What happened
Anthropic redesigned Projects in Claude Code on September 17, moving it from a folder you drop files into toward a system where you hand Claude a goal and it manages the work itself.
Claude Code is Anthropic’s coding agent: you describe what you want built or fixed, and it writes and runs the code for you instead of you typing every line. Until now, a Claude Code “project” was mostly a shared folder of context. The new version adds two moving parts on top of that: a coordinator and threads.
You give the coordinator a goal and connect a repository (the stored history of your project’s code) or some documents. The coordinator suggests work it can start right away, then splits that goal into pieces and hands each piece to a thread. Each thread is a full, separate Claude Code session running in the cloud, working on its own copy of the code on its own branch (an isolated line of changes that doesn’t touch your main code until it’s merged in). A thread can open a pull request, a proposed code change that waits for your review before it becomes part of your project, and run your tests before flagging it as ready.
Anthropic’s example: set a goal to cut a specific page’s load time, and Claude checks how slow each part of the app runs, tests fixes, and opens pull requests in parallel, one per fix, instead of you working through them one at a time in a single chat.
The rollout is narrow right now
This is in beta, and access is limited. It’s available today to some Claude Pro and Max subscribers who already use Claude Code’s cloud sessions (meaning your code runs on Anthropic’s servers, not just your own machine) and who don’t have any existing projects yet on web or desktop. Anthropic says it will open access to more Pro and Max users over the coming week, with Team and Enterprise plans getting it later. If you’re on Pro or Max and don’t see it, Anthropic has a waitlist rather than a way to turn it on yourself.
The usage catch
Every thread is a real Claude Code session, not a lightweight helper. If the coordinator opens four threads to work on four pieces of your goal at once, that’s four sessions running against your usage allowance simultaneously, on top of the coordinator’s own chat. Anthropic says directly that projects can hit your usage limit faster than working in a single chat, and that you can check project-specific usage and pick the model and effort level (how much time and reasoning it spends before answering) for the coordinator and for each thread separately.
That’s the tradeoff to weigh before turning this on for real work: parallel threads finish more pieces of a goal at the same time, but each one draws down the same weekly or monthly allowance your plan gives you. If you’re already close to your usage limit in normal Claude Code sessions, running several threads on a project will get you there faster, not slower.
There’s a second thing worth watching: threads share memory. Claude keeps notes across every thread in a project, like a release date changing or who to check with before touching a particular service, so a new thread doesn’t start from zero. That’s useful when every thread works on the same codebase. It’s worth a second look if you connect a project to multiple repositories with different sensitivity, an API repo and a payments repo, for example, since context one thread picks up is available to the coordinator and to other threads in the same project.
Who should care
This is aimed at people who already run Claude Code and have work that spans more than one sitting: a migration across several files, a bug that needs profiling before you know the fix, or recurring maintenance you currently split into separate chats yourself. If your Claude Code use is short, one-off edits you review immediately, a coordinator and multiple threads is more machinery than the task needs, and you’ll pay for sessions you didn’t need to run in parallel.
This isn’t the only coding agent moving toward one coordinator directing many working sessions. Cursor shipped its own version of this pattern last week, with a coordinator directing subagents instead of full sessions. The two tools split the work differently under the hood, but the direction both are heading is the same: less time spent babysitting one chat, more time spent deciding what to hand off and checking what came back.
What builders should do next
If you get access, don’t hand the coordinator a broad, open-ended goal on your first run. Pick one bounded task you’d normally do yourself across a few Claude Code chats, something like updating every place in three or four files that still calls an old function you’ve retired. Do it once the normal way, in a single chat, and note how long it takes and how many times you had to correct Claude’s work before it was ready to merge.
Then run a similarly sized task through a project instead. Compare two things against your single-chat run: how much of your usage allowance the parallel threads consumed to reach a mergeable result, and how many of the opened pull requests needed manual fixes versus how many you could merge as written. That tells you whether the parallel threads bought you real time, or just spent your allowance faster to arrive at the same amount of review work.
Review every thread’s pull requests the way you’d review any other, before merging. The coordinator directs the work, but nothing here removes your role as the person who approves what ships.
End of article