Claude Code Projects: One Conversation Now Coordinates Parallel AI Threads

Anthropic redesigned Projects in Claude Code on September 17, replacing the old folder-based version with something closer to a manager than a filing cabinet. Claude Code Projects now works as one ongoing conversation where Claude acts as a coordinator: it takes what you send, decides what becomes a separate task, and starts a thread for each one. Each thread is its own cloud session, running on its own branch, and it keeps working after you close the laptop.

The shift matters less as a feature and more as a change in who does the coordinating. Running several Claude Code sessions at once used to mean you were the scheduler: deciding what each one worked on, repeating the same background at the start of every session, and checking back manually to see what finished. Projects moves that job to Claude itself.

How the coordinator actually splits work

A project has two parts. The conversation is the coordinator, one long-running session that reads what you send and decides where it goes. A quick question gets answered in the conversation directly. New work, a bug report, a stack trace, a list of tasks, gets routed to a new thread or to a thread already working in that area, and Claude tells you which. Several unrelated tasks dropped into one message become several separate threads.

Each thread is a full cloud session with its own context window, working on a new branch off the repository's default branch. It opens a pull request when the work calls for one, and can open one on its own for a concrete fix without being asked. When two threads touch the same code, the overlap resolves as an ordinary merge conflict, the same as any other pull request, not something the coordinator tries to prevent upfront.

Every new thread starts with the project's repositories, its instructions, and its memory already loaded, so a rule stated once, such as which branch to target or how to check work before calling it done, reaches every thread from then on rather than getting typed into a fresh prompt each time. That's the actual gap this closes: not running things in parallel, which Claude Code could already do, but not having to re-explain the same context to every parallel session yourself.

Memory, a library, and pull requests you can act on

Project memory is the part doing the real work under the hood. Claude writes notes to files as it works, a scheduling change, why a piece of code was dropped, who to check with before touching a given service, and every thread reads the index file when it starts. Anthropic's own framing of the use case: a thread can remember the release moved to Friday, or why the export was dropped, without you repeating it.

A Library tab collects the files you upload and the files threads produce, so previous work stays discoverable instead of buried in a closed session. An Overview pane groups every thread by state (ready for review, waiting on you, working, landing, idle, resolved), which is where the actual daily use of this shows up: you open a project after an hour or a morning away and see which pull requests are ready, which thread hit a wall and needs an answer, and which finished cleanly with nothing for you to do. Threads that need scheduling, rather than a one-off run, become routines, which appear on their own tab and run in the project going forward.

What running threads in parallel actually costs

Projects draw on the same Pro and Max plan limits as any other Claude Code session, and a project uses those limits faster than one session working alone, since every running thread is a full session in its own right. A new project defaults to Opus at high effort for threads and low effort for the coordinator itself, which is the fastest setting to burn through a usage window. Anthropic's own documentation is direct that Pro users in particular should expect to hit their limit sooner on days they run a project.

There's no fixed cap on how many threads run at once beyond what the work needs, but there is a hard ceiling: 200 new threads per day across your projects. Asking Claude to run only two threads at a time, or to propose threads before starting them, is a preference it follows, not an enforced setting, so anyone actually worried about burning through a plan should set that expectation in project instructions rather than assume a casual request holds.

Where this actually lands for a solo operator

Projects is in public beta, limited for now to select Pro and Max accounts that have already used cloud sessions and don't have an existing project in claude.ai chat or Cowork. Team and Enterprise access is coming later, and the feature only exists at claude.ai/code, the desktop app's Code tab, and the mobile app, not in the terminal CLI or through Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry.

For anyone running an AI operator setup rather than a single assistant, the honest read is that this formalizes something advanced users were already assembling by hand: multiple Claude Code sessions, a shared brief typed into each one, and a manual check-in loop to see what finished. Cross-session messaging, which shipped as a first-party feature in August, solved the narrower problem of one running session warning another mid-task. Projects goes further by putting a coordinator in front of the whole batch, so the relaying and the status-checking stop being your job by default.

The tradeoff is the same one that comes with any coordinator: less manual overhead, faster plan consumption, and a genuine dependency on the coordinator routing things the way you'd have chosen yourself. For now, on a Pro or Max plan, that's a worthwhile trade to test on one real, bounded piece of work, not a reason to point every open task at a project on day one.

Sources: Anthropic, "Projects redesigned: from folder to conversation"; Claude Code documentation, "Let Claude coordinate ongoing work with Projects".