Claude Opus 5 Is Out — Here Are the API Changes That Will Actually Break Your Code

Anthropic shipped Claude Opus 5 on July 24, 2026, and if you build on the Claude API there's a version of this launch story you can safely skip: the benchmark charts. The version you can't skip is the API contract, because for the first time in a while an Opus release changes how existing requests behave — and one parameter combination that was perfectly valid on Opus 4.8 now returns a 400 error.

I write and teach about AI engineering at Cursuri-AI.ro, Eastern Europe's AI education platform, and this post is the writeup I wish every model launch came with: not "how smart is it," but "what do I need to change in my code, in what order, and what silently behaves differently if I change nothing." Everything below comes from Anthropic's official "What's new in Claude Opus 5" documentation — no leaked numbers, no vibes.

Quick disclaimer: this space moves monthly and this is a launch-window snapshot. Verify against the official docs before you wire anything to production.

The spec sheet, in one table

Spec	Claude Opus 5
Model ID	claude-opus-5 (anthropic.claude-opus-5 on Bedrock)
Context window	1M tokens — both default and maximum (no smaller variant)
Max output	128k tokens
Thinking	On by default
Pricing	$5 / $25 per million input/output tokens — unchanged from Opus 4.8
Fast mode	$10 / $50, research preview, Claude API only

Two of these are bigger deals than they look. The 1M context window isn't an opt-in variant — it's just what the model has, and the docs specifically claim consistent instruction following, tool calling, and reasoning throughout the window. And 128k max output makes single-request long deliverables (big refactors, full reports) realistic — with a caveat about max_tokens we'll get to, because it's now doing more work than it used to.

Opus 4.8 stays available on every platform, so nothing forces a same-day migration. But the changes below are the kind you want to understand before your first "why is this request failing" incident, not after.

Change #1: thinking is on by default

On Opus 4.8, a request without a thinking field ran without extended thinking. You opted in with thinking: {"type": "adaptive"}.

On Opus 5, that same field-less request now runs with thinking on. The model decides when and how much to think on each turn, and the effort parameter is the knob that controls thinking depth. If your code already sends thinking: {"type": "adaptive"}, you're fine — that value remains valid and is equivalent to the new default.

Why this can bite you even though it sounds like a free upgrade:

max_tokens is a hard limit on total output — thinking plus response text. A workload that ran happily with max_tokens: 2000 on Opus 4.8 (no thinking, short answers) can now spend a chunk of that budget on reasoning before it writes a single visible token. The official guidance is explicit: revisit max_tokens for every workload that previously ran without thinking.

Change #2: the actual breaking change — disabled thinking + high effort = 400

Here's the one to grep your codebase for today:

• thinking: {"type": "disabled"} is accepted only when effort is high or below.
• thinking: {"type": "disabled"} combined with effort xhigh or max returns a 400 error, on every request.
• This is generally available behavior (not beta) from Opus 5 onward — and it's a breaking change from Opus 4.8, where disabling thinking was independent of the effort level.

If you currently run thinking-disabled at high effort levels, you have exactly two exits: keep thinking disabled and drop effort to high or below, or keep your effort level and delete the thinking field entirely.

There's a second, subtler reason to just let thinking stay on. The docs note that with thinking disabled, Opus 5 can occasionally write a tool call into its text output instead of emitting a proper tool_use block, or leak internal XML tags into the visible response. If you parse tool calls in production, that's not a cosmetic footnote — it's a failure mode your handler needs to survive. Anthropic's recommendation is to keep thinking enabled and control cost with lower effort levels instead.

Change #3: effort is now the control lever that matters

With thinking on by default, effort becomes the central parameter of your integration. The full ladder on Opus 5: low, medium, high (the default), xhigh, and max. The docs make a claim worth taking seriously: Opus 5 converts additional effort into better results more reliably than any earlier Opus model — which means the level you pick carries more weight than it did on 4.8. At the other end, low and medium are explicitly called out for producing strong quality at a fraction of the tokens and latency.

A request with everything turned up looks like this:

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "max"},
    messages=[{"role": "user", "content": "..."}],
) as stream:
    response = stream.get_final_message()

