Claude Code Projects: threads and your limits

How Claude Code Projects use your plan limits

Claude Code Projects threads use the same plan limits as every other Claude Code session you run. A project cannot spend past those limits on its own. Work goes beyond them only if you have turned on usage credits for your account, and a thread cannot turn them on for you. Anthropic's Claude Code docs and support.claude.com say this as of 12 October 2026.

The real question is how fast a project uses those limits. A project runs several full sessions at once, plus a coordinator, and by default it runs Opus everywhere. A five-hour or weekly window empties faster under that load than under one session in a terminal. This guide explains where the usage goes and which documented settings slow it down.

What is a Claude Code project?

A project is one ongoing conversation in which Claude coordinates a stream of related work. You tell it what needs doing, and it starts a thread for each task. The conversation is the coordinator. It sees what threads report back, not every step they take.

Threads are the workers. Each thread is a separate session with its own context window. It does one piece of work and reports back to the project conversation when it finishes. A thread is usually a cloud session, which means Claude Code running in the cloud rather than on your machine. You can ask for a thread to run on your own computer through Remote Control instead. That needs Claude Code v2.1.280 or later on that computer.

Each cloud thread is a Claude Code cloud session that works on its own branch. It clones its repositories into its own cloud sandbox, so it has its own copy of the repo. It opens a pull request (PR) when the work calls for one. Two threads that change the same lines therefore meet as an ordinary merge conflict, and you handle it like any other PR conflict.

Where a thread runs matters for planning. Cloud threads keep going after you close your laptop. A thread on your computer runs only while that computer is awake.

A thread is different from a subagent. A subagent runs inside one session, does a side task in its own context window, and returns a summary to that session. A project thread is a whole session. A thread can still use subagents for its own side tasks, and those subagents send requests of their own.

Who can use Projects, as of October 2026

As of October 2026, Projects are in public beta on the Pro and Max plans. The rollout is gradual. It starts with accounts that have used cloud sessions and do not have existing projects in claude.ai chat or Cowork. Projects are not available on Team or Enterprise plans yet. Anthropic's launch post of 17 September 2026 said Team and Enterprise would follow later.

If Projects does not appear in the sidebar at claude.ai/code, or in the Code tab of the desktop app, the rollout has not reached your account. In that case you can join the waitlist.

Projects work at claude.ai/code, in the desktop app, and in the Claude mobile app. They are not in the terminal CLI (command-line interface), the VS Code extension or the JetBrains plugin. They are not available through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry. A code project also needs its repository on github.com with the Claude GitHub App installed. GitHub Enterprise Server, GitLab and Bitbucket repositories are not supported.

Which usage pool does a project thread draw from?

The Projects docs answer in one sentence: "Project usage counts against the same plan limits as your other Claude Code sessions, and a project can't spend past those limits on its own." The order of draw is:

1. Your plan limits. Pro and Max both have a five-hour session limit and a weekly limit. These limits are shared across Claude and Claude Code, so a chat in the Claude app and a project thread take from the same allowance.
2. Usage credits, only if you turned them on. Usage credits are pay-as-you-go. They apply only after the included limits are used up. A thread cannot switch them on for you.

The Projects docs name only these two sources. For how the two windows reset, read how Claude's five-hour and weekly usage limits work.

Usage counts against the session allowance and the weekly allowance at the same time. Anthropic's error docs warn that a single burst of heavy activity, such as a large fan-out of parallel work, can use up the weekly allowance before the session window resets. A project with several threads running is exactly that kind of burst.

The cloud part has no extra price. A cloud session counts toward your plan's usage limits, and there is no separate charge for the cloud VM (virtual machine). Cloud sessions share rate limits with all your other Claude and Claude Code usage, so running tasks in parallel consumes more of your limits in proportion.

Anthropic also ran a cloud sessions bonus credit promotion, which began on 23 September 2026. Its support article says the credit does not cover Projects and Routines. For ordinary cloud sessions, that credit paid first while it had a balance. That order does not apply to project threads. The claim deadline was 7 October 2026, so it has passed, and claimed credits expire on 4 November 2026. If you claimed it, how the cloud session bonus credit works covers what it does pay for.

What happens when a thread reaches your plan limit?

A thread that reaches your plan's five-hour or weekly limit waits. It keeps retrying on its own and continues when the limit resets. The project conversation does the same. This means work you left running starts to use your next usage window without any message from you.

