Claude Opus 5: what actually changes for developers

Anthropic released Claude Opus 5 this week — the system card is dated 24 July 2026 — and it is the rare model launch where the interesting part is not the benchmark table. Opus 5 lands at exactly the same price as Opus 4.8, which makes it a straight swap for most people. But two default changes will break code that ports over unexamined, and a third change quietly rewrites the advice everyone has been giving about prompting.

The short version

• Model ID: claude-opus-5 on the Claude API, anthropic.claude-opus-5 on Amazon Bedrock, and the bare ID on Google Cloud and Microsoft Foundry.
• Price: $5 per million input tokens, $25 per million output — identical to Opus 4.8, and half what Claude Fable 5 costs. Prompt caching still saves up to 90%, batch processing 50%.
• Context: 1M tokens, which is both the default and the maximum. Output caps at 128K.
• Consumer plans: the new default on Claude Max, and the strongest model available on Claude Pro.

Anthropic’s positioning is that Opus 5 gets close to Fable 5’s frontier intelligence at half the price, and that it is state of the art on coding and knowledge-work evaluations — while remaining behind Mythos 5 on cybersecurity tasks. We have not run our own evaluations, so treat the benchmark claims as the vendor’s rather than ours.

The two changes that will break things

1. Thinking is on by default

On Opus 4.8 and 4.7, omitting the thinking parameter meant the model did not think. On Opus 5, omitting it means adaptive thinking runs.

That sounds like a behaviour change. It is actually a truncation and cost change, because max_tokens is a hard ceiling on thinking plus response text. Any route that ran without thinking on 4.8 and sized max_tokens tightly around the expected answer can now run out of budget partway through and return a cut-off response. If you have code that never set thinking, revisit its max_tokens before you switch the model string.

To keep the old behaviour, pass thinking: {"type": "disabled"} — which brings us to the second one.

2. Disabling thinking only works at high effort or below

Combining thinking: {"type": "disabled"} with an effort level of xhigh or max returns a 400 on Opus 5. Opus 4.8 accepted that combination happily.

The check runs per request, so this is not something you can verify once at the top of a conversation and forget. A later call that raises effort while thinking is still disabled gets rejected even though earlier calls in the same session went through. Audit every call site, not just the first.

In practice, a latency-sensitive route that was running xhigh with thinking off is usually better served by dropping to medium with thinking on than by preserving the disabled path — which brings us to the genuinely interesting part.

The advice that inverts

“Ask the model to double-check its work” is one of the most reliable prompting tips there is. On Opus 5 it is counterproductive.

Opus 5 verifies its own work without being told to. Instructions that tell it to verify — “include a final verification step”, “re-check before responding”, “use a subagent to verify” — now produce over-verification: extra passes, extra tokens, extra latency, no extra correctness. Anthropic’s own migration guidance is unusually blunt about the fix: delete them. Not rewrite, not soften. Delete. The same goes for separate verification steps carried over in an agent harness.

If you maintain a prompt library that applies “add a self-check” as a global rule, Opus 5 needs a carve-out rather than a tweak.

Two related re-tunings worth knowing about. Opus 5 writes longer user-facing responses than its predecessors, and lowering effort does not reliably shorten them — a conciseness instruction does. And it reaches for subagents far more readily than Opus 4.8 did, which is a reversal: if you added “delegate more” guidance for 4.8, take it out, and consider an explicit cap on spawn count. Each subagent re-establishes context, re-explores, reports back, and then the coordinator re-reads the report — the cost multiplies quickly.

Smaller things that matter

• Prompt caching starts at 512 tokens, down from 1024 on Opus 4.8. Prompts you previously wrote off as too short to cache may now cache with no code change at all. Worth re-checking.
• Rate limits are a separate bucket. Opus 4.8, 4.7, 4.6 and 4.5 share one combined pool; Opus 5 does not draw from it. Moving traffic across neither frees headroom on the old bucket nor inherits it — check your tier’s Opus 5 limits before shifting volume.
• Priority Tier does not cover Opus 5. A Priority Tier request naming it fails validation.
• Fast mode is Claude API only — $10/$50 per million, not available on Bedrock, Google Cloud or Foundry.
• Refusals return HTTP 200. Opus 5 ships with elevated cybersecurity safeguards, and a declined request arrives as a successful response with stop_reason: "refusal" — not an error. Code that reads content[0] unconditionally will break on one. Check stop_reason first.

Should you switch?

If you are on Opus 4.8: probably yes, and the migration is a model-string change plus the two audits above. There is no price penalty and no reduction in the feature set.

If you are on Opus 4.7 or earlier, you inherit the older breaking changes too — extended thinking with a token budget, sampling parameters and assistant-turn prefills all return 400s on the current generation, and those pre-date Opus 5.

The one thing we would not do is switch and then judge it against your existing prompts. A model that verifies its own work, writes at length, and delegates eagerly will look worse than it is when it is running instructions written to compensate for a model that did none of those things.