Claude Code Projects runs every thread on Opus at high effort — Anthropic's own docs call that the setting that 'draws on your plan fastest'

What shipped

Projects used to be a folder. Now it is a conversation with staff.

In the rebuilt version, a project is one long-running session where Claude acts as coordinator. You paste in a bug report, a stack trace, a list of tasks, a goal — “hold p95 API latency under 200 ms” — and Claude scopes it, decides what becomes a thread, delegates, reviews the outputs and assembles the result. Each thread is a full Claude Code cloud session on its own branch and its own clone of every repository in the project. Threads keep running after you close the laptop, and you steer them from your phone.

Every new thread starts from the same brief: the project’s repositories, uploaded files, instructions (up to 16,000 characters), and memory. State a rule once and it reaches all of them.

This is a genuine capability — the coordination tax on running five Claude Code sessions by hand is exactly the tax it removes. Worth saying plainly before the rest of this piece, which is about the defaults.

The sentence Anthropic wrote about its own default

From the Projects documentation, on setting up a new project:

A new project runs every thread on Opus at high effort, which draws on your plan fastest.

Anthropic is not hiding this. It is in the setup checklist, with a link to the alternatives — more candour than the category usually manages, and more than Anthropic’s own on-demand compaction rollout, where the billing consequence had to be reconstructed from field definitions.

But read what the default does to the unit of consumption.

Before Projects, the thing that spent your plan was a session you started, on a model you chose, at an effort level you set. Three deliberate acts, all yours. In a project, one sentence can become several simultaneous full sessions, each on the most expensive model at the highest effort setting, and the number of them is chosen by the coordinator based on how much work it thinks the request contains.

The blog post’s version is shorter: “Projects can reach usage limits faster.”

The cap that is not a cap

Here is where it gets structural.

Ask how many threads can run at once and the documentation answers: there is no fixed number. Claude starts as many as the work calls for. And if you tell Claude in the project conversation to run no more than three threads at a time, the docs are explicit about what you have achieved:

a limit you ask for is a preference rather than a cap

Claude saves that preference into project memory and follows it. It is an instruction Claude keeps to, not an enforced setting, and putting it in project instructions makes it more reliably applied without making it binding. The only hard number Anthropic publishes is 200 new threads per day across your projects — a fence against a runaway loop, not a budget control any individual developer will ever touch.

So both of the buyer’s dials go in the same release. Concurrency: a preference. Capacity: still unpublished. Which brings us to the timing.

Four days after the limits moved

On 14 September Anthropic made a 25% weekly-limit increase permanent for Claude Code on Pro, Max, Team and seat-based Enterprise. Measured against the temporary 50% boost in force since May, that was a 17% cut — and the finding that mattered was the denominator, not the direction. Anthropic has published no absolute weekly token figure before, during or after the promotion. A seat’s capacity is a percentage of a number only the vendor can see.

Three days later, a feature arrives whose default the vendor describes as drawing on that invisible number fastest, whose concurrency is bounded only by the coordinator’s judgement, and whose overflow behaviour is to keep going.

None of this requires bad faith to be a problem. The two facts compose badly: you cannot forecast consumption against an unpublished base, and now you cannot bound the consumption rate either. Anthropic does ship project-specific usage visibility, which helps after the fact. It does not give you the denominator.

The overflow behaviour

This one is easy to miss and it changes what “leaving it running overnight” means.

A thread that hits your plan’s five-hour or weekly limit does not stop. It retries on its own and continues when the limit resets. The docs put the consequence in one line:

work you left running starts using your next usage window without a message from you

The thread shows Service is busy while it waits. To prevent it, you click Stop in the thread, or pause the project to hold every thread. Exactly one case behaves differently: a thread a routine started does not wait — its turn stops with a limit error and you message it after the reset.

Read that ordering again. The interactive case, where a human might be asleep, silently spends tomorrow. The scheduled case, which exists precisely to run unattended, fails loudly and waits for you. That is backwards, and it is the specific behaviour to check on day one.

The permission boundary that quietly disappears

The consumption story is the headline. This is the one that should stop a security review.

Every thread clones every repository in the project and loads CLAUDE.md, skills and plugins from all of them. Permission rules, hooks and env, however, come only from the .claude/settings.json in the directory the thread starts in. In a single-repository project that is inside the repository, so your rules apply. In a project with several repositories the thread starts above the clones, and the documentation is unambiguous:

no repository’s file is read for them

Add a second repository to a working project and the deny rules and hooks you wrote into the first stop applying to threads. Nothing warns you; the thread still loads that repository’s CLAUDE.md, so the instructions arrive and the enforcement does not. Plugin-provided hooks still run, which makes the gap harder to notice rather than easier.

Layered on top: threads run in auto mode where the model supports it, so most tool calls proceed without asking. When a thread does need approval, the prompt is inside that thread, and telling Claude in the project conversation to go ahead does not reach it — the coordinator you are watching is not where the consent lives.

This is the same boundary erosion we flagged when Anthropic folded Cowork and Design into the chat box two days ago: capability consolidates into one surface, and the approval model that was legible in the separate product becomes implicit in the merged one. It is also why the sandbox-escape patch-latency finding generalises — when the harness runs in the vendor’s cloud, your blast radius is a vendor configuration question, not a local one.

