Correction, October 13, 2026: Parallel threads can reach plan limits faster; they do not guarantee higher usage for every task. Separate branches can still conflict when changes are merged.
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. Earlier Claude projects primarily grouped context. The redesigned experience first enters beta through Claude Code. 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 can be reviewed before merging into 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 initial beta had limited access
This is in beta, and access is limited. The September 17 announcement offered it 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 planned to expand access to more Pro and Max users over the following week, with Team and Enterprise plans 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 consumes the usage allowance available on your plan. If you’re already close to your usage limit in normal Claude Code sessions, several simultaneous threads can reach the cap sooner. Check actual usage rather than assuming the same cost for every split task.
Threads also 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 extra sessions can consume allowance without saving enough time.
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, start with a specific task, such as updating three or four files that still call a retired function. Check the project-specific usage as the coordinator opens threads, and review each proposed change before merging.
Judge whether parallel work saves time after accounting for the allowance consumed and the fixes you need to make. A task split across several threads can finish sooner while still leaving substantial review work.
Review every thread’s pull requests before merging. Separate branches prevent direct file collisions, but overlapping changes can still produce merge conflicts. The coordinator directs the work, but nothing here removes your role as the person who approves what ships.
End of article