What Changed on September 17
Anthropic redesigned Projects in Claude Code on September 17, 2026, converting what used to be a static folder of reference files into a multi-agent coding system. Now a project is a single conversation with a coordinator that breaks your engineering goal into pieces, delegates them to parallel cloud threads, reviews the results, and assembles the finished work.
If you’ve been running multiple Claude Code sessions manually — splitting the work yourself, tracking handoffs, recombining results — this redesign automates exactly that overhead. You describe the goal; Claude manages the execution.
How the New Projects Work
The coordinator
One conversation sits at the center. You give it a high-level goal — “reduce checkout p75 latency” or “retire the deprecated v1 API across three repos” — and the coordinator scopes the request, creates threads, assigns tasks, monitors progress, and merges results. It doesn’t write the code itself; it manages the workers that do.
The threads
Each thread is a full Claude Code cloud session running on its own branch with its own copy of the repository. Threads run in isolation and can further decompose their own assignments into subagents, loops, and internal workflows when the work is large. When two threads touch the same code, the collision surfaces as an ordinary git merge conflict — the same model as a pull-request workflow, which means your existing review habits transfer directly.
Shared memory and the library
Two features keep parallel work coherent:
- Shared project memory carries decisions, context, and communication preferences across all threads for the project’s lifetime — the moved release date, the dropped export, which team to check with before touching billing. Information that used to die between sessions now persists.
- A project library organizes files you upload alongside artifacts Claude generates — design diagrams, implementation plans, research notes.
Human approval still required
Threads run in auto mode, but Anthropic built the guardrails deliberately: a second model (the classifier) reviews actions, and the default block list includes merging a pull request no human has approved, approving Claude’s own pull requests, disabling CI checks, force pushes, and production deploys. Threads open PRs; people merge them.
The Cost Reality
Here’s the part to read twice: every parallel thread counts as a complete Claude Code session against your usage limits. Running four threads simultaneously can exhaust your plan limits roughly four times faster. Anthropic says this explicitly — parallel threads reach usage limits faster.
This makes the feature a trade-off, not free leverage:
- Worth it: sprint weeks before deadlines, large refactors with independent modules, prototype spikes where parallel exploration beats sequential polish, multi-repo migrations.
- Not worth it: routine single-file tasks, exploratory work where you’d iterate anyway, anything on a tight usage budget.
You can assign different models or effort levels to the coordinator versus worker threads — a cheaper model for the coordinator and full power for the threads, for example — to tune cost against quality. Monitor project-specific usage as you go.
Who Gets Access
The beta opened September 17 for select Pro and Max subscribers using Claude Code cloud sessions, with wider Pro/Max access rolling out over the following week. Team and Enterprise plans come later — Anthropic hasn’t given a date.
Note the distinction that trips people up: this redesign is for Claude Code Projects (at claude.ai/code, the desktop app’s Code tab, and mobile). Existing Projects in the regular claude.ai chat app and Cowork continue working as before. The updated experience reaches the rest of Claude’s surfaces after the Code rollout.
Setting Up Your First Project Well
Write the project instructions field. It’s up to 16,000 characters, sent to every new thread and the coordinator — and it starts empty. A useful brief covers: what the project is for, where the work happens, how a thread verifies its own work before calling it done, what to do when something’s missing, and what needs your go-ahead first. The acceptance standard for everything the project produces is written by you, so write it.
Start with two or three threads. The temptation is to fan out wide immediately. Resist it until you’ve watched the usage meter on a small run — the cost multiplier is real.
Give it independent modules. Parallel threads shine when tasks don’t overlap. A migration across three repos, or a feature split into frontend/backend/docs workstreams, parallelizes cleanly. Tightly coupled changes in one file just generate merge conflicts.
Use the mobile interface. The coordinator conversation works on mobile, so a cloud workstream can continue while you’re away from your desk — check in on thread progress, redirect, and approve PRs from your phone.
Cursor shipped a similar concept — coordinator agents managing cloud subagents — a week earlier on September 10. Our Cursor Projects breakdown compares the two approaches if you’re choosing between ecosystems.
A Concrete Example: The v1 API Retirement
Anthropic’s own example is worth walking through because it shows the coordinator pattern at its best. The goal: retire a deprecated v1 API endpoint across three repositories — API backend, web frontend, mobile app.
The old way: you’d open three Claude Code sessions (or do it manually), migrate callers in each repo, run each test suite, open three PRs, and figure out the merge order yourself — probably a day of careful orchestration.
The Projects way: you state the goal once. The coordinator spawns one thread per repository. Each thread migrates its repo’s callers, runs its tests, and opens its PR. The coordinator then tells you which PRs need to merge first (backend before frontend, typically) and assembles the summary. Your job collapses to reviewing three PRs and approving the merge order.
That’s the pattern to look for in your own work: multi-repo, parallelizable, with a defined done-state per unit. Single-repo tangles with heavy interdependencies are the opposite — that’s where you stay in one session.
Threads vs Subagents: The Mental Model
If you’ve used Claude Code’s subagents before, the new threads can be confusing. The distinction:
- Subagents work inside one session, sharing its context and branch. They’re task decomposition within a single unit of work.
- Threads are separate cloud sessions with separate branches and repo copies. They’re parallel units of work that only reconcile at merge time.
A thread can itself spawn subagents for its own subtasks — the hierarchy goes coordinator → threads → subagents. In practice, you’ll interact with the coordinator and occasionally dive into a thread’s stream when something looks off. The subagent layer mostly stays invisible, which is the point.
Related: JetBrains Air Brings Agentic Coding to Your IDE (2026)
Official source: Anthropic
Frequently Asked Questions
What is the new Claude Code Projects?
A redesigned feature (launched in beta September 17, 2026) where a project is one conversation with a coordinator that delegates work to parallel Claude Code cloud threads, each on its own branch, with shared memory across threads.
How much does it cost?
There’s no separate price — but each parallel thread counts as a full Claude Code session against your plan’s usage limits, so costs scale with how many threads you run simultaneously.
Who can use it?
Beta for Pro and Max subscribers using Claude Code cloud sessions, expanding over time. Team and Enterprise plans come later.
Can threads approve their own pull requests?
No. Guardrails block threads from merging PRs no human approved, approving their own PRs, disabling CI, force-pushing, or deploying to production. Humans still merge.
Is this the same as Projects in the Claude chat app?
No. The redesign is for Claude Code Projects. Regular chat-app Projects are unchanged for now.
How is this different from Cursor Projects?
Both use a coordinator-plus-subagents architecture. Claude Code’s version is built around git branches and merge conflicts per thread; Cursor’s emphasizes cloud computers, subscriptions to external signals (Slack, PRs), and longer-running autonomous work. See our Cursor Projects article for the full comparison.