Claude Opus 5 Keeps the Price and Changes the Bill

What Actually Shipped

Claude Opus 5 (claude-opus-5) became available on July 24, 2026 across the Claude API, Claude Code, claude.ai, and Claude Cowork, with the documentation also listing Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry. It carries a 1M-token context window, 128k max output on the synchronous Messages API, adaptive thinking, and a reliable knowledge cutoff of May 2026 — the most recent cutoff in the current lineup, four months later than Fable 5's January 2026.

Anthropic positions it as the default recommendation for complex agentic coding, sitting below Claude Fable 5 ($10/$50) as the capability ceiling and above Claude Sonnet 5 ($3/$15 list, with introductory pricing of $2/$10 through August 31, 2026). Two opt-in beta features arrived with it that matter for agents: mid-conversation tool changes, which let you change the tool set without invalidating the prompt cache, and server-side fallbacks, whose fallbacks: "default" mode can re-run a safety-classifier refusal on Anthropic's recommended fallback model.

There is also a fast mode: up to 2.5× higher output-token throughput at twice Opus 5's base price, which the pricing page lists as $10/$50 per million tokens. The gain applies to output tokens per second, not time to first token, so treat it as a latency option to benchmark rather than a blanket 2.5× speed-up. Note the fine print: fast mode is in research preview on the Claude API (including Claude Managed Agents) only, is unavailable on Amazon Bedrock, Google Cloud, and Microsoft Foundry, and cannot be combined with the Batch API's 50% discount.

The broader feature set is nearly the same as Opus 4.8, but not identical. Anthropic's migration guide names two service-level exceptions that can block an otherwise simple model-string swap: the server-side web fetch tool is unavailable on Opus 5, and Priority Tier is not supported. Teams using either need an alternative before rollout.

The Price Didn't Move. Your Token Count Might.

Here is the change most likely to show up on an invoice before it shows up in a postmortem. On Opus 4.8, a request that omitted the thinking field ran without thinking. On Opus 5, that identical request runs with adaptive thinking enabled. Anthropic's migration guide names this a breaking change, and the consequence is arithmetic: max_tokens is a hard limit on total output — thinking tokens plus response text — so a value that was comfortable on 4.8 may now truncate real answers, and output tokens you were not previously buying are now billable at $25 per million.

The migration guide flags two more behavior shifts in the same direction. Default responses and written deliverables run longer on Opus 5 than on 4.8, and lowering effort reduces thinking volume without reliably shortening visible output — you have to prompt for length explicitly. And Opus 5 spawns subagents more readily, so orchestration prompts tuned on 4.8 may fan out further than you budgeted for.

None of this makes Opus 5 a bad deal. It makes the price comparison meaningless on its own. Cost per million tokens is identical; cost per completed task is an open question that only your own workload answers. This is the same discipline as modelling the cost of an AI feature before shipping it: the unit that matters is cost per accepted change, not cost per token.

Effort Is the Main Dial — and the Advice Inverted

The effort parameter is not new; it has been available since Opus 4.5 and now spans five levels. What changed with Opus 5 is the recommended starting point, and it moved in the opposite direction from the previous two Opus releases.

For Opus 4.7 and 4.8, the documented advice was to start at xhigh for coding and agentic use cases. For Opus 5, it is to start at high — the default — and to use low and medium liberally as the primary control for cost and response time wherever your evals show quality holds. The guide is explicit that effort settings carried over from an earlier model should get a fresh sweep rather than a copy-paste.

That inversion is the most under-reported detail of this launch. A team that migrated to Opus 4.8 and dutifully pinned effort: "xhigh" because the docs said so will, on Opus 5, be running above the recommended baseline while also paying for thinking that is now on by default. Two compounding increases, zero code changes, one model string.

One hard edge to audit: on Opus 5, thinking: {"type": "disabled"} combined with effort xhigh or max returns a 400 error. That combination was accepted on Opus 4.8. If you disable thinking anywhere for latency or output-format reasons, grep for it now — either re-enable thinking or drop effort to high or below.

Two Cache Rules That Point Opposite Ways

Prompt caching is where agent economics are usually won or lost, and Opus 5 changes it twice.

