I have a specific use case (financial analysis), that is at the edge of what is possible with this models (accuracy wise).
Gemini 2 was the beginning, you could see this technology could be helpful in this specific analysis but plenty of errors (not unlike a junior analyst). Gemini 2.5 flash was great actually useable, errors made were consistent.
This is where it gets interesting, I could add additional points to my system prompt, yes it would fix those errors but it would degrade the answer elsewhere, often it wouldn't be incorrect but merely much simpler less nuanced and less clever.
This is where multi-agents helped it actually meant the prompt can be broken down so that answers remain "clever". There is a big con to this, it is slow, slow to the point that I chose to stick with a single prompt (the request didn't work well operating in parallel as the other prompt surfaced factors for it to consider).
However Gemini 3 flash is now smart enough that I'd now consider my financial analysis solved. All with one prompt.
It's hard to accurately measure but one advantage that the multi-agent approach has seems to be speed. I routinely see Sisyphus launching up to 4 sub agents to read/analyse a file and/or to do things in parallel.
The quality of the output depends more on the underlying LLM. GLM 4.7 isn't going to beat Opus but Opus with an orchestra seems to be faster and perhaps marginally better than with a more linear approach.
Ofcourse this burns a lot of tokens but with a cheap subscription like z. ai or with a corporate budget does it really matter?
This feels like reading about some kind of obscure roleplaying game. As far as I can understand:
- there was a CLI based on OpenCode, that depended on extracting the auth token used by Claude Code
- Anthropic found a way to prevent this
- This person (or AI) reimplemented similar workflows using custom commands inside Claude Code instead
It appears that Anthropic is totally in their right to do this. Third party software is meant to use the API instead. It sucks that it's so much more expensive, but it's their decision to make,
Meanwhile, this seems like a good approach, both sides win. The project page would benefit from skipping all the drama and focusing on being a helpful intro.
This seems great, but installing a bunch of prompt from an hackernews/github account with no history seems like something you shouldn't do. Especially with "silent auto-upgrade".
I'm not familiar with this at all. But at first blush, it seems like the Readme is far more interested in being angry with Anthropic than actually telling me what this is or why I care.
I see "Multi Agent Orchestration", but, scrolling through this I still have no idea what I'm looking at.
The readme (and probably most of the project) is likely generated by an LLM - chances are we'll learn more reading the prompts than the readme.
I actually tried this few days back before the Claude Code EULA reinforcement, I went through the same thing.
1. I honestly had a hard time parsing what this is supposed to do or provide over standard opencode setup from the readme. It is rather long-winded and have a lot of bombastic claims but doesnt really explain what it does.
2. Regardless, the claims are pretty enticing. Because I was in experiment mode, and I already had a VM running to try out some other stuff, I gave it a try
3. From what I can tell, its basically a set of configs and plugins to make opencode behave a certain way. Kinda like how lazyvim/astronvim are to neovim.
4. But for all its claims, it had a lot of issues - the setups are rather brittle and was hard to get working out of the box (this is from someone who is pretty comfortable tinkering with vim configs), when I managed to get it working (at least I think its working), its kinda meh? It uses up way more tokens than the default opencode, for worse (or at less consistent) results.
5, FWIW, I dont find the multi/sub-agent workflow to be all that useful for most tasks, or at the very least its still very early IMO, kinda like the function calling phase of chatgpt to really be useful.
6. I was actually able to grok most of Steve Yegge's gastown post from the other day. He made-up a lot of terms that I think made things even more confusing, but I was able to recognize many of the concepts as things that I also had thought of them in a "it would be cool if we can do X/Y/Z" manner. Not with this project.
TBH, at this point im not sure if I'm using it wrong or am I missing something, or this is just how people market their projects in the age of LLM.
edit: what I tried the other day was the code-yeongyu/oh-my-opencode, not this (fork?) project
Re point 5, the simplest argument in favor of sub-agent workflows it that it allows the main agent context to remain free of a large amount of task-specific working context. This lets the main context survive longer before you need compaction. Compaction in CC is a major loss of context IME. Context compaction is generally the point where I reset the conversation as the compacted conversation is practically as bad as a new one but has a bunch of wasted space already.
How I wish we could just see and patch up the raw context before it goes out. If I could hand edit a compaction it would result in better execution going forward and better for my own mental model. It’s such a small feature, but Anthropic would never give it to us.
I recentry read a book that presentes its content as ramble poetry, a post-ironic reference heavy text. I feel that is a suitable description for this readme page.
It sounds pretty reasonable to me that they sell a subscription without API access at a different price than the one with that feature. It's obviously a very useful feature or the workaround wouldn't exist, right?
To me it sounds like the CLI subscription is a loss-leader designed to get you hooked so you'll upgrade once you realize it's valuable enough to pay extra for the "premium" features. It also sounds pretty reasonable to ban products designed to cheat them out of the difference in cost.
Am I missing some nuance, or is this just internet people being cheap?
The cli subscription actually actively cannibalizes the API business in my experience. I think this is a product decision: if you use it to code, they want to control the user experience.
If you use it to back up 100,000 MAUs, then they want you to use the API.
I was originally an API user but the cli subscription is so much cheaper that I switched over. This is a combination of th CLI getting much more useful and reasoning models using many more tokens.
Comparing this to API access feels odd to me. Opencode does not magically convert your subscription into API usage. It is just an alternative to the official CLI. It has a web UI, smoother UX, and less flickering. Nothing groundbreaking, but it is pretty annoying that even something as simple as tagging files with @ is still so laggy.
How do you think Claude Code and OpenCode communicate with Anthropic? Through the API. Maybe it's accessed slightly differently for subscription users. Anthropic is saying you can't use the API via a subscription anywhere you want. Only Claude Code can use it that way.
OpenCode doesnt use the official API. It illegally bypasses it and pretends to be the Claude CLI app, which allows people who dont pay for API access to use it anyhow. That violates Anthropics TOS and robs them of income they rightfully should have had.
If you dont like a service or cant afford it dont use it. If you do and you can, be a paying customer.
This removes the primary advantage of opencode, easy access to many models to avoid hammering a single service. Absolutely unusable to anyone with a pro sub.
If I have a team of developers should I be enforcing this type of multi-agent setup for development? Has this tech reached the level of being better than your above average developer at implementing well specified features? Has anyone had success doing this?
In my experience multi-agent orchestration frameworks usually accomplish vague to unnoticable to straight up worse results compared just getting used to the vanilla tools before impulsively installing the daily flavor of "I made Claude Code better". I'm guessing you've probably already noticed by now these come out daily. But a look at the repo shows that they do at least halfway use sub-agents in the way most people are starting to realize they're (currently at least) most helpful imo, which is managing context bloat in the main chats. Not a fan of wishfully creating "expert" agents which amount to little more than prompts asking Claude to a good job at the task. I'm honestly not sure why that couldn't be a slash command at that point.
If you're an engineering manager, you should communicate with your team, know their strengths and weaknesses, stay sharp on modern technique, and, most importantly, ask them what workflows work best for them, not us on Hacker News.
If you're hiring a consultancy or a pile of freelancers it's a bit different, but the question here would make me believe you don't trust their capability to start and I would be looking for teams that better align with what you expect as their outputs.
Huh? You don't need all of this to program effectively with Claude. You just need a daft idea, a bad API sketch and patience. A large vocabulary of insults and swear words goes a long way as well.
Idk, I'm skeptical. Is there any proof that these multi agent orchestrators with fancy names actually do anything other than consuming more tokens?
Reasoning density.
I have a specific use case (financial analysis), that is at the edge of what is possible with this models (accuracy wise).
Gemini 2 was the beginning, you could see this technology could be helpful in this specific analysis but plenty of errors (not unlike a junior analyst). Gemini 2.5 flash was great actually useable, errors made were consistent.
This is where it gets interesting, I could add additional points to my system prompt, yes it would fix those errors but it would degrade the answer elsewhere, often it wouldn't be incorrect but merely much simpler less nuanced and less clever.
This is where multi-agents helped it actually meant the prompt can be broken down so that answers remain "clever". There is a big con to this, it is slow, slow to the point that I chose to stick with a single prompt (the request didn't work well operating in parallel as the other prompt surfaced factors for it to consider).
However Gemini 3 flash is now smart enough that I'd now consider my financial analysis solved. All with one prompt.
It's hard to accurately measure but one advantage that the multi-agent approach has seems to be speed. I routinely see Sisyphus launching up to 4 sub agents to read/analyse a file and/or to do things in parallel.
The quality of the output depends more on the underlying LLM. GLM 4.7 isn't going to beat Opus but Opus with an orchestra seems to be faster and perhaps marginally better than with a more linear approach.
Ofcourse this burns a lot of tokens but with a cheap subscription like z. ai or with a corporate budget does it really matter?
This feels like reading about some kind of obscure roleplaying game. As far as I can understand:
- there was a CLI based on OpenCode, that depended on extracting the auth token used by Claude Code
- Anthropic found a way to prevent this
- This person (or AI) reimplemented similar workflows using custom commands inside Claude Code instead
It appears that Anthropic is totally in their right to do this. Third party software is meant to use the API instead. It sucks that it's so much more expensive, but it's their decision to make,
Meanwhile, this seems like a good approach, both sides win. The project page would benefit from skipping all the drama and focusing on being a helpful intro.
This seems great, but installing a bunch of prompt from an hackernews/github account with no history seems like something you shouldn't do. Especially with "silent auto-upgrade".
At least its open source ?
I'm not familiar with this at all. But at first blush, it seems like the Readme is far more interested in being angry with Anthropic than actually telling me what this is or why I care.
I see "Multi Agent Orchestration", but, scrolling through this I still have no idea what I'm looking at.
The readme (and probably most of the project) is likely generated by an LLM - chances are we'll learn more reading the prompts than the readme.
I actually tried this few days back before the Claude Code EULA reinforcement, I went through the same thing.
1. I honestly had a hard time parsing what this is supposed to do or provide over standard opencode setup from the readme. It is rather long-winded and have a lot of bombastic claims but doesnt really explain what it does.
2. Regardless, the claims are pretty enticing. Because I was in experiment mode, and I already had a VM running to try out some other stuff, I gave it a try
3. From what I can tell, its basically a set of configs and plugins to make opencode behave a certain way. Kinda like how lazyvim/astronvim are to neovim.
4. But for all its claims, it had a lot of issues - the setups are rather brittle and was hard to get working out of the box (this is from someone who is pretty comfortable tinkering with vim configs), when I managed to get it working (at least I think its working), its kinda meh? It uses up way more tokens than the default opencode, for worse (or at less consistent) results.
5, FWIW, I dont find the multi/sub-agent workflow to be all that useful for most tasks, or at the very least its still very early IMO, kinda like the function calling phase of chatgpt to really be useful.
6. I was actually able to grok most of Steve Yegge's gastown post from the other day. He made-up a lot of terms that I think made things even more confusing, but I was able to recognize many of the concepts as things that I also had thought of them in a "it would be cool if we can do X/Y/Z" manner. Not with this project.
TBH, at this point im not sure if I'm using it wrong or am I missing something, or this is just how people market their projects in the age of LLM.
edit: what I tried the other day was the code-yeongyu/oh-my-opencode, not this (fork?) project
Re point 5, the simplest argument in favor of sub-agent workflows it that it allows the main agent context to remain free of a large amount of task-specific working context. This lets the main context survive longer before you need compaction. Compaction in CC is a major loss of context IME. Context compaction is generally the point where I reset the conversation as the compacted conversation is practically as bad as a new one but has a bunch of wasted space already.
How I wish we could just see and patch up the raw context before it goes out. If I could hand edit a compaction it would result in better execution going forward and better for my own mental model. It’s such a small feature, but Anthropic would never give it to us.
Thanks for pointing me to the Gas Town blog post. That was...a lot. I'm going to need a lot of time to digest everything that was in there.
I recentry read a book that presentes its content as ramble poetry, a post-ironic reference heavy text. I feel that is a suitable description for this readme page.
For those who've been tracking the Oh My OpenCode and Anthropic fight.
That has really been the "OpenCode and Anthropic" fight, OMO is still a tiny player compared to all OpenCode (and other such clients) usage.
Do you have a link to some background? I'm curious why it was banned.
https://news.ycombinator.com/item?id=46549823
They banned it because it’s the current way tech companies are expected to operate.
It sounds pretty reasonable to me that they sell a subscription without API access at a different price than the one with that feature. It's obviously a very useful feature or the workaround wouldn't exist, right?
To me it sounds like the CLI subscription is a loss-leader designed to get you hooked so you'll upgrade once you realize it's valuable enough to pay extra for the "premium" features. It also sounds pretty reasonable to ban products designed to cheat them out of the difference in cost.
Am I missing some nuance, or is this just internet people being cheap?
The cli subscription actually actively cannibalizes the API business in my experience. I think this is a product decision: if you use it to code, they want to control the user experience.
If you use it to back up 100,000 MAUs, then they want you to use the API.
I was originally an API user but the cli subscription is so much cheaper that I switched over. This is a combination of th CLI getting much more useful and reasoning models using many more tokens.
Comparing this to API access feels odd to me. Opencode does not magically convert your subscription into API usage. It is just an alternative to the official CLI. It has a web UI, smoother UX, and less flickering. Nothing groundbreaking, but it is pretty annoying that even something as simple as tagging files with @ is still so laggy.
How do you think Claude Code and OpenCode communicate with Anthropic? Through the API. Maybe it's accessed slightly differently for subscription users. Anthropic is saying you can't use the API via a subscription anywhere you want. Only Claude Code can use it that way.
OpenCode doesnt use the official API. It illegally bypasses it and pretends to be the Claude CLI app, which allows people who dont pay for API access to use it anyhow. That violates Anthropics TOS and robs them of income they rightfully should have had.
If you dont like a service or cant afford it dont use it. If you do and you can, be a paying customer.
This removes the primary advantage of opencode, easy access to many models to avoid hammering a single service. Absolutely unusable to anyone with a pro sub.
It’s not hard to set up a router/proxy for Claude Code to use something else.
If I have a team of developers should I be enforcing this type of multi-agent setup for development? Has this tech reached the level of being better than your above average developer at implementing well specified features? Has anyone had success doing this?
In my experience multi-agent orchestration frameworks usually accomplish vague to unnoticable to straight up worse results compared just getting used to the vanilla tools before impulsively installing the daily flavor of "I made Claude Code better". I'm guessing you've probably already noticed by now these come out daily. But a look at the repo shows that they do at least halfway use sub-agents in the way most people are starting to realize they're (currently at least) most helpful imo, which is managing context bloat in the main chats. Not a fan of wishfully creating "expert" agents which amount to little more than prompts asking Claude to a good job at the task. I'm honestly not sure why that couldn't be a slash command at that point.
If you're an engineering manager, you should communicate with your team, know their strengths and weaknesses, stay sharp on modern technique, and, most importantly, ask them what workflows work best for them, not us on Hacker News.
If you're hiring a consultancy or a pile of freelancers it's a bit different, but the question here would make me believe you don't trust their capability to start and I would be looking for teams that better align with what you expect as their outputs.
Why are you being so combative?
I dont understand how you can say that its a bad thing to ask an IT professional community like HN for advice?
I assume you were born with all the knowledge of the world?
Probably the "should I force X on my team" instead of managing them like professionals with insight (or even just treating them like adults).
Managers deciding minutiae like this is the type of micromanagement you make blog posts about, imo.
You would have likely received less combative feedback without your first sentence. I would have framed it as "recommend to team"
No. Just, no to all of this
Enforce?
Just pay for the API access.
Huh? You don't need all of this to program effectively with Claude. You just need a daft idea, a bad API sketch and patience. A large vocabulary of insults and swear words goes a long way as well.
Terrible name…