Anthropic redesigned Claude Projects on September 17 around a persistent coordinator that can split a coding goal into cloud threads, send them to separate repository copies and branches, review their reports, and assemble the work into pull requests. The obvious reading is “Claude Code, but with more agents.” That misses the consequential part of the release.
Parallel cloud execution is not new to Claude Code. Claude Code on the web already ran isolated tasks in parallel in 2025, and the 2026 desktop redesign made a person the manager of multiple sessions. Projects changes who carries the coordination burden. A model now keeps the project conversation, decides how to decompose work, delegates it, and proposes how the pieces come back together.
That is a meaningful product shift, but it is not yet a proven productivity gain. Anthropic has not published an independent benchmark for accepted pull requests, review time, regression rate, or cost per completed project. The right scorecard is therefore not thread count. It is accepted, dependency-correct changes per reviewer-hour and quota unit. A coordinator earns its place only if it reduces the work between “a patch exists” and “the system should ship.”
RohitAI’s thesis: Claude Projects is a bet that coordination can become a product capability. The beta should be judged at the acceptance boundary, not by how impressively it fans out.
What Anthropic actually changed
The word “Projects” has carried several meanings. The original 2024 product grouped chats, uploaded knowledge, and custom instructions. The new Claude Code beta uses the same durable-workspace idea for software delivery. In one project conversation, the coordinator can break down a goal, start multiple cloud coding threads, inspect their returned results, and suggest an integration order.
Execution isolation: each thread receives a separate cloud Claude Code session, repository copy, and branch.
Shared project context: threads inherit the project’s files, repositories, instructions, and editable memory.
Delivery surface: threads can run tests, push commits, open pull requests, and react to review or CI feedback.
Coordinator role: the project conversation sees worker reports and can assign follow-up work; that is not the same as a complete independent trace of every worker step.
Continuity: the conversation remains available for a stream of work rather than ending with one coding session.
The current documentation also puts firm edges around the launch. It is cloud-only today. The beta is single-user, with no project or thread sharing and no organization-level project controls. Local execution is promised later, without a date. Changes to repositories, instructions, plugins, or environment settings affect new threads rather than retroactively reconfiguring work already running.
Availability is narrower than a generic Claude Projects feature list suggests. Anthropic’s support page says the redesign begins with select Pro and Max users in Claude Code, initially prioritizing cloud-session users who do not already have chat or Cowork projects. Broader Pro and Max rollout is planned first; chat, Cowork, Team, and Enterprise support comes later. Existing projects keep working, but a paid subscription alone does not guarantee the new sidebar today.
Documented in the beta | Not established by the launch |
|---|---|
Separate cloud session, repository copy, and branch for each thread | Transactional merges or conflict-free cross-repository delivery |
A coordinator can delegate work and propose sequencing | Independent review of every action or every patch |
Shared instructions, files, repositories, and memory | Instant correction propagation or versioned memory provenance |
Tests, commits, pull requests, and PR follow-up | Higher accepted-change throughput or a lower defect rate |
Staged access for select individual subscribers | Current Team or Enterprise governance support |
The merge queue is the benchmark that matters
Anthropic’s launch example is a multi-repository endpoint migration. That is a good demonstration because it exposes why parallelism is easy to oversell. Several agents can edit independent branches at the same time. The delivery remains serial wherever one repository’s contract, generated client, schema, or deployment must land before another change can be trusted.
A coordinator may reduce scheduling overhead by identifying dependencies and proposing merge order. It can also create a larger review queue faster than people can drain it. Ten plausible pull requests are not ten units of progress if a reviewer must reconstruct their shared assumptions, rerun integration checks after the first merges, and send half of them back for rework.
accepted delivery = changes that satisfy current requirements and independent checks
cost of delivery = agent usage + reviewer time + reruns + regressions
useful throughput = accepted delivery / cost of deliveryThis is the first non-obvious consequence of the redesign: reviewer capacity becomes the scarce concurrency limit. Requested agent concurrency is only a preference in the current product, not a hard cap. Even perfect execution fan-out cannot create more architectural attention, security review, or release-window capacity.
Treat every change as incomplete until it carries an acceptance packet: the base and head commits, affected repositories, test commands and results, known failures, dependency order, and the person or deterministic rule that accepted it. This extends the evidence-ledger argument from RohitAI’s analysis of managed coding harnesses. The project transcript is useful context; it is not the receipt.
The same distinction applies to review language. RohitAI’s Copilot approval analysis separates advice from authority: an assessment and a counted repository approval are different controls. A Projects coordinator saying that work looks ready is likewise not independent acceptance evidence, especially when coordinator and worker inherited the same project assumptions.
Adding a second repository can change the policy contract
The most operationally important caveat is buried in the cloud-environment carry-over rules. In a single-repository cloud session, repository-level .claude/settings.json permission rules and hooks can be loaded. In a several-repository session—including a project thread—the working directory starts above the cloned repositories, and those repository settings are not read the same way. The repository .mcp.json file follows the same working-directory distinction. Anthropic documents the matrix here.
Workspace shape | Repository policy behavior to verify | Pilot question |
|---|---|---|
One repository | Repository hooks, permission rules, and MCP configuration can load from the working repository | Does a forbidden command actually fail in the hosted environment? |
Several repositories | The session starts above the clones; do not assume each repository’s local settings were inherited | Which expected hooks and denials disappeared when scope expanded? |
Server-managed settings or enabled plugins | These are separate policy paths and should not be collapsed into the repository rule | Which control enforced the decision, and where is its audit record? |
This does not mean multi-repository Projects has no controls. Server-managed settings, enabled plugins, the environment configuration, GitHub permissions, and network rules are separate layers. It does mean that “we added the second repo for context” can quietly be a policy migration. Natural-language project instructions are not a replacement for a command denial or a hook that was expected to run.
The second non-obvious consequence is therefore concrete: workspace scope belongs in change control. Before widening a Project, replay a small suite of allowed and forbidden actions. Test network destinations, hooks, MCP servers, write permissions, and comment-triggered automation. Record the result against the exact environment configuration.
Branch isolation is useful, but it is only an editing boundary. A GitHub comment can trigger external automation, a connector can write outside the cloned repository, and a deployment hook can create state that a diff does not contain. Claude Code’s cloud documentation specifically notes that auto-fix replies can use the user’s GitHub identity, while a base-branch advance alone may not produce the webhook needed for automatic conflict repair. A clean branch is not proof that the run stayed inside its intended authority.
Shared memory is a correction-distribution system
Projects gives the coordinator and new threads a continuing context. The documented controls include up to 16,000 characters of project instructions and editable project memory organized through a MEMORY.md index. That can remove repeated onboarding: architecture notes, build commands, conventions, and unfinished decisions no longer have to be pasted into every session.
But continuity changes the failure mode. A bad assumption can stop being a local mistake and become a common cause across workers. Worse, an instruction correction applies to new threads; it does not rewrite the state of threads already running. The impressive memory test is not whether the system remembers an old command. It is whether every path that can act stops using that command after the owner replaces it.
RohitAI’s proposed memory metric: measure stale-rule reuse after a correction, plus the time until the final running or newly started thread stops acting on the superseded rule.
Run the test deliberately. Start two threads under requirement A. Change the authoritative requirement to B, mark A as superseded, then start a third thread. Ask all three to continue. A useful coordinator should expose which work still depends on A, cancel or repair it, and keep the acceptance decision tied to B. A polished summary that hides one stale branch is a failure.
Keep different kinds of state in different systems. Working notes can live in project memory. Requirements should point to an owner and authoritative specification. Approvals belong in the repository or change-control system. Test receipts should bind command, commit, environment, and time. Editable narrative memory can help locate those records, but it should not become the only copy of authority.
State | Best role for project memory | Authority that should remain external |
|---|---|---|
Working observation | Remember a hypothesis or one-run failure | Linked logs and the commit where it occurred |
Project convention | Help new threads find the current rule | Owned, versioned instruction or specification |
Acceptance decision | Summarize why a change was accepted | Review event, test gate, and exact commit |
Superseded assumption | Preserve a pointer to the replacement | Dated correction with an accountable owner |
Quota is now a backlog-admission budget
Every delegated thread consumes the user’s existing plan allowance. The product enforces a limit of 200 new threads per day across Projects; that is a creation limit, not 200 simultaneous workers and not 200 completed tasks. Cloud sessions do not carry a separate virtual-machine charge, but they share account usage with Claude and Claude Code. Optional usage credits add metered overflow at standard API rates and can be bounded with spending caps and auto-reload settings.
The timing matters. Anthropic’s updated capacity FAQ says the temporary 50% weekly uplift ended September 13 and a permanent 25% uplift over the older baseline began September 14. Put differently, the current allowance is 125/150, or 83.3%, of the summer promotion level—a 16.7% reduction from that temporary peak, while still remaining 25% above the earlier baseline. The FAQ has now resolved the date uncertainty noted in RohitAI’s August limit analysis. The promotion did not alter the separate five-hour allowance.
Max plans also retain separate five-hour and weekly limits; a “5x” or “20x” label describes usage relative to Pro, not agents, guaranteed throughput, or completed pull requests. Anthropic does not publish a universal token entitlement that can be converted into a Projects delivery forecast. Defaults currently use Opus for both coordinator and workers, with low effort for coordination and high effort for threads, but there is no public cost-per-accepted-project benchmark.
This is the third non-obvious consequence: the decision to fan out is a backlog-admission decision. A coordinator can spend tomorrow’s interactive capacity on today’s low-value branch. Teams should reserve capacity for urgent debugging, cap paid overflow at the account level, and stop obsolete attempts before resets rather than assuming the conversation’s concurrency preference is a financial control.
A transcript can survive after the work is gone
Persistent conversation and persistent artifacts are different promises. Anthropic says a recovered cloud session can restore conversation history while background processes from a reclaimed virtual machine are gone. Uncommitted work can be lost. Conversely, deleting a Project does not delete GitHub branches or pull requests already pushed from it.
That asymmetry should define “done.” A thread is not complete because its status says finished or because the coordinator can recount what happened. Completion requires a durable commit, retrievable artifacts, test evidence tied to that commit, and an acceptance state in a system the team already operates. The remote branch may outlive the workspace; the process and its uncommitted filesystem may not.
A two-week pilot designed to expose the weak points
Do not begin with an open-ended rewrite. Pick a real, reversible migration with a known denominator—such as replacing one endpoint across two repositories and twelve call sites. Run a comparable batch with manually coordinated cloud sessions so the Project has a baseline. Keep the model, acceptance tests, and reviewer expectations as similar as practical.
Write the acceptance contract. Name the repositories, allowed tools and destinations, forbidden changes, authoritative requirements, required tests, reviewer, budget, and stop conditions.
Prove the environment on one target. Confirm GitHub App access, push permissions, dependencies, network paths, hooks, denied commands, and the expected PR behavior before wider delegation.
Calibrate a small fan-out. Start with three representative targets, including one known exception. Record why each patch is accepted, rejected, or sent back.
Inject a correction. Replace an authoritative rule after work starts. Measure stale-rule reuse in running and new threads, and verify that superseded work is surfaced rather than silently merged.
Advance the base branch. Create a conflict that arrives without a review-comment or CI-failure event. Check how the coordinator detects it, requests a rebase, and invalidates stale test evidence.
Break continuity. Allow a sandbox to expire after a pushed checkpoint and again before one. Confirm exactly which conversation, process, commit, and artifact can be recovered.
Measure the human queue. Track review minutes, oldest PR age, rework after earlier dependencies land, and regressions—not only elapsed agent time or PR count.
Reconcile usage with outcomes. Attribute coordinator work, worker threads, failed attempts, overflow spend, and reviewer time to accepted targets. Stop if the queue or usage grows faster than accepted completion.
The minimum scorecard should include accepted targets per reviewer-hour, median review age, first-pass acceptance, regression rate, correction latency, stale-rule reuse, reruns after dependency merges, plan usage, paid overflow, and cost per accepted target. “It opened more pull requests” is not a success criterion.
Continue if accepted completion rises without worse regressions, stale-rule reuse falls quickly, and review load stays within the team’s budget.
Narrow the scope if policy behavior changes between one and several repositories, external effects are hard to attribute, or review age grows.
Stop if the team cannot reconstruct authority, evidence, and current assumptions from durable records without relying on the coordinator’s summary.
This is a category race, not a first-to-parallel claim
Anthropic did not invent parallel coding agents with this launch. Cursor documents a Projects coordinator with persistent shared files, parallel cloud agents, and event or schedule subscriptions. Devin documents parallel sessions used to explore competing solutions, including an illustrative three-session workflow that consumes roughly three times the ACUs of one session. Those are vendor descriptions, not head-to-head evidence that one product is faster, cheaper, or more reliable.
The useful comparison is contractual: who owns continuity, what policy survives a workspace change, which source-control systems and local dependencies are supported, how recovery behaves, what usage controls are enforceable, and what evidence reaches the reviewer. Cursor’s cloud agents support several source-control providers and multi-repository environments, while its own documentation says long-running mode is unavailable for multi-repository setups. Claude Projects requires GitHub.com, push access, and the Claude GitHub App. Product labels conceal different operating boundaries.
RohitAI’s market read is that raw agent count will stop differentiating these tools. The winning workspace will produce dependency-correct, review-ready changes with fewer stale assumptions and less reviewer reconstruction. That is a prediction, not a result established by this beta.
Who should test it now
The strongest early fit is a single developer with a continuing, bounded stream of GitHub work: a cross-repository migration, a related backlog of bugs, or a testing initiative where dependencies and acceptance criteria can be written down. The workflow should tolerate cloud execution, reversible branches, and a human review boundary.
Wait if the work depends on local-only services, organization-level sharing and controls, non-GitHub hosting, or consequential external actions that are not yet isolated. Use a standalone cloud session for one independent task, local Claude Code for machine-bound dependencies, and a Routine for narrow scheduled or event-driven work. Projects is justified when the continuing coordination itself is the problem.
The beta’s most important unanswered questions concern operating quality: independent acceptance rate, reviewer time saved, correction propagation, memory provenance, cross-repository conflict behavior, project-state export, and cost per accepted outcome. Broader enterprise rollout will also need a governance contract beyond today’s single-user surface. Anthropic has not given dates or guarantees for those answers.
The useful way to read the launch
Claude Projects is not important because one chat can summon several coding agents. That execution pattern was already available, and competitors offer related abstractions. The important change is that Anthropic has put a persistent coordinator above cloud coding sessions and made project continuity, delegation, memory, and PR sequencing part of one product surface.
That surface can remove real coordination toil. It can also preserve a wrong premise, spend a weekly allowance faster, alter policy behavior when a second repository is added, and deliver more patches than a reviewer can safely absorb. None of those risks makes the product a bad bet. They define what a serious evaluation must measure.
Do not ask how many agents Claude Projects can keep busy. Ask whether the workspace can carry a correction to every active path, prove which controls applied, survive a broken session without inventing completion, and hand a reviewer a small set of dependency-correct changes with durable evidence. If it can, Anthropic has reduced the hardest cost in agentic coding. If it cannot, the new coordinator has only moved the queue.
Frequently asked questions
Who can access redesigned Claude Projects?
The September 17 beta starts with select Pro and Max Claude Code users, initially prioritizing people who use cloud sessions and do not already have chat or Cowork projects. Anthropic says broader Pro and Max access follows, with chat, Cowork, Team, and Enterprise support later. Rollout dates and regions are not fully specified.
Does each thread get its own usage allowance?
No. Threads consume the user’s existing plan usage. The 200-new-threads-per-day limit applies across Projects and is not a concurrency entitlement. Max multipliers describe usage relative to Pro, not a guaranteed number of workers or completed tasks.
Can Claude Projects run locally?
Not in the current beta. Threads run in Anthropic-hosted cloud environments. Anthropic says local execution is coming, but it has not published a firm date.
Does the coordinator automatically make cross-repository changes safe to merge?
No such guarantee is documented. It can delegate work, run tests, open pull requests, inspect worker reports, and suggest merge order. Teams still need independent acceptance, dependency-aware retesting, conflict handling, and evidence bound to exact commits.