Yesterday I wrote about Cursor Projects, which work the same way, and I expressed hope that the others would copy it quickly. Well, it just happened. That said, it’s safe to assume Anthropic had been working on this for some time so they could test it; the direction has been obvious since the success of Grok Bot, released in mid-August.
According to the blog announcement, the beta opens first to users who already run cloud sessions in Claude Code and have no existing project in chat or in Cowork (probably because of migrations, which matches the fact that I don’t have the feature enabled myself). Over the course of the week it is supposed to expand to more Pro and Max accounts, and only then will the Team and Enterprise plans and the rest of Claude get their turn. If you don’t have access, you can sign up for the waitlist. Watch out for a naming collision: Projects in chat, which just group conversations and attached files, are still a different feature. And it’s confusing.
How it works
A project has two layers. The coordinator receives what you write in the conversation and decides what becomes a thread and what it answers right there in chat. Threads are the workers. Each has its own context window, its own clone of the repositories and its own branch, and it can further split the work into subagents and loops. The Overview sidebar sorts them by status: ready for review, waiting on you, working, idle.
The coordinator sees what the threads report back to it, not every step they take. When two threads touch the same code, the documentation handles it soberly: it gets resolved as a merge conflict on the pull request, just like at any other time. There is no clever coordination of writes.
Context is set up once. Claude writes the project memory itself into files that every new thread reads at startup, project instructions are capped at 16,000 characters, and the repositories, uploaded files and cloud environment apply equally to all threads. When you correct one thread and tell Claude to remember the correction, the other threads start with it. In my opinion this is the main benefit of the whole thing, much more than the parallelization itself, because it makes it easy to share context from a single source of truth.
How much of your subscription it eats
I’d be careful here; it’s always a lot of magic. A project draws on the same limits as other sessions, and it draws on them faster.
| Item | Default |
|---|---|
| Thread model | Opus, high effort |
| Coordinator model | Opus, low effort |
| Concurrent threads | No fixed cap, limit of 200 new threads per day across projects |
| Limit exhausted | The thread waits and resumes on its own once the limit resets |
| Pull request monitoring | On; the thread wakes up on CI failure and on review comments |
Two things are worth emphasizing. A new project launches ALL threads on Opus with high effort, which is the most expensive combination you can choose. And a thread that hits the limit wakes itself up in the next window, so work you start in the evening can drain your limits by morning. Right after creating a project, I’d switch the threads to Sonnet and keep high effort only where the task truly demands it.
Where it falls short
- With multiple repositories, permission rules, hooks and
envvariables from.claude/settings.jsondon’t apply. A thread picks them up only from the directory where it starts, and with multiple repositories that directory sits above the clones. If you build safety guardrails on hooks, you lose them exactly when you’re running the most sessions at once and would probably need them most. This bothers me, and you won’t find it in the announcement. - Threads run only in the cloud. A local database, a device emulator or an API behind a corporate network are out of reach. Anthropic promises local execution “very soon” but gave no date.
- github.com only. No GitHub Enterprise Server, no GitLab, no Bitbucket, and the Claude app has to be installed on every repository.
- A project belongs to one person. You can’t share it, and corporate administration is missing during the beta.
- A thread’s sandbox is put to sleep between turns. If it can’t be woken up, the thread continues from a fresh clone and uncommitted changes are lost.
Cursor launched practically the same thing eight days earlier
This is the most interesting part of the whole story. Projects in Cursor has been running since September 10, and the architecture matches almost to the letter: a coordinator that doesn’t write code itself, agents working in parallel, and a shared context that grows with the project. Two coordinators within eight days. Either both teams read the same internal metrics, or this layer is simply next in line.
| - | Claude Code Projects | Cursor Projects |
|---|---|---|
| Launched | Sept 17, 2026 | Sept 10, 2026 |
| Beta for | some Pro and Max accounts | all users |
| Where threads run | cloud only, local execution promised without a date | cloud, and the coordinator launches an agent on your machine when a test needs to run locally |
| Work without a prompt | schedules (routines), pull request monitoring | schedules, pull request monitoring, watching a Slack channel |
| Declared scale | cap of 200 new threads per day | delegating to “thousands of subagents” |
The local agent is the main practical difference today. Cursor can reach your database and tools; Anthropic can’t yet. Cursor also adds numbers on the benefit: new users reportedly merge 30% more pull requests, and those who work mainly in projects merge six times as many. It’s a vendor figure with no described methodology and no control group, so I wouldn’t build anything important on it. For Czech companies, one more thing may matter: since August, Cursor belongs to SpaceXAI.
OpenAI lacks this layer. Codex has had subagents since March and can do parallel runs, and the Codex app adds a panel where you watch the agents. But you are the one who assigns the division of work; there is no persistent coordinator with shared memory over the whole project. GitHub Agent HQ is in the same position: mission control lines up agents from several vendors into one overview and leaves the division of work to you.
What to take away from this
It pays off for work that has a goal extending beyond a single session and keeps producing sub-tasks. The same change across ten repositories, a migration, a pile of reported bugs in one service. There, the current system, where you have to wait for each run to finish, is especially annoying. For a single test fix it’s an unnecessarily heavy tool; an ordinary cloud session is enough. I’ll wait for local threads, because without access to the database and tools on my machine, half of my tasks are out of the game. Until then I’ll try it on documentation and on research batches, where a project can work even entirely without a repository and hand files over to the library. That is, if Anthropic enables it for me; I’ve been on the waitlist for a while now :)
Sources: Projects documentation and Anthropic’s announcement from September 17, 2026, Cursor’s announcement from September 10, and additionally The New Stack. The figures on beta scope, limits and default models reflect the state as of September 17, 2026, and Anthropic is changing them as access gradually rolls out.