Three deliberate details in that snippet: there's no thinking field (the default is what you want), max_tokens is large (at xhigh/max the model needs room to think and act across tool calls), and it's streamed — at 64k-token budgets, non-streaming requests can hit the time limit.

The sane strategy is the documented one: start at the default high, then adjust based on your own evals, not vibes. Step down where quality holds — you pocket the tokens and latency. Step up to xhigh/max for the genuinely hard work. If you don't have an eval harness that can answer "did quality hold when I dropped effort?", that's the single highest-leverage thing to build this quarter — it's the discipline we treat as foundational in our course on LLM evals in production.

Change #4: the model behaves differently, even if you change nothing

The docs have a refreshingly honest section on differences you'll notice without touching your code:

• Default responses run longer — both user-facing answers and written deliverables. If your product has strict length constraints, enforce them in the prompt.
• In agentic sessions, the model narrates its progress more often. Good for UX transparency; tune it down where you want silence.
• In multi-agent frameworks, it delegates to subagents more readily — budget accordingly, subagents are tokens too.
• It verifies its own work without being told to. This is the one that demands action: verification instructions inherited from older prompts — "include a final verification step," "use a subagent to verify" — should be removed, because on Opus 5 they cause over-verification. You pay twice, in tokens and latency, for work the model already does.

This is a pattern every migration teaches: prompts get calibrated against the previous model's weaknesses, and those calibrations become friction on the next model. A model migration without a prompt audit is half a migration. That workflow — prompts, tools, verification, on real repos — is exactly what we drill in our Claude Code and agentic coding course.

The smaller changes you'll actually be happy about

• Prompt caching minimum drops to 512 tokens, from 1,024 on Opus 4.8. System prompts that were too short to cache start caching with zero code changes. If you run compact prompts at volume, this shows up on your invoice by itself.
• Mid-conversation tool changes (beta): you can add or remove tools between turns while preserving the prompt cache, with the mid-conversation-tool-changes-2026-07-01 beta header. For phase-based agents (explore → edit → verify, different tools each), this removes a whole architectural compromise — no more front-loading every tool "just in case."
• A "default" mode for fallbacks (beta): the fallbacks parameter can now apply Anthropic's recommended fallback models by refusal category, instead of a hand-maintained model list. Use the server-side-fallback-2026-07-01 header (the older 2026-06-01 header only accepts explicit lists).
• Fast mode exists but is API-only: $10/$50 per million tokens, research preview, not currently on Bedrock, Google Cloud, or Microsoft Foundry. If you route through a cloud provider and were counting on it, adjust your plan.

The migration checklist, in the order things break

1. Grep for the fatal combination: thinking: {"type": "disabled"} anywhere near effort xhigh/max → that's a 400 now. Decide per integration: drop the thinking field, or lower effort.
2. Revisit max_tokens on every request that ran without thinking on 4.8 — the budget now covers reasoning + response.
3. Swap the model ID to claude-opus-5 — from a config variable, not a hardcoded string. (Model retirements turn hardcoded IDs into production 404s; ask me how I know.)
4. Audit your prompts for verification instructions and remove them — over-verification is pure waste on Opus 5.
5. Turn on streaming for anything with a large max_tokens.
6. If you must run thinking-disabled, make your parser survive tool calls in text and stray XML tags.
7. Re-run your evals before shifting traffic. "Better on average" is not "better on your tasks."

If your architecture makes step 3 scary — model IDs scattered across services, no config layer, no eval gate — that's a structural problem worth fixing once, properly. Going from "API calls sprinkled through the codebase" to "an application where a model swap is a config change" is the arc of our building AI applications with Python course.

The bottom line

Opus 5 doesn't ask you to learn a new API — it asks you to re-check the assumptions your existing code was built on. Thinking is on unless you say otherwise, effort is the lever that matters, max_tokens now pays for cognition too, and one previously-valid parameter combo is a hard error. In exchange you get a 1M-token window as the default, 128k output, cheaper caching, and betas that clean up real architectural pain.

Teams that treat this as a checklist migration — rather than a find-and-replace on the model name — will come out with integrations that are cheaper and more reliable than what they had. And that discipline, built once, pays out again on every launch that follows.

If you want structured, hands-on training on any of this — evals, agentic coding, production LLM apps — that's what we build at Cursuri-AI.ro.