Claude Code on Opus 5: What to Run, and How to Pace Limits Anthropic Never Publishes

The two numbers a Claude Code subscriber reaches for after Opus 5 shipped, when the week gets tight, are both useless.

The first is the session cost in /usage. It is a real number, and Anthropic says plainly that it "is intended for API users" and that for Claude Max and Pro subscribers "the session cost figure isn't relevant for billing purposes" [1]. Optimizing it optimizes somebody else's invoice.

The second would genuinely help: how much of your current window is left, in tokens or messages. Anthropic does not publish that. The support pages describe a rolling five-hour window and a weekly window, and note that Max carries two weekly limits, without ever attaching a count to any of them [9].

So the metric the cost-cutting genre loves does not bill you, and the metric you actually need does not exist in public.

TL;DR: On a subscription you buy a rate, not tokens, which makes the useful unit accepted work per allowance window. That is my practical inference from the documented controls, not an Anthropic claim. On Pro, Team Standard, and Enterprise subscription seats, Claude Code's default model resolves to Claude Sonnet 5; on Max, Team Premium, Enterprise pay-as-you-go, and the API it resolves to Claude Opus 5 [2]. Model tier repairs what Claude did not know. Effort level repairs what Claude did not do [4]. Session and weekly limits are shared across all models, so /model is not an escape hatch [1]. Commit the routing decision to subagent frontmatter, which carries both model and effort [6]. Then put the human gate where reversal is expensive, not where the diff is large.

Current as of 2026-07-25. Every Anthropic fact below was read from the official docs on that date. Recheck the source pages before turning any of this into permanent team policy.

The meter you are actually on

Claude Code's own cost documentation describes the subscription allowance resetting "on a rolling five-hour window and a weekly window" [1]. Max adds a second weekly limit: one across all models, one for Sonnet only. Weekly limits reset at a fixed time tied to your account, and the whole allowance is shared between Claude and Claude Code, so an afternoon spent talking to Claude in the browser is drawn from the same pool as your agent runs [9].

Here is the beat that changes behavior. Session and weekly limit messages are "shared across all models, so switching models with /model doesn't restore access" [1]. The reflex almost everyone has when the warning appears, drop to a cheaper model and keep going, does nothing once you have hit the session or weekly wall. It works only for the narrower Opus-specific limit. That is why your Wednesday afternoon did not improve.

And you cannot pace against a published figure, because there is not one. No token count, no message count, for a Pro or Max window [9]. Any article that quotes you a hard number for those windows is inferring or inventing it.

One more mechanic explains a cost you have felt without naming it: the prompt cache lives for an hour on a subscription and drops to five minutes once you are drawing on usage credits [1]. The first message after lunch is expensive for a structural reason, not because the model woke up slowly.

If the meter cannot be read ahead of time and cannot be escaped by switching models, the only thing still under your control is what each turn is configured to attempt. That is a configuration question, and it has a startable answer.

Quick answer: Claude Code Opus 5 configuration by task shape

Start with the fact most shared team playbooks are silently broken by. On the Anthropic API, Max, Team Premium, and Enterprise pay-as-you-go, default now resolves to Claude Opus 5. On Pro, Team Standard, and Enterprise subscription seats, it resolves to Claude Sonnet 5 [2]. Two engineers on the same team, both "just using the defaults," are running different models and comparing notes as if they were not. Opus 5 in Claude Code also requires version 2.1.219 or later [2], so a teammate on an older build cannot select it at all, whatever the plan says.

With that established, this is where I would start each task shape. It is a starting policy, not a ranking.

If you run both major coding agents, the same routing method for GPT-5.6 Codex is worth reading beside this one. The argument shape carries over. The controls, the effort vocabulary, and the limit regime do not, so do not port a Codex policy into Claude Code by find and replace.

The table tells you where to begin. It is worth very little without a rule for what to change when the beginning fails, and most teams change both controls at once and learn nothing from the result.

Two dials, two failures

Anthropic's own diagnostic is the cleanest version of this, and it is one sentence long: when Claude falls short, ask whether the problem was insufficient knowledge or insufficient work. A knowledge gap means reach for a larger model. Insufficient work means raise the effort level [4].

The part most coverage drops is what effort actually governs. It is not thinking time. Anthropic describes it as controlling "how many files it reads; how much it verifies; and how far it pushes through a multi-step task before checking in with you" [4], and the platform docs add that effort "affects all tokens in the response," including tool calls, so lower effort means "Claude makes fewer tool calls" [3]. Turn effort down on an agentic task and Claude does not simply think less. It checks less. That is a correctness trade wearing a cost trade's clothing.

Which does not mean keep it pinned high. Anthropic's Opus 5 guidance is to use low and medium "liberally as your primary control for token cost and response time wherever your evals show quality holds," and notes that lower effort on the newest models often exceeds xhigh performance on prior models [3]. The conditional clause is the whole instruction. If you have no gate, you have no evals, and you have no basis for turning anything down.

