The beta dropped on September 17. Claude Code Projects, rebuilt. What used to be a single-session coding experience — one Claude, one conversation, one branch — is now a coordinator and up to 200 worker threads per day, each thread a full cloud session, each running on its own branch, each persisting after you close your laptop.

The version of this I find most interesting isn't the feature list. It's the bet underneath it.

Context window expansion, the other major direction for handling complex long-horizon work, says: give the AI more room, let it hold more context at once. The parallel threads model says something else. It says the bottleneck isn't what the model can hold. It's serial execution. Don't make one session longer; make ten sessions run at the same time. And then coordinate them.

Both arguments are probably right for different workloads. But the two bets produce different products, different cost structures, different failure modes. Worth knowing which one you're buying.

How it works

A coordinator — itself a Claude Code session — reads your natural-language goal and divides it across parallel worker threads. You don't write a task graph or specify dependencies. You describe what you want done and the coordinator figures out the decomposition. Each thread gets its own branch and a full copy of the relevant repo. Threads run tests, open PRs, and keep running when you close your laptop.

When two threads touch overlapping code, you get merge conflicts, same as you would from a human team. No silent overwrites. The coordinator tracks what's in flight and assembles the result as threads complete.

The "always-on" framing is the part I find most operationally meaningful. The old model tied execution to your local process. Close the laptop, stop the work. Here, the sessions live in Anthropic's cloud, detached from your machine. You hand off a multi-hour migration before dinner and come back to PRs.

The "pays in parallel" framing — that's The Register's phrasing, and they're right to flag it. Each thread is a full Claude Code cloud session. If you run five threads simultaneously, you're consuming credits at five-session speed. The plan allowances don't stretch to cover parallelism for free. This isn't a complaint, exactly. It's just the honest cost model that Anthropic didn't lead with in the announcement.

Source spread

• VentureBeat — launch coverage [builder] — strong on the coordinator mechanics, git workflow, and "always-on" framing; read this first
• The Register — pricing and credit burn [skeptic] — correctly surfaces the "you work and pay in parallel" dynamic; the headline is the take
• MarkTechPost — beta availability details [builder] — covers rollout sequencing and which users are eligible in the current wave
• XenoSpectrum — coordinator and thread architecture [builder] — good on the coordinator-as-Claude-session detail and the multi-agent coordination design

What's real:

• The coordinator automates the decomposition step. If you've been manually breaking down feature requests into tasks for Claude, this moves that work up a level. The coordinator reads a goal description and subdivides it without you specifying the dependency graph. Whether it does this reliably on complex, real codebases is the open question — but on the happy path, it saves a meaningful amount of setup work.
• Persistent execution is a genuine workflow category change. Background sessions that keep running independent of your local process mean multi-hour tasks that previously required a laptop staying awake can now be handed off. For database migrations, large refactors, and cross-repo work, this matters more than the parallelism does.
• 200 threads/day is generous for real projects. A typical feature branch or targeted refactor probably runs 5–15 threads in a session. To hit the cap you'd need a very large, highly parallelized codebase task — or a lot of small tasks back-to-back. Most builders won't see this limit.
• Git-native conflict handling is the right design. Merge conflicts, not silent overwrites, when threads collide. The coordinator produces git-legible work. This is important: the output isn't an opaque blob, it's PRs you can read and merge like any other code review.

What deserves a side-eye:

• Beta eligibility is narrow. Available now to select Pro and Max subscribers using cloud sessions who don't have existing projects. If you have an existing project, you're on the waitlist for migration. Team and Enterprise access comes next week. Until then, the most likely users of this are people starting fresh.
• "No new pricing tier" is technically true. It's also slightly incomplete. Parallel threads burn credits in parallel. If your current plan is sized for one active session at a time, you may need to rethink your usage patterns or upgrade before running large parallel jobs. Model this before committing a big run.
• The coordinator quality hasn't been independently evaluated. The demos are first-party and show clean decompositions on well-defined goals. Whether the coordinator produces good task breakdowns for messy, real-world codebases with unclear ownership boundaries is an empirical question the beta period will start to answer. I'd weight my own experience over the launch demos.

What builders need to know

• Check eligibility now, not when you need it. Beta is limited to Pro/Max users on cloud sessions without existing projects. If you have an existing project, you're waiting. Find out now which bucket you're in.
• Model your credit burn before running large parallel jobs. Five parallel threads at once consumes plan credits at five-session speed. Start with 2–3 threads on a small test task to calibrate what a full run will cost you before committing a migration or large refactor.
• Write goal descriptions like you'd write a brief for a junior team. The coordinator works from your natural-language goal description. Vague goals produce vague decompositions. "Migrate the auth module from JWT to Clerk, including updating the existing test suite and the two endpoints in users.ts that currently bypass auth" is better than "migrate auth." The specificity you'd put in a task ticket is the right specificity here.
• Treat the merge conflicts as the quality signal. If your parallel threads are producing a lot of conflicts, the coordinator probably decomposed the task poorly — or the task was too coupled for parallel execution to help. That's useful information. Tune the goal description before re-running.
• Team and Enterprise access is coming next week. If you're evaluating for a team context, wait for that tier. The beta restrictions around existing projects will also relax as the rollout widens.

Further reading

• VentureBeat — Anthropic launches Claude Code Projects — full launch coverage with technical mechanics
• The Register — Claude Code revamps projects — the pricing and credit burn analysis
• MarkTechPost — beta availability and rollout — who can use it now vs. next week
• Claude Code What's New — Anthropic's official weekly digest with the feature-by-feature breakdown