If you planned to spend that next window on something else, stop the work first. Click Stop in the thread, or pause the project to hold every thread at once.

One case behaves differently. A thread that a routine started does not wait. Its turn stops with a limit error.

A second failure is about credits rather than limits. A thread or the project conversation can make a request that your plan covers only with usage credits, such as a request to a model or a context size your plan does not include. If usage credits are off, that request fails with this message:

Additional usage credits are required

The fix is to turn usage credits on, or to choose a model and context size your plan includes. If you hit an ordinary limit outside a project, what to do when you reach a Claude limit walks through your options.

Why does a Claude Code project use your limits faster?

The docs say a project draws on the same plan limits as your other sessions "and uses them faster". On a Pro plan in particular, Anthropic says to expect to reach your limit sooner on days you run one. If you are on Pro, what uses up a Claude Pro limit shows how a project fits beside your other usage. Four things draw on your plan inside a project:

• Running threads. Each one is a full session, and several can run at once. Running several sessions at once multiplies token usage.
• The coordinator conversation. Claude uses tokens of its own to read what threads report and to decide what to do next.
• Threads watching a pull request. After a thread opens a PR, it watches that PR with auto-fix turned on, even if auto-fix is off for your other cloud sessions. An idle thread wakes and uses your plan again when CI (continuous integration) fails or a review comment arrives.
• The first turn on your first project. Claude takes a turn of its own as soon as the project is created, unless you send a message first. That turn uses your plan.

Two defaults make this heavier. The first is the model. A new project runs Opus everywhere, with high effort for threads and low effort for the coordinator conversation. Anthropic's own setup steps say that running every thread on Opus at high effort "draws on your plan fastest". The docs do not name an Opus version.

The second is the cache. A follow-up routed to a thread that has been idle longer than the cache lifetime re-reads that thread's whole conversation before it does anything. The cache lifetime is an hour on Pro and Max within your plan's limits. It drops to five minutes once you are drawing on usage credits. A large old thread is expensive to revive, because its entire history is read again instead of coming from the cache. For new work, a fresh thread can use less.

An idle project costs nothing. A project with no running threads, no watched pull requests and no new messages does not use your plan while it sits idle. An archived project does not use it either.

How do you make a project use less? The levers Anthropic documents

Set the model and effort for the project

Project settings > General holds four controls: Thread model, Thread effort, Coordinator model and Coordinator effort. For work that does not need the largest model, Anthropic suggests a smaller model or a lower effort level for threads, the conversation, or both. Changes apply to new threads, not to threads already running. If you are unsure what an effort level changes, read what the Claude effort levels actually change before you lower one.

For one task that needs a different model, ask for that model in the task itself. For a thread that is already running, use that thread's model picker.

Tell Claude how many threads to run

The docs state no fixed number of concurrent threads. Claude starts as many as the work calls for. You set a preference in the project conversation in plain words. These three examples come from Anthropic's docs:

Run at most two threads at a time
Propose threads and wait for my go-ahead before starting them
Reuse an existing thread for follow-ups in the same area

Claude saves these to project memory. Put the limit in the project instructions to have it applied to every thread from the start. On a first batch, the docs suggest asking Claude to propose threads before starting them and to run a few at a time.

Know what this lever is. It is an instruction Claude keeps to, not an enforced setting, so a thread limit you give this way is a preference rather than a hard cap. The one enforced limit the docs state is 200 new threads per day across all your projects. That is a daily count of new threads. It does not limit how many run at once.

The reuse instruction and the cache rule pull in different directions. Reusing a thread is cheap while its cache is warm. After the thread has been idle past the cache lifetime, a fresh thread can cost less than reviving it.

Stop idle threads from waking up

To stop a thread from waking on CI failures and review comments, ask in the thread for it to stop watching the pull request.

Two project-wide controls sit in Project settings > General. Pause stops everything at once. Every running thread and the conversation are interrupted, no new threads start, routines do not run, and the project accepts no messages until you resume it. Archive hides the project from the sidebar and archives its threads, which stops any thread that was running or watching a pull request.

Send the first message yourself

On your first project, Claude takes its own turn unless you write first. Send your first message straight away, with the batch size and the propose-first instruction in it, so the first piece of work is the one you chose.

How do you see what a project used?

