One request in Claude Code can now fan out into several full cloud sessions, each working on its own branch and drawing on the same rate limits as other Claude Code activity. That is the consequential detail in Anthropic's rebuilt Projects feature. The company has packaged orchestration into a chat, while the compute draw and merge surface still grow with every worker it creates. Anthropic says projects with several threads can reach usage limits faster in its launch post, and its earlier web announcement confirms that cloud sessions share rate limits with other Claude Code activity.
Anthropic released the new Projects experience in beta on September 17. A project has a coordinator, a goal, shared memory, a library of files and artifacts, and multiple threads that can run at the same time. The Verge's report describes it as a relaunch of Projects for managing several agents in one place. The product changes an older folder-like container into an active manager that can divide a request, assign the pieces, review the results, and assemble an answer.
That sounds like a small interface change until you look at the execution model. Each thread is a Claude Code cloud session with a separate copy of the repository and a separate Git branch. A thread can run tests and open a pull request. It can also split its assigned work again through subagents, loops, or workflows. Anthropic's description therefore puts a coordinator above a set of already capable coding sessions, rather than adding a task list beside one assistant.
A project now does the dispatching
A developer starts with a goal and chooses a repository or other context. The project's environment, connectors, plugins, instructions, and model are configurable. Claude then suggests work it can pick up, routes tasks to new or existing threads, and reports through the main project conversation. The user can stay at that level or open a worker thread and steer it directly, according to Anthropic's product announcement.
The distinction matters because parallel Claude Code sessions already existed. When Anthropic launched Claude Code on the web in October 2025, users could start several isolated tasks and watch them from a browser. The developer still had to decide which task belonged in which session and reconcile the output. Projects assigns that planning and routing to another Claude process, then keeps the related sessions under one goal.
Anthropic uses two examples that reveal the intended scale. One asks a project to reduce checkout p75 latency by profiling endpoints, testing changes, and opening pull requests in parallel. The other connects API, web, and mobile repositories so separate threads can retire a deprecated endpoint, test each caller, and report the required merge order. Both examples give the coordinator boundaries before work starts: endpoints in one case and repositories in the other, as shown in the launch post.
Branches isolate work, then Git settles the overlap
A branch per thread prevents two workers from writing into the same working tree at the same instant. It does not make their changes compatible. Anthropic says overlapping edits are handled as an ordinary pull-request merge conflict. That sentence in the Projects announcement is the clearest limit on the feature: the coordinator can organize work, but Git still exposes collisions when workers touch the same code.
The most suitable jobs are therefore separable ones: profiling several endpoints, migrating callers in different repositories, or investigating independent failures. Anthropic gives similar advice for its smaller Claude Code subagents, saying parallel work fits tasks without dependencies. A tightly coupled refactor may gain less because every early decision can change the assumptions behind another thread's patch. That is an inference from the branch model, not a performance claim from Anthropic.
Projects also sits above Claude Code's existing agent layers. A subagent has its own context window, completes a bounded assignment, and returns a result to the main session. Anthropic says subagents cannot talk to one another. A Project thread is a full cloud session with its own branch, and that thread may create subagents of its own. Anthropic's subagent guide calls separate communicating sessions heavier and more expensive than subagents, which helps explain why Projects exposes usage controls.
For a team, the review unit remains the pull request. The documented workflow keeps tests and pull requests in the loop. A coordinator can inspect the output and suggest which changes should land first, while the release materials leave overlapping edits to Git's normal conflict process. The Verge reports the same branch-level limit.
Shared memory carries decisions between threads
Every thread contributes to and reads from a common project memory. Anthropic says it can retain details such as a moved release date, the reason a proposed export was dropped, or the person who must approve changes to a billing service. A project can also remember how often the user wants updates and how readily it should start another thread. Files supplied by the user and artifacts produced during the work collect in a shared library. Those are the continuity features listed in Anthropic's announcement.
That shared record addresses a common failure in parallel sessions: each worker begins with only part of the decision history. A new thread can draw on earlier conclusions instead of asking the user to repeat them. Yet memory also becomes part of the project's operating state. A stale decision could influence several later threads, so teams will need to learn how visible, editable, and well-scoped that memory is in practice. Anthropic's launch post explains what the memory can retain but does not document those management details.
The library performs a different job. It holds source material and generated artifacts that later work may need. Memory carries distilled decisions and preferences. The library preserves the actual files and outputs. Anthropic presents both as cumulative across a week of requests, with each new thread building on the same project history. That makes Projects closer to a persistent work room than a temporary batch of chat tabs, based on the company's product description.
Parallelism spends the same allowance faster
Each Project thread counts as a full Claude Code session. Anthropic warns that several concurrent threads can exhaust usage limits sooner and provides project-specific usage reporting. Users can choose the model and effort level separately for the coordinator and worker threads, according to the launch announcement. Decomposition is therefore a budget decision as well as a planning decision.
The underlying cloud service has always shared its allowance with the rest of Claude Code. Anthropic's 2025 web launch says browser-based sessions use the same rate limits as other Claude Code activity. Projects makes it easier to start more of those sessions from one request. A developer who previously opened two workers manually can now let the coordinator create several, and the convenient interface can make the consumption less obvious until the project meter moves.
Model controls offer one way to manage that tradeoff. A team could reserve a stronger model or higher effort for the coordinator and use a lighter setting on routine workers, or reverse that allocation when implementation is difficult and routing is simple. Anthropic confirms that both roles have selectable model and effort settings, though it has not published a recommended configuration or comparative cost figures for Projects in the announcement.
The beta starts in the cloud
Access is narrow on day one. Anthropic says the redesigned Projects beta is initially going to selected Pro and Max subscribers who use Claude Code cloud sessions and have no existing Projects on the web or desktop. More users on those plans are due to receive it over the following week. Team and Enterprise access, along with use across regular Claude and Cowork, will come later. Existing Projects continue in their current form until the rollout reaches them, according to Anthropic's release details.
All threads currently run on Anthropic's infrastructure. The company says support for work on the user's machine, including local tools, code, and resources behind a private network, is coming soon, without giving a date. For today's cloud sessions, Anthropic's web architecture overview says each task runs in an isolated environment with file-system and network restrictions, while Git access passes through a proxy limited to authorized repositories. Users can allow specific domains when a task needs to fetch packages or reach another service.
The cloud-only start leaves an important adoption boundary. Repositories that build entirely inside Anthropic's environment fit immediately. Work that depends on an internal package registry, a private staging service, specialized hardware, or local developer tooling may need network configuration or may have to wait for local threads. The Projects post promises local operation, while the older web documentation describes the controls available to cloud tasks today.
The next useful evidence will come from ordinary engineering work: how often the coordinator chooses clean ownership boundaries, whether shared memory is easy to correct, how much extra usage survives code review, and whether the pull requests arrive in a workable order. Anthropic has made dispatch cheap enough to happen inside one conversation. The test is whether those branches form an ordered set of reviewable changes, rather than a faster queue of conflicts. Until local execution lands and the beta reaches teams with existing Projects, those results matter more than the number of agents shown on screen. Anthropic's rollout note leaves both steps pending.