Interesting that the default coordinator is opus low and thread subagents are opus high. Some folks have been saying they do a fable orchestrator to a qwnen subagent, and this seems to be the inverse (cheaper coordinator, more expensive subagent).
Boris from the team here. Projects are how I write pretty much all my code these days. Happy to answer any questions.
The motivation for building the new coordinator is: as people get more comfortable using Claude Code, we noticed they start running more agents in parallel — Claude works, so you start another thread to work on the next thing. As the model gets smarter and more token-efficient, and as features like auto mode and cloud let agents run longer, this has become more and more common. You can do a lot of work in parallel this way. But the longer you multi-Claude this way, the more it feels like the UX is not good enough: it is hard to manage the complexity and context switch. It feels bad to fragment your attention like that.
At the same time, sometimes you want to deeply focus on a single task, and go back and forth on it without switching your attention to something else. Not every kind of work needs parallelization. This kind of single threaded focus remains really important.
The solution we came up with is coordinators. You do your work in Projects, then talk to your project’s coordinator, which then delegates work to threads when needed. Threads run in parallel and bubble up information and questions to the main thread. You can also jump into a thread to do deep work.
If you’ve tried it, we’d love to hear what you think. If you haven’t, give it a spin and please share feedback on what we can do to make it better for your use case (run /bug or make a GitHub issue).
I’ve been doing this kinda thing manually. I have an /orchestrate skill. I throw ideas at that agent, it figures out how to batch things, and then it opens new Rex splits where it gets a new agent to do the work of that batch. It’s like subagents but I can still open them and interact with them directly, keep planning more batches later, etc.
I agree with the problem of complexity and context switching, but I don't see how having a single orchestrator agent helps with this problem.
Nowadays, agents run for hours on a serial task, so after telling the agent to start working on something, you simply cannot work on it anymore for a few hours. I don't see how there's anything you can do that rescues you from having to switch to something else then back a few hours later.
I think accepting that context switching will happen, and simply optimizing the UI/UX to make context switching as fast as possible, will be the way to go in the future. This will involve some form of cross-task aggregation, and eventually it will pay to have an agent decide what you should pay attention to next, but I think it will not be one regular agent you talk to, but some kind of specialized UI where you go through a backlog of pending tasks and decisions.
Agree — that is what the coordinator is. You start a task in a Project, and Claude spins up a thread to work on it. You can then do other work in the project in parallel. When Claude needs you or has a result, it will tell you in the main thread. The cool part of the UX is it feels like a better use of attention — I no longer feel like I’m mentally jumping between contexts.
How does this differ from the existing subagent workflow? I almost exclusively work with Claude in the main thread as a coordinator, and it dispatches subagents in worktrees (and then integrates their changes). Is this essentially nicer UX on top of that pattern?
Ok, I think I might have misread your first comment. I interpreted it as the Claude Coordinator itself allowing "single-threaded focus".
On a second read, I can see what you actually meant was that the Claude Coordinator helps make multitasking smoother, and if you wanted focus, you can just jump into the individual Claude Code threads instead.
This makes sense and I have been thinking in the same direction for my personal kanban orchestrator. It completes multi-step epic tickets by orchestrating agents and answering their questions, while I can still go interact with individual tickets if I want. The bottleneck is ultimately in the decision-making quality of the coordinator, imo, which limits how much this can actually automate. (Serial runtime is also a big problem)
I have been building my own coordinator system recently, and one of the big problems that I have is keeping track of all of the parallel threads. By that I mean, I can start multiple sessions, each of which will run a workflow or multiple workflows in parallel.
What is your coordinator offering in terms of visualizing the progress being made? I often find an agent getting stuck somewhere somehow, and currently I must traverse the entire tree to spot them.
Where are the worktrees? I often run multiple AI workloads in the same repo, whether it be a monorepo or working on multiple feature requests for a single product. IMO this is the biggest miss I have from CC today, and the primary reason I run herdr to manage my agents.
Claude orchestrates threads in the cloud, and checks out the relevant repos without you having to specify it. Try it — if it doesn’t work for your setup, would love to learn more.
I'm excited to have a version of this I don't have to maintain myself anymore! My co-founder was just questioning me today if it was worth the effort to maintain.
I've found that the next two bottlenecks above broad project co-ordination across agents like this are 1) specifying a project in enough detail that you are actually happy with the results 2) predicting the costs in terms of tokens and time.
How are you managing these? I've found without getting a lot better at 1 and 2, parallel project management like this has questionable returns on tokens and time.
1. Opus 5.5 is a pretty good answer. We iterated a lot on the coordinator, and combined with Opus 5.5 or other modern models, it feels like it strikes the right balance of acting with autonomy while going back to inform you and to validate assumptions.
2. In AB tests and evals, we’ve found that the coordinator has <10% token overhead compared to running sessions directly, and users feel it’s well worth the cost. We’re thinking through ideas for better planning how to pace/use tokens, but don’t have a perfect solution yet. One thing that somewhat works is just asking the model eg. “use around 300k tokens”.
I’m personally a massive fan of it and it’s my main driver. Now having the coordinator more in the mix is a welcomed add and helps with the workflow when running multiple projects. At some stage, would love to have projects be able to talk / handoff to each other and a single dashboard across all projects to see where threads are up to.
Great feature; I feel like I've been trying to do this in different ways all year, from skills or sub agent config where the root agent supports similar orchestration, or trying to stuff agent status or outcomes into shared memory (and each agent having behaviors to surface it).
So much cognitive overhead just managing that, this is so much better.
I like this workflow so much that I actually built my own tool to do exactly that. https://github.com/endthestart/poundlock-dispatch And in the Claude desktop app I force all sessions to communicate through a Project Manager session. But it’s always been a pain due to the 10 message limit and having to schedule it to check on other sessions to ensure everything is still moving a long.
I built the claude code clone at a big EU corp. My code is over a year old and has 'orchestrator', 'watchdog', 'validator' etc.
I used Claude to help build, and went along with its suggested terminology, so, there is a lot of 'terminology leak' from the models as you use them. Probably why the terms are the same, helps the models integrate better with your own custom harness.
How embarrassing for them both. You should figure out who initially coined the word "project" so Anthropic, Cursor, and everyone else who has used the term since can go apologize.
At a high level the two are fairly similar. That said, the prompting is fairly different and optimized for the UX of talking to a coordinator without having to jump into sub-threads. Lots of other small differences around effort, tools, permission forwarding.
Hi Boris. We need the ability to run orchestrators on the local machine. Right now they run on the cloud which means they cannot access files and resources on the developer’s machine. This makes projects infeasible for many types of workloads.
At the moment I’m using a “regular” session as an orchestrator and have it start and manage its sessions (which it refers to as “lanes”, each of which runs Opus). Once each lane is done, the orchestrator (Fable) does its own review to make sure it “fits” the broader feature context. But the experience is clunky and nowhere as nice as how things work in projects. It may also be not as token efficient.
This has a lot of friction. Claude Projects concepts is great and I am experimenting with it. But this being cloud first is confusing to me and may be others as well. It asks too much permissions when working with local projects which become annoying after some time. Ideally Claude projects should be able to work with local projects only also. Now you are getting mixed feedback where lot of issues are due to being cloud first not projects on concept level.
I recently asked Claude what was the best Discord bot library and it spawned 7 sub-agents and ran me completely out of usage in about 10 minutes. I think this won't be particularly helpful until we solve the problem of usage exploding like that.
Its easy to fix. I've run into the same issue on day one, thankfully I got the usage reset. Just tell your claude session to be 'head-orchestrator' and delegate to Sonnet or Opus rather than more Fable agents. The fable making fable thing also made my usage evaporate.
Also a custom mcp letting it call Sol 6.1 on high via codex for general workers has really helped me preserve Claude usage.
I have a heavy workload running right now with Fable head-orch + Opus x8-10 sub-orchs calling codex workers, and usage is really slow for the amount of work being done.
It is surprising that Claude would use that many subagents, since we prompt Claude not to use subagents unless asked. You can verify this actually by intercepting the network traffic to see the system prompt.
It is also surprising that a few agents would cause you to run out of tokens that quickly.
1. Which model were you using?
2. Which plan are you using? Pro/Max/Ultra
3. Can you run /bug in that session and share the feedback id here? Happy to debug.
I was using Fable 5.2 on Max 5x -- I had Max 20x a few months ago but had to downsize.
I did ask a lot of it, but didn't expect it to fan out that far, nor even for that to be quite so expensive.
Here's the feedback id: 70ad3e81-cfab-4e83-9311-587561931e29
I used one of the Fable resets to continue on. That got me through it and I was satisfied with the result, I just can't believe I needed one for that task.
This use-case should be extraordinarily normal, it's insane for it to cost so much.
Question. I know they pay you a ridiculous amount of money but, do you ever get tired of having to pretend like every vibe coded release is the best thing ever and everyone should use it?
I've spent the last two building almost exactly this for fun at $DAYJOB, the todo list becomes individual threads with proactive comms. As I was building it, it was teaching me why there were some architectural choices in Gastown[1] that I was tilting my head at about back when it came out.
I've built half versions of it many times this year never getting the flow right.
Today I cracked the todo list led development where I was just adding ideas as streams of thought and if a thought was relevant to a repo I have a 'keeper' for each microservice who is the expert in answering questions and implementing features in its own domain. They live for forever and self compact if necessary but my coordinator session becomes chaos. I need to filter out the interactions I have with it to only relevant signals. At the moment I have them chatting back and forth and trying to keep up with them is intense.
My long term idea is that programs become living organisms where the agents live side by side to the code and running apps, receiving feedback from outside the system and implementing features and restarting and deploying itself with watchdogs. I had a lot of fun with it today.
My biggest issue is that the coordinator comes back to me with a question about an idea or feature that I had thought of an hour ago and it needs to refresh me on my own thoughts...
Gastown ended because it couldn’t stop fiddling with gastown instead of making things according to yegge. No idea how this isn’t different
I’ve seen code that top model agents produce and it’s still incorrect, often faking tests, makes local maxima but otherwise boneheaded decisions and tradeoffs that are straight up horrible to run and try to maintain and I have no idea how people have convinced themselves that details no longer matter.
The change from no moat -> a really big moat is the the migration of more and more coding to the cloud.
The more of your development setup is running in the cloud, I think it will be really hard to justify leaving. Certainly the cloud will for the next couple years be cheaper (credits, economies of scale etc).
I currently simply use claude code on fable 5.2 as 'head-orch' and have it spawn up Opus high suborchs, then the suborchs use a custom mcp for spawning codex/antigravity/deepseek/z.ai etc agents.
Right now I have 10+ suborchs running up to 20 sub sub workers each as sol 6.1 high workers.
github issues for work tracking/assignment + worktrees and prs to prevent collision. So far its working very well.
How do claude code projects improve on this?
Interesting that the default coordinator is opus low and thread subagents are opus high. Some folks have been saying they do a fable orchestrator to a qwnen subagent, and this seems to be the inverse (cheaper coordinator, more expensive subagent).
Boris from the team here. Projects are how I write pretty much all my code these days. Happy to answer any questions.
The motivation for building the new coordinator is: as people get more comfortable using Claude Code, we noticed they start running more agents in parallel — Claude works, so you start another thread to work on the next thing. As the model gets smarter and more token-efficient, and as features like auto mode and cloud let agents run longer, this has become more and more common. You can do a lot of work in parallel this way. But the longer you multi-Claude this way, the more it feels like the UX is not good enough: it is hard to manage the complexity and context switch. It feels bad to fragment your attention like that.
At the same time, sometimes you want to deeply focus on a single task, and go back and forth on it without switching your attention to something else. Not every kind of work needs parallelization. This kind of single threaded focus remains really important.
The solution we came up with is coordinators. You do your work in Projects, then talk to your project’s coordinator, which then delegates work to threads when needed. Threads run in parallel and bubble up information and questions to the main thread. You can also jump into a thread to do deep work.
If you’ve tried it, we’d love to hear what you think. If you haven’t, give it a spin and please share feedback on what we can do to make it better for your use case (run /bug or make a GitHub issue).
I’ve been doing this kinda thing manually. I have an /orchestrate skill. I throw ideas at that agent, it figures out how to batch things, and then it opens new Rex splits where it gets a new agent to do the work of that batch. It’s like subagents but I can still open them and interact with them directly, keep planning more batches later, etc.
I agree with the problem of complexity and context switching, but I don't see how having a single orchestrator agent helps with this problem.
Nowadays, agents run for hours on a serial task, so after telling the agent to start working on something, you simply cannot work on it anymore for a few hours. I don't see how there's anything you can do that rescues you from having to switch to something else then back a few hours later.
I think accepting that context switching will happen, and simply optimizing the UI/UX to make context switching as fast as possible, will be the way to go in the future. This will involve some form of cross-task aggregation, and eventually it will pay to have an agent decide what you should pay attention to next, but I think it will not be one regular agent you talk to, but some kind of specialized UI where you go through a backlog of pending tasks and decisions.
Agree — that is what the coordinator is. You start a task in a Project, and Claude spins up a thread to work on it. You can then do other work in the project in parallel. When Claude needs you or has a result, it will tell you in the main thread. The cool part of the UX is it feels like a better use of attention — I no longer feel like I’m mentally jumping between contexts.
How does this differ from the existing subagent workflow? I almost exclusively work with Claude in the main thread as a coordinator, and it dispatches subagents in worktrees (and then integrates their changes). Is this essentially nicer UX on top of that pattern?
Ok, I think I might have misread your first comment. I interpreted it as the Claude Coordinator itself allowing "single-threaded focus".
On a second read, I can see what you actually meant was that the Claude Coordinator helps make multitasking smoother, and if you wanted focus, you can just jump into the individual Claude Code threads instead.
This makes sense and I have been thinking in the same direction for my personal kanban orchestrator. It completes multi-step epic tickets by orchestrating agents and answering their questions, while I can still go interact with individual tickets if I want. The bottleneck is ultimately in the decision-making quality of the coordinator, imo, which limits how much this can actually automate. (Serial runtime is also a big problem)
I have been building my own coordinator system recently, and one of the big problems that I have is keeping track of all of the parallel threads. By that I mean, I can start multiple sessions, each of which will run a workflow or multiple workflows in parallel.
What is your coordinator offering in terms of visualizing the progress being made? I often find an agent getting stuck somewhere somehow, and currently I must traverse the entire tree to spot them.
Where are the worktrees? I often run multiple AI workloads in the same repo, whether it be a monorepo or working on multiple feature requests for a single product. IMO this is the biggest miss I have from CC today, and the primary reason I run herdr to manage my agents.
Claude orchestrates threads in the cloud, and checks out the relevant repos without you having to specify it. Try it — if it doesn’t work for your setup, would love to learn more.
Hi Boris, I've been having a great time with Fable 5.2 as the head-orch to spin up sub orchs that spin up sub sub workers as needed.
Besides the nicer UI, what other advantages are there over my current flow?
I'm excited to have a version of this I don't have to maintain myself anymore! My co-founder was just questioning me today if it was worth the effort to maintain.
I've found that the next two bottlenecks above broad project co-ordination across agents like this are 1) specifying a project in enough detail that you are actually happy with the results 2) predicting the costs in terms of tokens and time.
How are you managing these? I've found without getting a lot better at 1 and 2, parallel project management like this has questionable returns on tokens and time.
1. Opus 5.5 is a pretty good answer. We iterated a lot on the coordinator, and combined with Opus 5.5 or other modern models, it feels like it strikes the right balance of acting with autonomy while going back to inform you and to validate assumptions.
2. In AB tests and evals, we’ve found that the coordinator has <10% token overhead compared to running sessions directly, and users feel it’s well worth the cost. We’re thinking through ideas for better planning how to pace/use tokens, but don’t have a perfect solution yet. One thing that somewhat works is just asking the model eg. “use around 300k tokens”.
[edit: forgot HN needs newlines for lists]
I’m personally a massive fan of it and it’s my main driver. Now having the coordinator more in the mix is a welcomed add and helps with the workflow when running multiple projects. At some stage, would love to have projects be able to talk / handoff to each other and a single dashboard across all projects to see where threads are up to.
Great feature; I feel like I've been trying to do this in different ways all year, from skills or sub agent config where the root agent supports similar orchestration, or trying to stuff agent status or outcomes into shared memory (and each agent having behaviors to surface it).
So much cognitive overhead just managing that, this is so much better.
I like this workflow so much that I actually built my own tool to do exactly that. https://github.com/endthestart/poundlock-dispatch And in the Claude desktop app I force all sessions to communicate through a Project Manager session. But it’s always been a pain due to the 10 message limit and having to schedule it to check on other sessions to ensure everything is still moving a long.
Funny coincidence cursor came up with the exact same concept and names.
I built the claude code clone at a big EU corp. My code is over a year old and has 'orchestrator', 'watchdog', 'validator' etc.
I used Claude to help build, and went along with its suggested terminology, so, there is a lot of 'terminology leak' from the models as you use them. Probably why the terms are the same, helps the models integrate better with your own custom harness.
How embarrassing for them both. You should figure out who initially coined the word "project" so Anthropic, Cursor, and everyone else who has used the term since can go apologize.
Funny coincidence, I’ve worked in projects with coordinators for longer than either company has existed.
As far as I can see, this is not available via Claude Code CLI. Are there plans for it?
This is such an insightful view of the user experience. The user story you present is very familiar!
How is this different from having a coordinator open side sessions that report to it?
At a high level the two are fairly similar. That said, the prompting is fairly different and optimized for the UX of talking to a coordinator without having to jump into sub-threads. Lots of other small differences around effort, tools, permission forwarding.
Can we please have something like the live voice in chat in code! Seems like this would fit this orchestrator setup like a glove.
(and exposed to the SDK ideally!)
Babling about something in the UI or the UX then asking it to figure out some options has yielded me some insane results.
Hi Boris. We need the ability to run orchestrators on the local machine. Right now they run on the cloud which means they cannot access files and resources on the developer’s machine. This makes projects infeasible for many types of workloads.
At the moment I’m using a “regular” session as an orchestrator and have it start and manage its sessions (which it refers to as “lanes”, each of which runs Opus). Once each lane is done, the orchestrator (Fable) does its own review to make sure it “fits” the broader feature context. But the experience is clunky and nowhere as nice as how things work in projects. It may also be not as token efficient.
Projects can talk to your local machine, with your permission. We also support trusted devices for extra security.
Try asking Claude to run a command in your machine and report back? If it’s not working, make sure remote control is enabled in the project settings.
This has a lot of friction. Claude Projects concepts is great and I am experimenting with it. But this being cloud first is confusing to me and may be others as well. It asks too much permissions when working with local projects which become annoying after some time. Ideally Claude projects should be able to work with local projects only also. Now you are getting mixed feedback where lot of issues are due to being cloud first not projects on concept level.
I recently asked Claude what was the best Discord bot library and it spawned 7 sub-agents and ran me completely out of usage in about 10 minutes. I think this won't be particularly helpful until we solve the problem of usage exploding like that.
Its easy to fix. I've run into the same issue on day one, thankfully I got the usage reset. Just tell your claude session to be 'head-orchestrator' and delegate to Sonnet or Opus rather than more Fable agents. The fable making fable thing also made my usage evaporate.
Also a custom mcp letting it call Sol 6.1 on high via codex for general workers has really helped me preserve Claude usage.
I have a heavy workload running right now with Fable head-orch + Opus x8-10 sub-orchs calling codex workers, and usage is really slow for the amount of work being done.
It is surprising that Claude would use that many subagents, since we prompt Claude not to use subagents unless asked. You can verify this actually by intercepting the network traffic to see the system prompt.
It is also surprising that a few agents would cause you to run out of tokens that quickly.
1. Which model were you using?
2. Which plan are you using? Pro/Max/Ultra
3. Can you run /bug in that session and share the feedback id here? Happy to debug.
I was using Fable 5.2 on Max 5x -- I had Max 20x a few months ago but had to downsize.
I did ask a lot of it, but didn't expect it to fan out that far, nor even for that to be quite so expensive.
Here's the feedback id: 70ad3e81-cfab-4e83-9311-587561931e29
I used one of the Fable resets to continue on. That got me through it and I was satisfied with the result, I just can't believe I needed one for that task.
This use-case should be extraordinarily normal, it's insane for it to cost so much.
Sounds pretty good for anthropic.
Question. I know they pay you a ridiculous amount of money but, do you ever get tired of having to pretend like every vibe coded release is the best thing ever and everyone should use it?
I personally think it's a fantastic feature; I have a /dispatch skill that did exactly that and it helps me multi-tasks smaller things much faster!
It's pointless to talk about because it's not widely available.
I've spent the last two building almost exactly this for fun at $DAYJOB, the todo list becomes individual threads with proactive comms. As I was building it, it was teaching me why there were some architectural choices in Gastown[1] that I was tilting my head at about back when it came out.
I've built half versions of it many times this year never getting the flow right.
Today I cracked the todo list led development where I was just adding ideas as streams of thought and if a thought was relevant to a repo I have a 'keeper' for each microservice who is the expert in answering questions and implementing features in its own domain. They live for forever and self compact if necessary but my coordinator session becomes chaos. I need to filter out the interactions I have with it to only relevant signals. At the moment I have them chatting back and forth and trying to keep up with them is intense.
My long term idea is that programs become living organisms where the agents live side by side to the code and running apps, receiving feedback from outside the system and implementing features and restarting and deploying itself with watchdogs. I had a lot of fun with it today.
My biggest issue is that the coordinator comes back to me with a question about an idea or feature that I had thought of an hour ago and it needs to refresh me on my own thoughts...
[1] https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...
Gastown ended because it couldn’t stop fiddling with gastown instead of making things according to yegge. No idea how this isn’t different
I’ve seen code that top model agents produce and it’s still incorrect, often faking tests, makes local maxima but otherwise boneheaded decisions and tradeoffs that are straight up horrible to run and try to maintain and I have no idea how people have convinced themselves that details no longer matter.
So this only works in anthropic cloud?
I started feeling the push last month with the free cloud-only credits.
With Nvidia's GPUs now under control, open weight producing buyers are crippled.
Anthropic is turning the screws.
Claude creates my productivity. It's hosted centrally by a single company. Now it's pushing to control my execution environment, too.
I hope anthropic employees think about the long term destruction of individual agency they're pushing.
The agent must represent the individual, not the organization.
What future do you want?
The change from no moat -> a really big moat is the the migration of more and more coding to the cloud.
The more of your development setup is running in the cloud, I think it will be really hard to justify leaving. Certainly the cloud will for the next couple years be cheaper (credits, economies of scale etc).
> Certainly the cloud will for the next couple years be cheaper (credits, economies of scale etc).
Developing in the cloud is not cheaper than developing on hardware you already own though.
But yes, if you count the capex of acquiring new hardware, cloud is often cheaper.
Sounds like a great way to automatically increase API usage by a lot and drain customers of money
What a new and novel criticism
I mean if people quit saying it then people quit seeing it, and play right into the hands of these companies
But where's the lie?
So, I'm a bit curious what the point of this is.
I currently simply use claude code on fable 5.2 as 'head-orch' and have it spawn up Opus high suborchs, then the suborchs use a custom mcp for spawning codex/antigravity/deepseek/z.ai etc agents.
Right now I have 10+ suborchs running up to 20 sub sub workers each as sol 6.1 high workers.
github issues for work tracking/assignment + worktrees and prs to prevent collision. So far its working very well. How do claude code projects improve on this?
Only a few more Silly CON valley moats to pillage, and Claude does everything!
One subscription to rule them all, as long you're nice to Claude...
What a time to be alive, couldn't think of a nicer group of people to give my money to.