Anthropic is changing Claude Projects from a place to organise context into a place to coordinate ongoing work. Announced on 17 September, the redesigned experience uses a main conversation to direct separate threads, each carrying out part of a larger assignment. The beta starts with selected Pro and Max subscribers using Claude Code cloud sessions, with a staged rollout rather than immediate access for every subscriber.
The announcement says existing projects continue working during the transition. Wider availability, including Team and Enterprise, comes later. It also distinguishes the initial cloud-based threads from a planned local execution option. Those qualifications matter: this is not a general release of an agent that can already reach every tool on a developer's laptop.
One conversation, several pieces of work
The practical change is who does the coordination. When a developer runs several independent sessions, someone must decide how to divide the task, repeat the background and reconcile the results. A coordinating project offers a different interface: describe the goal once, then use the main conversation to guide the work as separate threads progress.
The project documentation describes a coordinator that receives reports from workers rather than seeing every step they take. Threads share project instructions and memory but work in their own contexts and branches. An Overview pane separates completed work from tasks waiting for the user's answer, while other areas collect files and pull requests.
That design could be useful for a migration spanning several repositories, where each codebase needs a related change but has different tests and release considerations. It does not make the repositories interchangeable. A good brief still needs to identify what must remain compatible, which interfaces may change and what evidence would demonstrate success.
For example, a team retiring an old endpoint could specify its replacement, name the affected services and ask for independently reviewable changes. The useful output would be more than several patches: it would include test results and an intelligible order for integrating them. This is an illustrative evaluation task, not a claim that the beta guarantees a successful migration.
Shared context is not shared omniscience
The documentation also makes clear that project threads do not automatically inherit the Claude Code setup on a user's machine. Repositories, account connectors and the configured cloud environment provide their working context. Files or tools available only locally therefore need separate consideration. Uploading a document and giving an agent access to a private service are not equivalent actions.
This is a useful boundary to establish before a trial. A team should list the inputs the task requires and check where each one lives. If the workflow depends on a local database or an internal service unavailable to the selected environment, that gap should be resolved explicitly rather than left for the agent to discover halfway through the assignment.
Memory introduces a related review question: which decisions should persist? A temporary workaround should not quietly become a permanent project rule, and a remembered preference should not override a newly supplied requirement. Teams evaluating long-running assistance should look for a clear way to inspect and correct the context being carried into later work.
Cloud execution still needs a review process
Anthropic's cloud-session guidance explains that cloud work can continue after the laptop closes. It also distinguishes that execution from a local session controlled remotely. Hosted sessions use isolated environments, but isolation should not be confused with an absence of data movement: the documentation notes that communication with Anthropic's API remains possible even when general network access is disabled.
The same guidance says cloud sessions share account usage limits with other Claude and Claude Code activity. Parallel work can therefore consume those limits more quickly. Developers should evaluate the total work produced and the review effort required, not just the number of simultaneously active threads. A larger queue is not automatically a faster route to a releasable change.
Branches also provide separation without eliminating integration risk. Two individually sensible changes can make incompatible assumptions about a shared interface. Reviewers still need to inspect the combined result and run the tests that exercise interactions between components. Delegating implementation changes the distribution of work; it does not remove the need for someone to own the release decision.
A bounded pilot gives the clearest answer
A useful first project would have a recognisable finish line, a small set of repositories and tests that a reviewer already trusts. It should also define which actions require approval. That makes it possible to assess whether coordination really improves, instead of simply generating more activity to supervise.
The beta is most interesting as an attempt to organise work that outlasts one conversation. Its value will depend on whether the coordinator makes progress, dependencies and unresolved questions easier to understand. For now, eligible users have a new way to test that proposition, while everyone else should treat the staged access and environment limits as part of the announcement, not incidental fine print.