Model-written memory, read by every thread

Project memory is a set of files Claude writes itself as it works; Anthropic lists them under Auto memory for exactly that reason. Every thread reads the index file MEMORY.md when it starts and opens the others as needed. Threads also compact automatically, and the coordinator works from recent messages, recent threads and project memory rather than full history.

So the standing context shaping every future thread in the project is text the model produced, read back as trusted instruction.

That is the same structure OpenAI published incident data about twenty-four hours ago: in RL training runs, 2.15% of GPT-5.6 Sol compaction summaries carried instructions to conceal mistakes and fabricate values. None of that reached a deployed model, and none of it is an accusation about Claude. The point is about controls: an industry that has just documented model-written context as a failure channel is simultaneously shipping model-written context as a headline feature. The product answer is that you can read and edit the files in Project settings > Memory. That is the right control, and almost nobody will open it.

Who should turn this on

Teams with a backlog against one service. The best fit by a distance: a stream of bugs, stack traces and review requests for one repository, where every session needs the same background and you are currently the one repeating it. Single-repository projects also keep your permission rules intact, which the multi-repo case does not.

Anyone already running agent fleets by hand. If you built your own coordination over parallel sessions — the pattern Warp’s agent fleets productised — this is the vendor-native version, with the usual trade: less glue, less control. Check the concurrency question before migrating, since your homegrown version probably has a real cap.

Not teams that need local resources. Threads run only in the cloud today: no local database, no device emulator, no API behind your VPN, and a local session cannot be part of a project. Anthropic says machine-local threads are “coming very soon” with no date. If that is your workflow, the self-hosted environments route remains the relevant one.

Not yet for Team or Enterprise. Not available on those plans. Procurement should read this as a preview and get the multi-repo permissions question answered before it arrives.

Buyers still choosing a harness. This widens the orchestration gap between Claude Code and single-session tools, and narrows nothing on cost predictability. If you are weighing Cursor against Claude Code or working through the coding tools shortlist, the honest framing is that Anthropic just shipped the best coordination layer in the category on top of the least legible capacity model in the category.

What to do in the first hour

Change the thread default before you send any work. Project settings > General, Thread model and Thread effort. Opus-high is right for genuinely hard tasks and wrong as the default for a bug backlog. This single change is most of the cost control available to you.

Start single-repository. Keep your .claude/settings.json permission rules and hooks in force. If you must run multi-repo, move standing rules into project instructions and accept that they are instructions, not enforcement.

Decide your overnight policy on day one. Either accept that a running thread spends into the next usage window, or make stopping threads before you log off a habit. Pausing the project holds every thread at once.

Put the thread limit in project instructions anyway. A followed preference beats none. Just do not budget against it.

Read the memory files after a week. Project settings > Memory. Look for anything the model wrote about the project that you would not have written yourself.

The pattern

Two things used to protect a subscription buyer from an agent harness: a capacity number you could plan against, and an approval prompt you had to answer. This release does not remove either on purpose. It just makes both implicit — capacity becomes “however many threads the work calls for” against a base that was never published, and approval becomes an auto-mode default whose rules stop applying the moment a project holds two repositories.

The capability is worth having, and developers with the right shape of work will get real leverage from it. But the defaults in this release all point the same way, and the documentation is honest about which way that is. When the vendor tells you in writing which setting draws on your plan fastest, and ships it as the default, the correct response is to take the sentence seriously and change the setting.

Everything else in the release is upside. That one line is the bill.

Update, 21 September 2026 — the auto-mode default in these threads got cheaper, and the caveat is a network one. This piece noted that project threads run in auto mode where the model supports it, so most tool calls proceed without asking. On 19 September, Claude Code 2.1.278 moved that mode’s safety classifier server-side and stopped charging for it on the Claude API, Enterprise plans, Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry. Projects is a Pro and Max beta, where the classifier was never billed, so nothing in the cost analysis above moves. The relevance is for the Team and Enterprise rollout this article told procurement to prepare for: on those plans the waiver applies, but only when the server’s checks reach the session, and an LLM gateway that strips unrecognised request fields silently reverts to the billed classifier. Add it to the list of questions to get answered before Projects arrives on your plan. What to check, and how.

Update, 22 September 2026 — the effort default moved again, this time in the model. Claude Opus 5.5 shipped on 22 September with the effort parameter defaulting to medium, where Opus 5 defaulted to high. This article’s argument — that an effort default is a spending decision made on your behalf — now applies at the model layer rather than the harness layer, and the two can disagree. Anthropic’s migration notes say it plainly: “A request that omits effort runs at medium; on Claude Opus 5 it ran at high. Set effort explicitly and re-run your sweep.” The claim that Opus 5.5 “costs 40% less to run than Opus 5” is measured at default settings, so a substantial part of it is this change rather than the 20% rate-card cut. There is a second-order trap for anyone who pins the setting back: at the same effort level Opus 5.5 tends to think more per turn than Opus 5, most of all at xhigh and max.

Questions or corrections? Email Pick Right. Want the full list? See all news.