Anthropic upgrades Claude Code Projects to run parallel AI workers

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.

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.

So much cognitive overhead just managing that, this is so much better.

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.

(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.

Besides the nicer UI, what other advantages are there over my current flow?

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.

So far I would say it’s a welcome new behavior, but a noticeable change (Opus-5-5 at xhigh).

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 think you are solving for the right problem. Excited to see what this brings in the future.

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.

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.

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.