Two smaller items that cost people real window. If you carried effort settings over from an earlier model, run a fresh sweep rather than reusing them [3]. And changing effort mid-conversation invalidates prompt caching [3], which is the same cache that only lives an hour on a subscription. Flipping effort three times inside one session is not free.

Two nearby controls get confused with effort constantly:

• ultracode is a Claude Code setting, not a model effort level. It sends xhigh and adds dynamic workflow orchestration, and it applies to the session only [2].
• opusplan runs Opus in plan mode and switches to Sonnet for execution [2]. It is a two-tier decomposition you get without writing anything.

Take the rename from the table. It missed a file that was named in the request. That is a knowledge or contract failure, and raising effort will buy you a longer, better-argued version of the same miss. Now take an intermittent auth failure where Opus 5 named a token-refresh race and a cache invalidation problem, then proposed fixes for both without checking the timestamps already sitting in the logs. It understood the task and stopped short of the work. Effort is the clean next change, and the gate stays exactly where it was. One variable, one run.

Knowing which dial to turn still leaves the harder question of who turns it, and a human answering that at every /model prompt is a policy that has quietly decayed by Thursday.

Put the decision in the stage, not the session

A Claude Code subagent declares its own model and its own effort in frontmatter. The model field takes an alias, a full model ID, or inherit; the effort field takes low through max and "Overrides the session effort level" [6]. Anthropic frames subagents as a way to "control costs by routing tasks to faster, cheaper models like Haiku," and each one runs in its own context window and returns only a summary to the main thread [6].

That is the mechanism that makes a routing policy durable. It stops being a decision someone remembers to make and becomes a file in the repository that a reviewer can argue with. My claim that this beats session-level switching is practical inference from those documented controls, not a measured result, and I will say where it stops being safe in a moment.

The cheap lane and the careful lane look like this:

---
name: rename-sweep
description: Apply a typed-field rename across a declared file list
model: haiku
---

---
name: migration-verifier
description: Run named tests against a migration diff and report evidence with risks separated
model: opus
effort: xhigh
---

Effort levels are documented for Opus 5, Sonnet 5, Opus 4.8, and Opus 4.7 [2], so the Haiku lane carries a model line and nothing else.

Across a four-stage task the split I would start from is Sonnet 5 for the explore sweep that mostly gathers files, Opus 5 for the plan, Sonnet 5 again for implementation beside an existing pattern, and Opus 5 at xhigh for the verify stage, because that stage has to return evidence rather than agreement.

Now the cost, because decomposition is not free. Agent teams use approximately seven times more tokens than standard sessions when teammates run in plan mode [1]. On a shared window that is a decision with a price attached, not a free architectural upgrade.

Anthropic supplies the counterweight to its own explore, plan, implement, commit shape: plan mode adds overhead, and "If you could describe the diff in one sentence, skip the plan" [5]. I advocate stage decomposition and I still think most teams over-plan small work. A three-stage pipeline around a one-line config change is theatre.

This is also why I would rather measure full workflow cost and latency, including retries and review than celebrate the cheapest single turn. A Haiku stage that hands off garbage costs the next stage more than it saved.

Take your two most repeated task shapes out of the table above and commit them to .claude/agents/ as subagents before you tune anything else.

A committed policy makes the machine stages predictable, which leaves exactly one step in the loop still priced by instinct: deciding when a person has to look.

The strongest case against routing

The best argument against everything above is that routing is a false economy, and competent people hold it.

Rework from an under-powered model can burn more window than the downgrade ever saved. Maintaining a routing policy is unpaid engineering time that ships nothing. One configuration cannot be misrouted, and simplicity has real operational value on a two-person team. Anthropic is not pushing hard the other way either: its guidance says "For most tasks you should use the model's default effort level" [4], and that default is already high [2]. A reader who does nothing is not being negligent.

So here is the concession. If you are a solo builder at low volume, or the work in front of you is urgent and ambiguous, run Opus 5 at default effort and skip the matrix entirely. You will be fine, and you will spend your attention on the product instead of on a spreadsheet about the tool.

There is a blunter alternative that optimization advice rarely mentions: buy more window. Pro is listed at $17 per month billed annually, or $20 monthly, and Max starts at $100 per month [8]. If maintaining a routing policy costs you an hour a week, price that hour honestly before you decide the policy is the cheaper option.

The line I will defend is narrower than "always route." Routing is cheap exactly where the task shape is already known, which means a repeated shape with an existing test, like that rename. It is expensive to guess where the shape is not known, and guessing is precisely how routing becomes the false economy its critics describe. Route the stages you can name. Leave the rest at default.

Both camps do agree on one thing: overhead is justified where a wrong answer is expensive to undo. That is also the only place a review gate can pay for itself, and it is not where most teams put theirs.

Scope the human gate by reversibility, not diff size

The most useful sentence in Anthropic's best-practices doc is the one arguing against its own review tooling: "A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do." Chasing every finding "leads to over-engineering: extra abstraction layers, defensive code, and tests for cases that can't happen" [5].

Read that as an operating constraint. A gate that always produces findings is a gate that always produces work, and that work draws on the same window the implementation did. Review is a purchase, and you pay in the same currency.

