Projects redesigned: a coordinator, parallel threads, and memory that persists
In brief
On September 17, 2026 Anthropic put Projects into beta as something closer to a work queue than a folder. You set the goal and the context; Claude proposes tasks, delegates them to parallel threads — each a Claude Code cloud session on its own branch — and assembles the results. Plus project memory and a Library. Beta for select Pro and Max subscribers using cloud sessions.
Contents
A Claude Project has been, since it launched, a folder with a system prompt attached. You put files in it, you wrote instructions that applied to every conversation inside it, and each conversation started fresh with that context. Useful, and the structure question — what belongs in one project versus several — is covered in organizing projects.
On September 17, 2026 Anthropic put a redesign into beta that changes the shape of the thing. A project is now closer to a standing piece of work with a coordinator on it.
The new model
You set the project's goal and context. From there:
- Claude proposes tasks against that goal rather than waiting for you to specify each one.
- A coordinator delegates work to threads, which run in parallel.
- Each thread is a Claude Code cloud session on its own branch.
- The coordinator assembles the results.
Anthropic's own example: "Claude creates a thread per repo to migrate callers, run the tests, open PRs." One instruction, N repos, N threads, N pull requests, and a coordinator tracking which ones passed.
If you have run parallel agents in Claude Code by hand — multiple worktrees, multiple sessions, a mental note of which one was doing what — this is that pattern with the bookkeeping moved into the product. The failure modes from doing it manually still apply, and they are worth reading before you fan out across a codebase: Claude Code antipatterns covers the ones that cost the most time.
Project memory
Projects now carry context forward across conversations. Anthropic's examples of what a project can remember:
- that the release moved to Friday
- why the export was dropped
- who to check in with before touching the billing service
This is different from the old project instructions, which were a static block you wrote and maintained yourself. Memory accumulates from the work. The distinction between this and Claude's personal memory is worth being precise about — how Claude's memory actually works covers the mechanics, and memory in practice covers what it gets wrong.
The honest caveat: memory that accumulates automatically also accumulates wrong things automatically. A decision that gets reversed, a constraint that expires, a person who changes teams. Assume you will need to correct it, and check what a project believes before you trust a plan built on it.
The Library
New in this release: a Library that collects your files and Claude-generated artifacts in the project, so outputs from one thread are findable from another and from later conversations. Without it, work produced inside a thread is effectively stranded in that thread.
What is actually available today
This is a beta with a narrow gate:
| Stage | Who |
|---|---|
| Launch, Sept 17 | Select Claude Pro and Max subscribers using cloud sessions |
| Week 1 | More Claude Code users on Pro and Max |
| Later | Team and Enterprise; integration with chat and Cowork |
There is a waitlist if you do not have access. Local machine execution — threads running on your own machine rather than in the cloud — is described as "coming very soon," which means today every thread is a cloud session.
That cloud-only constraint is the practical limit right now. If your repo cannot be cloned into a cloud session — because of network-restricted dependencies, licensed toolchains, or a security policy that keeps source off third-party infrastructure — this does not work for you yet, regardless of your plan.
When this is the right tool
The coordinator-and-threads shape earns its overhead when the work is genuinely parallel and mechanically similar:
- Good fit: the same migration across 12 repos. A dependency bump that needs its tests run everywhere. A codemod plus verification per package. Anything where the per-unit work is near-identical and the interesting part is the aggregate result.
- Bad fit: one hard change in one file. A task where step two depends on what you learn in step one. Anything exploratory. Parallelism costs you coherence, and for sequential work you pay that cost for nothing.
The general rule holds: fan out when the units are independent, stay in one session when they are not. Dynamic workflows in Claude Code covers deciding this at runtime rather than up front.
What to verify before you trust it
A coordinator opening pull requests across twelve repos is a lot of output arriving at once, which is exactly the condition under which review gets skipped.
- Read the PRs individually. Twelve PRs that each look plausible is not the same as twelve correct PRs, and the coordinator's summary is a summary, not a verification.
- Confirm the tests actually ran and actually failed when they should. A thread reporting green on a repo where the test command silently no-ops is the expensive failure here.
- Check the branch each thread used. Threads run on separate branches; know which, before you review.
- Correct the project memory when it is wrong. An incorrect remembered constraint propagates to every future thread.
If you do not have access yet
The pattern is available today without the beta: run parallel Claude Code sessions yourself, one per unit of work, with a checklist as the coordinator. It is more manual and it does not have the Library or persistent memory, but it tells you whether your work is actually parallelizable — which is the thing worth knowing before the redesign reaches your account. Start from project setup in Claude Code.