In your favor: the minimum cacheable prompt length drops from 1,024 tokens to 512. Prompts that were previously too short to cache now create cache entries with no code changes. And mid-conversation tool changes (beta) mean you can add or remove tools during a session without invalidating the cached prefix — previously a reason to over-declare the entire tool surface up front just to keep the cache warm.

Against you: changing effort between requests invalidates cached prefixes. Effort shapes the rendered prompt, so a "smart" router that starts a conversation at medium and escalates to xhigh when a task looks hard will throw away the cache at exactly the moment the context is largest and most expensive to re-read. The documented best practice is to hold effort constant within a cached conversation and vary it across workloads instead.

Those two rules together suggest a concrete architecture: classify the task before the conversation starts, pick an effort level for the whole session, and let tool availability — not reasoning depth — be the thing that flexes mid-run. If you are instrumented well enough to see cache hit rates per session, this is a change you can measure in a day; if you are not, AI observability is the prerequisite.

The Benchmarks Moved, So Your Comparison Broke

When we covered Opus 4.8's SWE-bench Verified score, the number was at least legible: a widely used suite with published competitor results. Opus 5's launch numbers are drawn from a different set — Frontier-Bench v0.1, CursorBench 3.2, ARC-AGI 3, OSWorld 2.0, and Zapier AutomationBench — with no SWE-bench Verified headline.

Several of the claims are also cost-relative rather than capability-absolute: within 0.5% of Fable 5's peak CursorBench score "at half the cost," and surpassing Fable 5's best OSWorld result "at just over a third of the cost." Those are genuinely interesting framings, because cost-per-task is closer to what teams actually buy than a raw score is. But cost per task on a model with a five-level effort dial is a function of the settings used, and vendor benchmark configurations are rarely the ones running in your production path.

Launch posts naturally emphasize selected vendor-reported suites, and these numbers remain vendor claims until independent evals reproduce them. The practical consequence is just that cross-vendor comparison got harder this cycle, not easier. The defensible move is unchanged: keep a small eval set built from your own tasks, run the candidate at two or three effort levels, and compare cost and quality on work you actually ship.

What to Do This Week

• Audit disabled thinking before you switch. Search for thinking set to disabled. Paired with xhigh or max effort it now returns a 400 on Opus 5 — a hard failure, not a degradation.
• Revisit max_tokens everywhere. It caps thinking plus visible text together. Requests that never set a thinking field now think by default, so headroom that was fine on Opus 4.8 can truncate output on Opus 5. Anthropic suggests starting at 64k when running xhigh or max.
• Run a fresh effort sweep instead of porting settings. Start at high, then test medium and low against your evals. The old "start at xhigh for coding" advice was written for Opus 4.7 and 4.8.
• Strip inherited verification instructions and cap subagents. Both are documented sources of extra token spend on Opus 5 — the first from over-verification, the second from eager delegation. If you orchestrate multi-agent workflows, set an explicit ceiling.
• Re-baseline cost and latency, not just quality. The tokenizer is unchanged, so token counts are comparable — but per-request token volume is not. Measure cost per accepted change on a real slice of work before rolling the model string out broadly.
• Pin model IDs deliberately. Since the 4.6 generation, dateless IDs like claude-opus-5 are pinned snapshots rather than evergreen pointers, so they will not drift under you — but they also will not follow you forward. Opus 5's tentative retirement is no sooner than July 24, 2027.
• Note the near-term deadline that is not about Opus 5. claude-opus-4-1-20250805 is deprecated and retires August 5, 2026, with claude-opus-4-8 as the named replacement. Separately, temperature, top_p, and top_k return a 400 on non-default values from Opus 4.7 onward. If you are still on 4.1, that is the more urgent migration.

The short version: Opus 5 looks like a free upgrade because the price card says it is one. It probably is a good upgrade — a newer knowledge cutoff, a lower cache threshold, and tool changes that stop fighting the cache are all real wins. Just do not let an unchanged $5/$25 convince you that an unchanged bill is coming. Price the defaults, sweep the effort levels, and let your own numbers decide. If you want the full API-level walkthrough of these parameters, our Claude API guide covers the request shape they live in.