Anthropic's verification ladder runs cheapest to most expensive: state the requirement in the prompt, then /goal, then a Stop hook, then a dedicated verification subagent [5]. Match the rung to the consequence rather than installing the top rung across the board. The Writer/Reviewer two-session pattern belongs on the expensive end, and the failure mode Anthropic names as the trust-then-verify gap is what happens when you install a gate and stop reading its output [5].

Where should the person sit? At the step that is expensive to reverse. That criterion is the bounded, inspectable, reversible responsibility test, and that post labels it a practical inference from the research rather than a validated industry standard. The label travels with it here. I am not going to upgrade an inference into a finding because it is convenient for my argument.

I should be equally direct about what is missing. None of the sources behind this post measure review economics: review cost against escaped-defect cost, or how batch size changes either. The argument in this section is reversibility logic plus a vendor warning about reviewer noise. It is defensible. It is not measured, and you should not treat it as though it were.

In practice the split is unglamorous. A copy fix with a screenshot and an instant revert needs a glance, and a verification subagent attached to it is pure overhead. A retention-policy migration with partial writes deserves a named owner standing at the irreversible step, even when two agents agree the implementation is correct, because agreement between two agents is not evidence about consequences.

A gate scoped this way is a bet. The routing policy is a bet too. Neither one announces whether it is working, which raises the uncomfortable question of whether you would notice.

Pace against /usage, because you will misjudge the gain

METR ran a randomized controlled trial with 16 experienced open-source developers across 246 issues. Developers allowed to use AI tools took 19% longer to complete issues. They had forecast a 24% speedup beforehand, and after finishing they still believed they had been sped up by 20% [7].

State the limits in the same breath, because they matter. That was early-2025 tooling, sixteen developers, mature repositories they knew well. It did not measure Claude Code and it did not measure Opus 5, and anyone telling you it proves AI coding is slow is over-reading it. What transfers to your situation is the gap between what those developers experienced and what the stopwatch recorded. If experienced engineers can finish a task slower and walk away certain they went faster, you can run a routing policy for a month and never notice it is costing you.

So do not tune against how a session felt. Run /usage to see remaining session and weekly capacity [1], and log five runs from a single task class. Not five mixed runs. Averaging endpoint work, migration review, and vague debugging produces a number that describes nothing.

You will notice I have not given you a percentage saved anywhere in this post. That is deliberate. No source I found measures model-routing savings in agentic coding, and no vendor publishes a token count for your window, so any number I offered would be decoration. Your five runs are the measurement. Mine would not transfer to your repository anyway.

Five runs give you a local answer that is only as durable as the session it was learned in, and sessions end.

Make the policy survive the session

The subagent file survives, because it is committed [6]. Almost nothing else does. The gate you agreed on, the evidence that satisfied it, the review finding you consciously accepted, and the reason you promoted Sonnet 5 for endpoint work all live in session state and vanish with it. Next month someone reruns the same class of task at a different configuration and cannot say why the old one was chosen.

That gap is where a project board earns its place, and I want to be exact about the boundary. Claude Code stays the agent. Agiflow is the MCP-connected project board that holds the state a routing policy needs in order to outlive a session: work units and tasks with status workflows, task comments, artifacts, per-environment vault entries, and workflow locks scoped so only one run proceeds per composition. The agent-cli-workflow-lock-management journey covers a CI agent taking that lock through the CLI before it executes [10]. Agiflow does not run Claude Code, does not select models, and does not route effort. What it changes is narrower than a performance claim: when the stage boundary is also a board state, the human review gate becomes a status somebody owns instead of a habit that decays.

My operating rule is deliberately uneven. Spend capability on ambiguity. Spend effort on incomplete follow-through. Spend review on consequence. Spend nothing at all after the gate passes.

Copy the stage routing table into .claude/agents/ and log one week of /usage against it. At the end of it you will have five real runs from your own repository and a defensible reason to trust the cheapest configuration that keeps passing. No article about Claude Code on Opus 5 can hand you that, including this one.

References

[1] Manage costs effectively | Claude Code docs (2026)

[2] Model configuration | Claude Code docs (2026)

[3] Effort | Claude Platform docs (2026)

[4] Choosing a Claude model and effort level in Claude Code | Anthropic (2026)

[5] Best practices | Claude Code docs (2026)

[6] Create custom subagents | Claude Code docs (2026)

[7] Measuring the impact of early-2025 AI on experienced open-source developer productivity | METR (2025)

[8] Pricing | Anthropic (2026)

[9] Use Claude Code with your Pro or Max plan | Anthropic Support (2026) and What is the Max plan | Anthropic Support (2026)

[10] Agiflow product registry, Project Management domain, MCP Integration domain, and the CI workflow-lock journey: docs/products.yaml, docs/architecture/agiflow/domains/project-management.domain.yaml, docs/architecture/agiflow/domains/mcp-integration.domain.yaml, and docs/architecture/agiflow/journeys/agent-cli-workflow-lock-management.journey.yaml (first-party sources, verified 2026-07-25)