Claude Code Rebuilds Projects Around a Coordinator Directing Parallel Threads

Anthropic put a rebuilt projects feature into beta in Claude Code on September 17, 2026. Set a goal and a repo and a coordinator carves up the work, with each thread opening PRs on a branch of its own. Because they run in parallel, Anthropic says usage limits arrive sooner.

Claude Anthropic coding AI-agents multi-agent developer-tools

On September 17, 2026, Anthropic rebuilt the projects feature in Claude Code and put it into beta¹. Point it at a goal and a repository, and Claude works out the scope of the request, hands the work out, keeps the parallel threads in step, checks what comes back, and assembles the finished result.

The way it worked before, the company says, left the user to split the work up themselves across multiple sessions, manage the handoffs, and sew the results together at the end. The pitch now is that writing down what needs finishing is enough, and Claude takes the managing side. Progress can be steered from a phone, and the work carries on after the user walks away from their computer.

Threads do the work, the coordinator points them at it

A project is made of threads that carry out the work and a coordinator that directs them¹.

Starting one means picking a goal plus either a repository or some other context. Claude opens by suggesting work it could take on immediately. Cloud environment, connectors, plugins, instructions, and model are all set per project. Progress can be watched from the project’s main chat, or followed into an individual thread to inspect and correct the details. Brief the project’s Claude the way you would brief a chief of staff, Anthropic writes, and it routes the work to threads new or existing.

The internals are stated plainly. Every thread is itself a Claude Code cloud session, on a branch and a repository copy of its own¹. The coordinator handles keeping the work in order, but when two threads touch the same code, that overlap shows up as a merge conflict, no different from any other PR. A thread can also break down what it was handed further, using subagents, loops, and workflows.

With a repository connected, a thread opens pull requests and runs the tests; given documents, it reads them and drafts. The examples are concrete. Set a goal of bringing down the p75 latency on an app’s checkout, then have profiling of each endpoint, trials of optimizations, and the resulting PRs proceed in parallel threads. Or connect the API, web, and mobile repositories and set a goal of retiring a v1 endpoint that has been deprecated: Claude raises one thread per repository to move the callers over, run tests, and open PRs, then says which ones have to merge first¹.

Shared memory and a library accumulate across the project

Anthropic frames the feature as being for long-running, agentic workflows: work that will not fit into a single reply and that comes in more than one piece.

Two mechanisms carry that. One is a shared memory that every thread writes into and reads back from, which the company says reduces the need for elaborate prompt engineering. The examples it gives of what gets remembered are mundane and practical: that the release slipped to Friday, the reason the export got cut, whom to ask before anyone touches the billing service. It also picks up the user’s working and communication habits, and can be told how often to check in, how readily to open new threads, and how much detail to put in each update.

The other is a library, which gathers the files the user adds together with the artifacts Claude turns out, so relevant material is easier to find and later work can build on what came before.

This shape — a coordinator over parallel subordinate agents with a shared context — closely resembles the Projects feature Cursor put into beta on September 10. The designs are not identical, though. Cursor was explicit that its coordinator writes no code itself; in Anthropic’s description the coordinator’s duties include reviewing outputs and assembling the result, and nothing says it refrains from writing. Anthropic, for its part, is the one that spells out that threads hold their own branch and repository copy and that collisions land as ordinary merge conflicts.

There is a reason to spell that out. An experiment Anthropic itself published in August showed 18 of 30 agents creating the same branch name, one of several failure patterns in which similar agents converge on the same decision. The new design reads as an answer to that problem: push the collision down into a merge conflict a human can review.

Running in parallel means hitting the ceiling sooner

What deserves checking before adoption is availability and consumption.

On day one the feature reaches only a subset of Pro and Max subscribers — those using cloud sessions in Claude Code who have no existing projects on web or desktop¹. Over the following week it widens to more Claude Code users on those plans, with the rollout across all of Claude and to Team and Enterprise plans coming after that. Pro and Max users without access yet can join a waitlist. Existing projects keep running as they are and get upgraded as the rollout reaches chat and Cowork. The Verge notes that availability later extends to Cowork and ordinary Claude chats as well².

On consumption, Anthropic posts its own warning. A project runs several threads at once and each is a complete Claude Code session, so usage limits can arrive sooner than expected¹. What it offers against that is per-project usage figures, plus a choice of model and effort level set separately for the coordinator chat and for the worker threads.

That is worth reading against the timing: the weekly limit calculation changed on September 14. Raise the degree of parallelism on the same plan and the time it takes to reach the ceiling naturally shrinks. Rather than handing over a production migration whole, the sensible order is to hold the thread count and the model-and-effort combination down on a small job first and get a feel for what it consumes.

The other constraint is where the work happens. Threads run in the cloud for now; running them on your own machine, next to local tools and code and inside your own network, is described as coming “very soon”¹. Anything that depends on a local environment or an internal network has to be chosen around that for the moment.

Tool vendors taking over the management of long-running agents is the same direction OpenAI took by putting its managed Codex harness into public beta as the Agents API. What stays with the user is the design work: which goals to hand over and how closely to check the result. Whether this feature is pleasant to use comes down to settling the usage ceiling and the review line in advance.