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’ve been experimenting with this too but feel like I haven’t found the right implementation yet. Do you have any code or magic you’d be willing to share?
I love T3 code. Works like inbox zero, hiding running threads until Claude needs input or is done.
Integration with repo/PR is nice.
Ability to have multiple accounts and mix OpenAI/Anthropic/local.
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.
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)
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?
The threads (or sub agents) can speak to each other and organise each other, threads can spin up scheduled tasks to check on things later, and threads are organised by status so you can see when something needs you, is working, or is done.
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.
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”.
Does it work to ask them to pace themselves so they can work at a pace that stays within the usage limit windows, so that it can just keep going but perhaps slower?
I've been doing this with one of my VM projects and hit message caps really quickly, threads start stalling out.
In the end I needed to use a coordinator.md file to backdoor messages and locking state in a pull instead of push model to keep them running overnight.
I need a lot of inter-thread comms because my app has to build a kernel inside itself and then replace itself to run tests which meant I was hitting concurrency and load issues with multiple sessions trying to run things like benchmarks against their own work tree.
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.
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 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 did built something like this in the past. Claude can wait on output from a CLI quite easily, without having to setup scheduled tasks. So you can have a CLI that waits for the next message and exit as your inbox mechanism.
Has this changed the way the code harness decides on whether to send sub agents on a task? I noticed in my last few sessions that the opened sessions have much more liberally sent out agents (often with the justification of preserving context in their session).
So far I would say it’s a welcome new behavior, but a noticeable change (Opus-5-5 at xhigh).
Your description matches my experience, though i'm here on raw claude code over many sessions in parallel. I'd be happy to hear how I can set this "projects" thing up and give it a spin, is this a cloud-only or desktop-app only thing?
I haven’t been able to make the switch yet. I feel at home in a terminal, but I recognize that a TUI is inherently limited compared to a full fledged GUI.
It still feels strange to make the switch. Do you think the Desktop experience is actually superior? Is it Projects that make it more useful than Code?
I'm looking at the linked projects thin in general but i'm truly confused. I can't quite tell here on the website how i'd connect my github repository to a "project", the connector doesn't show up even though its.. connected. If anything the article seems to indicate I could connect multiple repositories (ie: a backend, a frontend, an app) and that sounds great for my use case.
But then I also question how the tooling would work, and where the work would run at all, it seems to indicate it can run over the Claude Desktop app if I link my machine and the article says "Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon" so that's the threads feature boris seem to be describing, excited to try it of course but I need a "project" first!
And... this isn't under the code tab on the website, it's under the normal "claude" tab, so i'm not sure what they want to indicate with that?
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.
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.
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 find it to be quite cautious too. Beyond the access prompts, the model itself tends not to take as much initiative when using a local machine. It often hands tasks off to me when it needs a web browser, for which I say “you drive” and it will. It’ll ask me to confirm in writing to perform an action on a local machine - sometimes to auto classifier knocks it back because I didn’t use the exact words. An example for this recently was pushing a new release to an internal TestFlight group - took several attempts but it wouldn’t accept so I did it manually, which a local session has no complaints doing.
I need one line from you: “save the ** scripts to sql-scripts/data-ops/update”. When I tried to write them there, the save was blocked because the approval reached me through the coordinator, not from you in this thread.
It is very limiting to not be able to specify effort level of the coordinator.
For me the orchestrator plays the role of a staff software engineer who is the team lead and knows about the whole project. I usually have it run Fable at high or xhigh. Its job is to coordinate the work of mid/senior engineers (Opus high/xhigh) that work on individual tickets, do the final review of their output (after their own subagent review rounds and fixes), make sure it fits the project as a whole and meets the quality threshold, then merge it. It also independently validates the Opus agents' findings, files follow-up tickets, performs cleanup of test databases and Vitest caches, talks to other orchestrators that are overseeing their own areas to address integration points, and so on. That's why it's the most capable agent.
In Projects though, coordinators appear to be running at low/mid effort, and are mostly responsible for ferrying messages back and forth. Basically a project coordinator/manager role. So it doesn't quite fit the way I work or how I think.
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.
That sucks - I've definitely been there. I think the lesson of "opus 5.5 is functionally the greatest model ever made and probably actually better than fable for a go research alternatives task and frankly I could have gotten away with sonnet subagents and why would I even use Fable for a task like that" is just one we all have to learn our versions of at the cost of a reset lol.
For me it was "oh max mode is literally a scam and always worse and never worth it" followed by "ultra code is not worth it" followed by "fable 5 rules but literally anything simple enough that I can do before I run out of usage limits on the 5x plan, the other AIs can do." Luckily though it turned out fable was also good at orchestrating non fable subagents so that was cool.
But yeah that's not a harness problem unfortunately. I guess they do encourage you to hit the money furnace button (ultra code pretty colors!) but yeah that's rough. Silver lining - you had a reset!
> "You do your work in Projects, then talk to your project’s coordinator, which then delegates work to threads when needed."
Correct me if I'm wrong, but you skipped a layer: Projects use a coordinator → worker → threads pattern.
This is the reason I only tried Projects once and then went back to my previous way of working: Threads in the current UI aren't easy to track or to watch over. Apparently if you want to know what they're doing you're supposed to ask your coordinator. That's crazyville.
It may not be "correct" but I like to use Fable as a coordinator/orchestrator/planner/assistant and validator. I chat with it constantly. I've banned it from doing any implementation or research work on its own. Instead it always fires off Opus subagents to do the work and then it validates their work when they're done and then updates me.
This way, the Fable thread is always available for me to chat with, plan, brainstorm, answer questions, etc. Yes, just like a Project's coordinator, but I always know what it's doing and workers are just one step away. The way the Projects are set up seems way more hands-off.
Working this way in the Desktop GUI, I can easily see all the subagents and subtasks that are running and I can drop in and check out what they're doing/thinking/etc. with a single click. This has helped numerous times as they can get stuck, or I can see that I've given the wrong instructions, or something else. I also have the main Fable session set timers so it can monitor for stuck agents as well (waiting for a test suite to return that never does, for example). I don't have anywhere near the same control and visibility into threads.
Projects instead defaults to a less advanced coordinator/orchestrator (I know you can change it but the point is that the system is designed for a dumber coordinator), then the smarter worker subagents start, but I don't get to talk to them directly unless I hunt them down, and then they fire off threads which I have NO visibility at all into and have no idea what they're doing.
You guys at Anthropic need to think about us poor schmucks that don't have unlimited tokens to work with. I can't have threads out there sucking up tokens/usage allowance only to find out later that they were wasting their time.
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.
> I have no idea how people have convinced themselves that details no longer matter.
Quantity has a quality of its own.
Being able to ship 40 features in a week starts to look very appealing against only 4. The quality issue is often not a dealbreaker, and I’ve seen very good quality code come out of these newer models, things a human wouldn’t have thought to do or wouldn’t have time for.
This is why in my private life I run only open weights models and procure all the hardware I can get my hands on. I don't want to be completely beholden to this company and its whims.
If you can't run models locally, look to openrouter for an escape hatch. Better to abandon Anthropic's ship now than a year down the road after they've had time to refine the cloud lock-in.
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).
The hardware of cloud environments feels like a real limiting factor for serious work. It isn't hard for 4 vCPU and 16 GB to become a bottleneck on compilation or running tests, especially integration tests with multiple containers involved.
It seems pretty easy to just set something like this yourself.
Personally, I just use Caldav and XMPP. Todos added to caldav get prioritized and picked up by an LLM and then worked on. The work is then evaluated in a simulator, screenshots/videos are sent from the LLM to confirm that the design is correct, or to ask follow up questions. From my phone I can screenshot my project and then add it to the todo list and queue it easily, and it will just get picked up and worked on.
Maybe I'm reinventing the wheel or sound like the anti-Dropbox guy, but I like that whatever feature I want or need in my workflow I just ask the LLM to add that. Makes it so that I can strip away a lot of complexity.
Edit: ok, I switched the URL from https://alphasignal.ai/news/anthropic-upgrades-claude-code-p... to what looks like the original announcement. If there's newer information not covered there, we can change the URL again, but I'd prefer a link to something intelligible.
I’ve been doing this in my Intent [0] system for a while now. A word of caution, Intent is not for everyone. :) It focusses a lot on guardrails and controls and what I call “critics”, that are concerned with code quality and using correct idioms, so #ymmv. But it does have a complete Multi-Agent framework that has served me pretty well for the last (almost) 12 months or so since I moved from a single-agent to multi-agent workflow.
Maybe if things weren’t relentlessly sucky in exactly the same way every god damn time, you wouldn’t have to hear the same critiques over and over again.
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?
I’m actually genuinely curious about this as well. I’m saturated at low single digits where I run out of things I actually want.
Like I could definitely find ways to do it if someone is paying me to burn tokens (have 5 of the agents come up with busywork for the rest).
I had my agent add OpenRouter support and provider toggling and it took 15 minutes-ish on a single agent.
Some of me wonders if these are just deeply unoptimized projects and agent harnesses burning tokens because it sounds fancy. I can’t imagine why you would ever need 200 agents for a normal codebase unless 200 agents was the goal or the codebase is an absolute nightmare.
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).
Please stop working on new products and finally fix its weird reverse writing style. I pay for codex just to get it to rewrite the meaningless shit Claude writes.
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’ve been experimenting with this too but feel like I haven’t found the right implementation yet. Do you have any code or magic you’d be willing to share?
I love T3 code. Works like inbox zero, hiding running threads until Claude needs input or is done. Integration with repo/PR is nice. Ability to have multiple accounts and mix OpenAI/Anthropic/local.
Yup been doing the same but with Orca.
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.
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)
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?
The threads (or sub agents) can speak to each other and organise each other, threads can spin up scheduled tasks to check on things later, and threads are organised by status so you can see when something needs you, is working, or is done.
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.
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]
Does it work to ask them to pace themselves so they can work at a pace that stays within the usage limit windows, so that it can just keep going but perhaps slower?
I've been doing this with one of my VM projects and hit message caps really quickly, threads start stalling out.
In the end I needed to use a coordinator.md file to backdoor messages and locking state in a pull instead of push model to keep them running overnight.
I need a lot of inter-thread comms because my app has to build a kernel inside itself and then replace itself to run tests which meant I was hitting concurrency and load issues with multiple sessions trying to run things like benchmarks against their own work tree.
Will projects hit the same issue?
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.
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.
What if we don't want it in the cloud? What if we want it to orchestrate what it can locally?
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 did built something like this in the past. Claude can wait on output from a CLI quite easily, without having to setup scheduled tasks. So you can have a CLI that waits for the next message and exit as your inbox mechanism.
Has this changed the way the code harness decides on whether to send sub agents on a task? I noticed in my last few sessions that the opened sessions have much more liberally sent out agents (often with the justification of preserving context in their session).
So far I would say it’s a welcome new behavior, but a noticeable change (Opus-5-5 at xhigh).
Your description matches my experience, though i'm here on raw claude code over many sessions in parallel. I'd be happy to hear how I can set this "projects" thing up and give it a spin, is this a cloud-only or desktop-app only thing?
Desktop only for now, rolling out gradually. Will be out to everyone soon.
Why do you prefer Desktop over Code?
I haven’t been able to make the switch yet. I feel at home in a terminal, but I recognize that a TUI is inherently limited compared to a full fledged GUI.
It still feels strange to make the switch. Do you think the Desktop experience is actually superior? Is it Projects that make it more useful than Code?
It's not publically released yet... which I guess Boris could of mentioned...
I'm looking at the linked projects thin in general but i'm truly confused. I can't quite tell here on the website how i'd connect my github repository to a "project", the connector doesn't show up even though its.. connected. If anything the article seems to indicate I could connect multiple repositories (ie: a backend, a frontend, an app) and that sounds great for my use case.
But then I also question how the tooling would work, and where the work would run at all, it seems to indicate it can run over the Claude Desktop app if I link my machine and the article says "Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon" so that's the threads feature boris seem to be describing, excited to try it of course but I need a "project" first!
And... this isn't under the code tab on the website, it's under the normal "claude" tab, so i'm not sure what they want to indicate with that?
This is such an insightful view of the user experience. The user story you present is very familiar!
As far as I can see, this is not available via Claude Code CLI. Are there plans for it?
Yep, working on it
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?
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.
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.
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.
What are the specific pieces of friction? Do you mean for example the prompt asking whether you trust the device?
I find it to be quite cautious too. Beyond the access prompts, the model itself tends not to take as much initiative when using a local machine. It often hands tasks off to me when it needs a web browser, for which I say “you drive” and it will. It’ll ask me to confirm in writing to perform an action on a local machine - sometimes to auto classifier knocks it back because I didn’t use the exact words. An example for this recently was pushing a new release to an internal TestFlight group - took several attempts but it wouldn’t accept so I did it manually, which a local session has no complaints doing.
One more live example which I just encountered.
I need one line from you: “save the ** scripts to sql-scripts/data-ops/update”. When I tried to write them there, the save was blocked because the approval reached me through the coordinator, not from you in this thread.
It is very limiting to not be able to specify effort level of the coordinator.
For me the orchestrator plays the role of a staff software engineer who is the team lead and knows about the whole project. I usually have it run Fable at high or xhigh. Its job is to coordinate the work of mid/senior engineers (Opus high/xhigh) that work on individual tickets, do the final review of their output (after their own subagent review rounds and fixes), make sure it fits the project as a whole and meets the quality threshold, then merge it. It also independently validates the Opus agents' findings, files follow-up tickets, performs cleanup of test databases and Vitest caches, talks to other orchestrators that are overseeing their own areas to address integration points, and so on. That's why it's the most capable agent.
In Projects though, coordinators appear to be running at low/mid effort, and are mostly responsible for ferrying messages back and forth. Basically a project coordinator/manager role. So it doesn't quite fit the way I work or how I think.
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.
Why can't it just be aware of usage limits and act accordingly?
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.
That sucks - I've definitely been there. I think the lesson of "opus 5.5 is functionally the greatest model ever made and probably actually better than fable for a go research alternatives task and frankly I could have gotten away with sonnet subagents and why would I even use Fable for a task like that" is just one we all have to learn our versions of at the cost of a reset lol.
For me it was "oh max mode is literally a scam and always worse and never worth it" followed by "ultra code is not worth it" followed by "fable 5 rules but literally anything simple enough that I can do before I run out of usage limits on the 5x plan, the other AIs can do." Luckily though it turned out fable was also good at orchestrating non fable subagents so that was cool.
But yeah that's not a harness problem unfortunately. I guess they do encourage you to hit the money furnace button (ultra code pretty colors!) but yeah that's rough. Silver lining - you had a reset!
Honestly, I would've preferred not to use that reset because I probably won't get more, but thanks.
Sounds pretty good for anthropic.
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.
> "You do your work in Projects, then talk to your project’s coordinator, which then delegates work to threads when needed."
Correct me if I'm wrong, but you skipped a layer: Projects use a coordinator → worker → threads pattern.
This is the reason I only tried Projects once and then went back to my previous way of working: Threads in the current UI aren't easy to track or to watch over. Apparently if you want to know what they're doing you're supposed to ask your coordinator. That's crazyville.
It may not be "correct" but I like to use Fable as a coordinator/orchestrator/planner/assistant and validator. I chat with it constantly. I've banned it from doing any implementation or research work on its own. Instead it always fires off Opus subagents to do the work and then it validates their work when they're done and then updates me.
This way, the Fable thread is always available for me to chat with, plan, brainstorm, answer questions, etc. Yes, just like a Project's coordinator, but I always know what it's doing and workers are just one step away. The way the Projects are set up seems way more hands-off.
Working this way in the Desktop GUI, I can easily see all the subagents and subtasks that are running and I can drop in and check out what they're doing/thinking/etc. with a single click. This has helped numerous times as they can get stuck, or I can see that I've given the wrong instructions, or something else. I also have the main Fable session set timers so it can monitor for stuck agents as well (waiting for a test suite to return that never does, for example). I don't have anywhere near the same control and visibility into threads.
Projects instead defaults to a less advanced coordinator/orchestrator (I know you can change it but the point is that the system is designed for a dumber coordinator), then the smarter worker subagents start, but I don't get to talk to them directly unless I hunt them down, and then they fire off threads which I have NO visibility at all into and have no idea what they're doing.
You guys at Anthropic need to think about us poor schmucks that don't have unlimited tokens to work with. I can't have threads out there sucking up tokens/usage allowance only to find out later that they were wasting their time.
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.
> I have no idea how people have convinced themselves that details no longer matter.
Quantity has a quality of its own.
Being able to ship 40 features in a week starts to look very appealing against only 4. The quality issue is often not a dealbreaker, and I’ve seen very good quality code come out of these newer models, things a human wouldn’t have thought to do or wouldn’t have time for.
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?
> What future do you want?
This is why in my private life I run only open weights models and procure all the hardware I can get my hands on. I don't want to be completely beholden to this company and its whims.
If you can't run models locally, look to openrouter for an escape hatch. Better to abandon Anthropic's ship now than a year down the road after they've had time to refine the cloud lock-in.
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).
The hardware of cloud environments feels like a real limiting factor for serious work. It isn't hard for 4 vCPU and 16 GB to become a bottleneck on compilation or running tests, especially integration tests with multiple containers involved.
> 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.
It seems pretty easy to just set something like this yourself.
Personally, I just use Caldav and XMPP. Todos added to caldav get prioritized and picked up by an LLM and then worked on. The work is then evaluated in a simulator, screenshots/videos are sent from the LLM to confirm that the design is correct, or to ask follow up questions. From my phone I can screenshot my project and then add it to the todo list and queue it easily, and it will just get picked up and worked on.
Maybe I'm reinventing the wheel or sound like the anti-Dropbox guy, but I like that whatever feature I want or need in my workflow I just ask the LLM to add that. Makes it so that I can strip away a lot of complexity.
Can somebody please find a better link for this?
Edit: ok, I switched the URL from https://alphasignal.ai/news/anthropic-upgrades-claude-code-p... to what looks like the original announcement. If there's newer information not covered there, we can change the URL again, but I'd prefer a link to something intelligible.
I’ve been doing this in my Intent [0] system for a while now. A word of caution, Intent is not for everyone. :) It focusses a lot on guardrails and controls and what I call “critics”, that are concerned with code quality and using correct idioms, so #ymmv. But it does have a complete Multi-Agent framework that has served me pretty well for the last (almost) 12 months or so since I moved from a single-agent to multi-agent workflow.
[0]: https://intent.laksa.io/
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
Maybe if things weren’t relentlessly sucky in exactly the same way every god damn time, you wouldn’t have to hear the same critiques over and over again.
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?
How do you generate tasks for 200 workers?
"Solve The Riemann Hypothesis"
"Enough of partial results."
I’m actually genuinely curious about this as well. I’m saturated at low single digits where I run out of things I actually want.
Like I could definitely find ways to do it if someone is paying me to burn tokens (have 5 of the agents come up with busywork for the rest).
I had my agent add OpenRouter support and provider toggling and it took 15 minutes-ish on a single agent.
Some of me wonders if these are just deeply unoptimized projects and agent harnesses burning tokens because it sounds fancy. I can’t imagine why you would ever need 200 agents for a normal codebase unless 200 agents was the goal or the codebase is an absolute nightmare.
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).
One of the ways on napkin math certainly is more expensive.
Please stop working on new products and finally fix its weird reverse writing style. I pay for codex just to get it to rewrite the meaningless shit Claude writes.
It's a product to burn through tokens at an alarming pace
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.