Open Usage in Project settings. It shows token use by thread and by model, and how much went to the project conversation. Anthropic's pages give no per-thread figure and no dollar or percentage cost for a project, so this tab is where you learn what your own project costs.

Do not rely on /usage in the terminal for this. Its figures are approximate and computed from local session history on that machine, so usage from other devices or claude.ai is not included. Project threads run in the cloud, so the terminal does not give you a full picture of them. For the wider picture of where Claude Code spends tokens, see how Claude Code token usage adds up.

To manage usage credits on Pro or Max, run /usage-credits in Claude Code. It opens Settings > Usage on claude.ai in your browser. The Usage credits section there lets you turn credits on or off and check your balance, this month's spend and your monthly spend limit. The command needs you to be logged in with a claude.ai subscription. It is not available with API key authentication. If you turn credits on so a project can keep going, set the monthly spend limit at the same time.

When is one local session or subagents the cheaper tool?

Anthropic's docs say a project is worth it when the work has a goal that outlasts one session and keeps producing tasks. For other work, a smaller tool usually uses less of your plan.

• One task that fits in a session. The docs give "Fix the flaky login test" as the example. Start a cloud session yourself. You pay for one session and no coordinator.
• Work where every task needs your machine. A local database, a device emulator or an API behind your VPN (virtual private network) cannot be reached from a cloud sandbox. Use a local session, or agent view to run several at once. Agent view is a research preview. A session you start in your terminal, IDE (integrated development environment) or the desktop app's local environment cannot be added to a project.
• Side tasks inside one job. Use subagents. They are not free: a subagent sends its own requests, which count toward the same usage limits as your main conversation. You can route a subagent to a lower-cost model such as Haiku, which a project's Opus default does not do for you.
• Several local sessions that need to coordinate. Keep them local, and look at Claude Code sessions that message each other for how they can pass work between them.

The docs also list a single scheduled task, and several people steering work in Slack, as cases where something other than a project fits better.

The usual local habits still apply. Anthropic's cost docs say Sonnet handles most coding tasks well and costs less than Opus, and they say to reserve Opus for complex architectural decisions or multi-step reasoning. Delegate verbose work to subagents, and use /clear to keep context small between unrelated tasks.

Check your setup before you move work into a project. Cloud threads do not pick up anything from the Claude Code setup on your own machine, so skills, plugins and MCP servers installed only locally are missing. Threads get CLAUDE.md and skills from the project's repos, plus your claude.ai connectors. If your workflow depends on a local MCP server, a local session is the right tool anyway.

Two beta limitations also point to a local session for some work. A project belongs to one user, so you cannot share a project or its threads, and there are no organization-level controls during the beta. A cloud thread's sandbox pauses between turns. If the sandbox cannot be resumed, the thread continues from a fresh clone, so uncommitted changes can be lost.

If you run projects most days and still hit the weekly limit, the plan size is the next question. Choosing between the two Max tiers covers that decision.

FAQ

Do Claude Code Projects threads use my normal plan limits or separate credits?

They use your normal plan limits, the same five-hour and weekly limits as your other Claude and Claude Code usage. A project cannot spend past those limits on its own. Work continues past them only if you have turned on usage credits, which are pay-as-you-go, and a thread cannot turn them on for you. Anthropic's cloud sessions bonus credit promotion does not cover Projects. This is what Anthropic's docs said on 12 October 2026.

Why did my Claude Code project keep working after I hit my limit?

A thread that reaches your five-hour or weekly limit keeps retrying and continues on its own when the limit resets. Work you left running therefore starts using your next usage window without a message from you. Click Stop in the thread, or pause the project in Project settings > General, to hold the work. Threads that a routine started are the exception: they stop with a limit error instead of waiting.

How many threads can a Claude Code project run at once?

Anthropic's docs give no fixed number. Claude starts as many threads as the work calls for. You can tell it in the project conversation to run at most two threads at a time, or to propose threads and wait for your go-ahead, but that is a preference Claude keeps to, not a hard cap. The only enforced limit the docs state is 200 new threads per day across all your projects.

How do I make a Claude Code project use less of my plan?

A new project runs Opus everywhere, at high effort for threads, which draws on your plan fastest. In Project settings > General, choose a smaller model or lower effort for threads, the coordinator, or both. Ask Claude to run fewer threads at once, ask idle threads to stop watching their pull requests, and start fresh threads instead of reviving large ones that have been idle for over an hour. Check Project settings > Usage to see token use by thread and by model.