Anthropic has re‑engineered Claude Projects to include a coordinating agent that automatically splits a developer’s goal into multiple parallel Claude Code sessions, each running on its own branch. The change also adds shared memory across threads and makes token consumption rise faster because every thread counts as a full Claude Code session.
Parallel coordination and token consumption
The new coordinator receives a high‑level engineering request, decides how to partition the work, and launches separate Claude Code cloud sessions for each piece. Each session operates independently, using subagents, loops, and workflows as needed. Because every session is billed as a full Claude Code instance, projects that run several threads in parallel will reach their plan limits more quickly than before. Users can select the model and effort level for both the coordinator and the worker threads, and they can monitor project‑specific usage through the interface.
Branch isolation, merge conflict handling, and shared memory
Every thread works on its own repository branch, which isolates changes but does not prevent two threads from editing the same file. When overlapping edits occur, Anthropic treats the situation as a standard merge conflict, similar to a pull‑request conflict, and requires resolution before integration. The redesign also introduces shared memory, allowing information captured in one thread—such as a revised release date, a feature‑drop rationale, or an approver list—to be automatically available to other threads without the developer re‑supplying context. A new library stores user‑added files alongside Claude‑generated artifacts, making them reusable for subsequent work.
Operational and security considerations
Practitioners need to account for the accelerated token burn when planning capacity for Claude Pro or Max subscriptions. The class‑action lawsuit alleging undisclosed usage ceilings highlights the risk of unexpected plan exhaustion. Monitoring usage per project becomes essential to avoid service interruption. The upcoming ability to run threads locally, including against resources behind private networks, expands deployment flexibility but also introduces new surface area for access control and data leakage; organizations should evaluate how local execution aligns with their security policies.
Because each thread creates its own branch and may open pull requests automatically, existing CI/CD pipelines and code‑review gates will be exercised as usual. Teams should verify that automated PRs from Claude sessions satisfy their compliance and audit requirements. The shared memory feature reduces repetitive prompting but also means that contextual data persists across sessions, which could inadvertently expose sensitive information if not properly scoped.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
- Track token usage at the project level and set alerts before hitting plan limits.
- Review merge‑conflict handling policies to ensure automated PRs from parallel threads are vetted.
- Validate that shared memory does not retain confidential data beyond its intended lifespan.
- Plan for the upcoming local‑execution capability by reviewing network segmentation and access controls.
- Stay informed about the rollout schedule for broader plan availability, mobile support, and team/enterprise access.
