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 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.
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'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’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.
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.
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?
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.
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.
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'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 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).
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.
So much cognitive overhead just managing that, this is so much better.
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.
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]
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.
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.
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'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...
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.
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 the 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?
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.