Anthropic redesigned Claude Code projects in September 2026, moving them from a folder you organise prompts and files inside to a coordinator that scopes a goal, splits the work across parallel threads, and assembles the result while you get on with something else.
What Actually Changed in Claude Code Projects
A project used to be a place to keep context tidy. Now you describe an outcome and Claude works out how to get there: it scopes the request, delegates pieces of it to parallel threads, coordinates them, reviews what each thread produces and stitches the finished result together. You can check in from your phone, and the work keeps moving after you close your laptop, which matters for an Australian engineering team trying to get value out of a Claude Code seat outside business hours without babysitting it.
How Do You Actually Use the New Coordinator Model in Claude Code?
You start a project the same way as before, by picking a goal and a repo or context, and Claude immediately suggests work it can pick up right away rather than waiting for a fully specified brief. From there you can configure the project's cloud environment, connectors, plugins, instructions and model, then either watch progress in the main project chat or open an individual thread to check the details and steer it directly, the same way you would check in on a junior engineer partway through a task.
What This Looks Like on a Real Multi-Repo Task
Reducing checkout p75 latency: Claude profiles each endpoint, tests optimisations and opens pull requests in parallel threads, rather than working through endpoints one at a time.
Retiring a deprecated v1 API across API, web and mobile repos: one thread per repo migrates the callers and runs the tests, and the coordinator tells you which pull requests need to merge first.
Each thread is its own Claude Code cloud session on its own branch and copy of the repo, so two threads touching the same file resolve as an ordinary merge conflict, not a mystery.
Old Claude Code projects versus the redesigned coordinator model
| Aspect | Old projects | Redesigned projects |
|---|---|---|
| Structure | Folder of context and prompts | Coordinator plus parallel threads |
| Execution | One session at a time | Multiple Claude Code cloud sessions in parallel |
| Memory | Re-explained most sessions | Shared project memory builds over time |
| Conflict handling | Manual coordination by you | Resolves as a normal PR merge conflict |
Who Gets Access First, and When
The rollout starts in beta with select Claude Pro and Max subscribers using cloud sessions in Claude Code who don't already have an existing project on the web or desktop, widening to more Claude Code users on those plans over the following week, then extending to the rest of Claude plus Team and Enterprise plans after that. If you're already on Pro or Max without access, a waitlist is open. For an Australian business budgeting, say, $45,000 a year for a small engineering team's Claude Code seats, the practical question is not whether to adopt this on day one, it's which recurring multi-step job is worth wiring up as a project first.
Pick a task that genuinely has more than one part and takes longer than a single reply, not a quick one-off fix, to see the coordinator model earn its keep.
Decide up front which connectors and plugins the project needs, since that configuration shapes what each thread can actually touch.
Treat the shared project memory as a feature to lean on deliberately: let Claude remember scheduling decisions and ownership instead of re-explaining them every session.
The shared project memory is the part easy to undervalue on a first read. Today, most Claude Code sessions start cold: you re-explain which branch is live, which endpoints are already covered, who owns which service, every time you open a new chat. A project keeps that context across threads and across days, so the second week of a migration doesn't start with the same scene-setting as the first. For a small Sydney engineering team juggling client work alongside internal cleanup, that compounding memory is often worth more than the raw parallelism, because it's the re-explaining that eats the hours nobody bills for, not the actual coding once Claude has the full picture.
Is This Worth Rebuilding Your Claude Code Workflow Around?
Not immediately, and not for every task. Existing projects keep working exactly as they do today and will be upgraded later, including to Cowork and chat, so there is no forced migration. The honest advice for a Sydney or Melbourne engineering team mid-rollout on Claude Code is to pick one real multi-part piece of work, run it through the new model once it reaches your plan, and judge it against how that same task went the old way, rather than assuming the upgrade is automatically worth restructuring your whole setup around.
If you're planning a Claude Code rollout for your engineering team and want help working out which recurring jobs are worth turning into a project versus handling as one-off prompts, that's exactly the kind of scoping work we do. Have a look at our services or get in touch before you commit engineering time to restructuring anything.
