Claude Code Projects: Parallel Threads, Real Costs

Anthropic put Projects into public beta on 17 September 2026, on Pro and Max, rolling out first to accounts that already use cloud sessions and don't have an existing project in claude.ai chat or Cowork. It isn't on Team or Enterprise yet, and it doesn't exist in the terminal — the CLI's claude project command is a different, unrelated thing that manages local state for a directory.

A project has four parts:

• The conversation. One long-running session where Claude coordinates. It decides what becomes a thread, routes follow-ups to the right one, answers small questions itself, and tracks everything it started. It sees what threads report, not every step they took.
• The threads. The workers. Each is a separate cloud session with its own context window, doing one piece of work on its own branch, opening a pull request when the work calls for one.
• Standing context. Repositories, uploaded files, project instructions (up to 16,000 characters), and project memory — notes Claude writes itself, indexed by a MEMORY.md every thread reads at start.
• The Overview pane. Threads grouped by state: Ready for review, Waiting on you, Working, Landing, Idle, Resolved. Plus tabs for Library, Pull requests, and Routines.

The part people miss: threads inherit nothing from your machine. They get the project's repos and files, each repo's CLAUDE.md, skills and plugins, your claude.ai connectors, and the project's cloud environment. Your local settings, your local MCP servers, your on-disk agent memory — none of it travels. If a skill only exists in your user settings, it may as well not exist.

Claude Code now has four different ways to run work in parallel, and they get conflated constantly. They are not interchangeable:

The meaningful line is lifespan. A subagent dies with its task and an agent team dies with its task. A thread doesn't. It finishes, sits idle, and wakes up two days later because CI went red on its pull request. That single property is what makes a project feel different from a fan-out of subagents — and it's also what makes the bill different.

A new project runs every thread on Opus at high effort. That is the most expensive combination Claude Code offers, applied to every worker, and Claude starts as many workers as the work seems to call for. Telling it to run three at a time is a preference, not a cap.

The only enforced ceiling is 200 new threads per dayacross all your projects. On a Pro plan that number is theatrical — you will run out of plan long before you run out of threads.

Three behaviors are worth knowing before you walk away from a running project:

• Threads resume into your next window.A thread that hits your five-hour or weekly limit doesn't fail. It shows "Service is busy", retries on its own, and continues when the limit resets — spending your next usage window without you sending a message. Stop the thread or pause the project if you don't want that.
• Idle threads wake on CI. Threads watch their pull requests with auto-fix on, whether or not auto-fix is on for your other cloud sessions. A red build or a review comment restarts a thread you thought was finished. You have to ask it, in the thread, to stop watching.
• Reviving an old thread is expensive.A follow-up routed to a thread that's been idle longer than the prompt cache lifetime — an hour on Pro and Max — re-reads that thread's whole conversation before it does anything. For genuinely new work, a fresh thread is usually cheaper than waking a big old one.

Do the arithmetic before the first batch. Eight threads on Opus-high is eight full sessions, each on the same plan budget as the terminal session you already have open, plus the coordinator's own tokens for reading what they report. If you've ever watched a single Opus session chew through a five-hour window, multiply that mental model and you'll set the model dropdown correctly on the first try. The effort level you pick matters as much as the model here, and Project settings gives you both, separately for the conversation and for threads.

A project amplifies whatever brief you give it across every thread, which means a vague brief produces a dozen confidently wrong pull requests instead of one. Before sending a real batch:

1. Write project instructions.This is the brief every new thread starts from — up to 16,000 characters, in Project settings > Memory. Cover which branch to start from, how a thread checks its own work, what needs your go-ahead, and what to do when something is missing. That last one is the line I'd never skip:

- Branch from main, one draft PR per thread.
- Run `npm test` and `npm run build` before calling work done;
  paste the summary lines in your final message.
- If you can't reach something you need — a repo, a secret,
  an API, a connector — say exactly what's missing in your
  first message and stop. Don't substitute, mock, or guess.
- Don't merge, force-push, or touch CI config without asking.

Rules about one repository still belong in that repository's CLAUDE.md, which every thread reads from its own clone. Project instructions are for the project; CLAUDE.mdis for the repo. Don't duplicate them.

2. Fix the model and effort. Project settings > General has Thread model and Thread effort, separate from the conversation's. Opus-high on everything is the default, not a recommendation. Lint cleanups and dependency bumps do not need it.

3. Use project memory deliberately. When you correct a thread, also tell Claude to remember the correction — it lands in project memory and later threads start with it. This is the mechanism that stops you re-explaining the same pitfall to thread number nine. It's also worth auditing: memory files are editable and deletable in Project settings > Memory, and a stale decision in there propagates silently, the same way a badly-worded skill description quietly changes behavior everywhere.

It's a beta, and the limitations are the kind that decide whether it fits your work at all:

• GitHub.com only, with the Claude GitHub App installed. Not GitHub Enterprise Server, not GitLab, not Bitbucket. A /web-setup token is not enough for project threads.
• No local execution.Threads are cloud sessions. A database only your laptop can reach, a local MCP server, a device on your LAN — out of scope. Anthropic says local threads are coming; they aren't here.
• One user, no sharing. A project belongs to you. No sharing threads, no share links on transcripts, no org-level controls during beta.
• Threads are stuck where they were born. You can move a cloud session into a project, never a thread out of one or between projects.
• Sandboxes can drop work.A thread's sandbox pauses between turns. If it can't be resumed, the thread continues from a fresh clone and uncommitted changes are gone. On anything long, put "commit and push work in progress" in your instructions.

That last one deserves emphasis because it fails quietly and asymmetrically: the thread keeps going, so nothing looks broken, and you only find out when the branch is missing an hour of work.

Full disclosure: the beta hadn't reached my account when I wrote this, so every number above is Anthropic's published default or limit, not something I measured. What I havedone for months is the manual version of this — several Claude sessions across worktrees, one repo each, me playing dispatcher, me repeating the same context at the top of every one. That job is genuinely tedious, and it's the job a project takes.

I'd reach for a project when the work is a stream, not a task."Bring every service onto the new lint config" across six repos, each with its own PR. A service whose bug reports I keep pasting in as they arrive. A migration bigger than any one session, where a decision made on day one has to survive to day four. Those are the shapes where the coordinator earns its tokens.

I'd stay local when the work touches my machine.Anything that talks to a local database, a LAN device, an MCP server running on my mini, or a repo that isn't on github.com. Also anything where I want to read the diff as it happens rather than a summary of what a thread decided — a project deliberately puts a layer between you and the work, and sometimes that layer is exactly what you don't want.

The honest summary: this is the first Claude Code feature that treats long-running work as the unit instead of the session. That's the right abstraction. Just don't hand it your whole backlog on day one with Opus-high still in the dropdown.