Claude Code's updated projects introduce AI orchestration, though local developers will have to hold off

If you build software with AI coding agents, especially several running at once, Anthropic's redesigned Projects feature for Claude Code is worth your attention. This update adds orchestration, persistent threads, and shared memory for developers working in the cloud. However, if your workflow lives on your local machine and terminal, like mine does, you'll need to wait for a future release.

Here's a breakdown of what changed, who benefits, and the open questions that remain.

What's New for Cloud-Based Developers

Claude Code has technically always had projects — any directory you designate as the root of your source code counts as one. I keep each app I'm developing in its own directory and have built a fairly elaborate system for shuttling messages between them. Beyond that, though, these codebases stay isolated from each other.

Anthropic's announcement changes that for cloud users. According to the company, "Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result. You can steer progress throughout, and it keeps working after you close your laptop."

Orchestration: Keeping Your Agents on Task

Anyone who has launched a batch of AI agents knows the core problem: keeping them all pointed in the same direction. Picture trying to herd twenty kittens through a small door in alphabetical order. It won't work, and the coordination failure will at least be adorable.

Coding agents present the same challenge, minus the cuteness. Getting multiple agents to collaborate toward a shared goal requires orchestration — essentially a management layer that sits above the individual prompts. The revamped Projects feature supplies exactly that.

Each conversation becomes its own full cloud session, complete with its own branch and copy of the repository. Anthropic suggests briefing Claude on your project "the way you'd brief a chief of staff, and it routes work to new or pre-existing threads."

Because threads have names, you can intervene mid-run. You can open a thread that's actively working and redirect it, rather than letting it burn through tokens to completion only to deliver something you already know is off track.

Shared Memory and Cross-Repo Work

Threads can also learn from one another. Anthropic explains: "Over time, Claude learns more about the project details and applies them to its work. Every thread now adds to and draws from a shared memory, reducing the need for complex prompt engineering."

In the right context, this kind of automated memory can be genuinely powerful. It also enables work spanning multiple repositories — you can run a thread per repo simultaneously, then ask Claude which pull requests should be merged and in what order.

And since everything runs in the cloud, you can shut your laptop and let the work continue. Anthropic has also said mobile check-ins are on the way.

What Isn't Actually New

Some perspective is needed here. This update doesn't introduce a new form of parallelism. I've been running swarms of subagents for some time, and Anthropic itself notes the new Projects architecture uses that same subagent structure internally.

Claude could already divide work across subagents. What's different now is that the split persists — you can return to each subagent's discussion and keep talking with it.

It's also worth noting the feature doesn't appear fully autonomous. Based on what's been described, threads seem to start only after you press the Start button on each thread Claude recommends.

Most importantly for people like me: local development isn't supported yet. Anthropic says local execution — running threads on your machine alongside your tools, code, and network — is "coming very soon." The terminal experience itself isn't going away; this is an addition, and nothing in the announcement suggests any changes to local or CLI behavior.

Three Concerns Worth Weighing

While evaluating this update, three issues stood out to me:

Memory remains a black box. The announcement says little about how memory actually works. There's no obvious way to inspect what Claude has stored, fix it when it's wrong, or export it — and no details on how long anything is retained.

Costs scale with your agent fleet. Anthropic is upfront about this: "Projects can run several threads at once, and each one is a full Claude Code session. Because of this, projects reach usage limits faster." I've personally hit cutoffs after running a fleet of agents against my code.

Merge conflicts aren't prevented — just delayed. When threads overlap, you'll still face manual conflict resolution eventually. The conflicts don't disappear; they just arrive later.

Open Questions for Anthropic

I have plenty of questions, especially for when this reaches desktop users. Here are the top three:

1. When a project outgrows its context window — mine do every few hours — what happens to the shared memory? Can users see what was retained? Does it end up in .md files somewhere?
2. Is project history maintained automatically, and can it be exported with prompts intact? My own memory system requires Claude to log every prompt I issue, which serves as both an engineering audit trail and a record of conception and inventorship.
3. When local projects gain this capability, will they inherit memory, permissions, and hook behavior? How will it integrate with existing memory systems and mature, long-running projects?

Judging by Anthropic's statement that the feature targets those who "don't have any existing projects on the web and desktop," migration support clearly isn't solved yet.

If you could redirect a running Claude Code thread before it wandered off course, how would that change the way you work with coding agents? Let us know in the comments.