Claude Opus 5 — The Effort Ladder Is the Real Migration Risk

Anthropic released Claude Opus 5 on July 24, 2026. It ships at $5/$25 per million tokens — identical to Opus 4.8, half of Fable 5’s $10/$50 — with a 1-million-token context window, up to 128k tokens of synchronous output, and a new five-level effort control that changes how every API call behaves. The pricing headline is real. The part that will cost you money is the effort ladder nobody is reading carefully enough.

TL;DR

• Price: $5/$25 per MTok, unchanged from Opus 4.8, half of Fable 5. Fast mode at $10/$50 (~2.5× speed)
• Effort trap: xhigh effort scores 44.4% on FrontierBench v0.1 — beating max effort’s 43.3% while using 25% fewer output tokens
• Breaking change: Thinking is on by default. At xhigh/max effort, you cannot disable it — requests with thinking: {"type": "disabled"} return a 400 error
• Action: Tune effort level per workload before migrating. Do not hardcode max. Audit every agent loop that previously suppressed thinking

What Happened

Opus 5 is Anthropic’s new flagship, available immediately as claude-opus-5 on the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry, claude.ai, Claude Code 2.1.219+, and Claude Cowork. It becomes the default model on Claude Max and the strongest available on Claude Pro.

The headline numbers are strong: 96.0% on SWE-bench Verified, 79.2% on SWE-bench Pro, and within 0.5% of Fable 5’s peak on CursorBench 3.2 at max effort — at half the per-task cost. The minimum cacheable prompt threshold drops from 1,024 to 512 tokens, which means existing workflows that weren’t hitting the old minimum now get free cache hits without any code changes.

But the real story is the effort ladder: five discrete levels — low, medium, high, xhigh, and max — that control how much compute the model spends per request. The API and Claude Code both default to high. This replaces the old binary of “thinking on or off” with a gradient that changes token consumption, latency, and output quality in ways that are not intuitive.

Why This Matters

The effort ladder introduces a new parameter that most teams will either ignore or set wrong, and both mistakes cost real money.

Maximum effort is not maximum quality. Anthropic’s own FrontierBench v0.1 evaluation — run on their internal mini-SWE-agent harness on GKE, scoring mean reward over five attempts per task — shows xhigh effort hitting 44.4% mean reward while max effort lands at 43.3%. The xhigh setting achieves this while consuming 25% fewer output tokens. If you hardcode effort: max assuming it’s the best setting, you are paying more for a measurably worse result on agentic coding tasks. This is counterintuitive by design — “max” sounds like “best” — and Anthropic buries the nuance in benchmark tables that most teams won’t read before deploying.

Thinking is now mandatory at the top two effort levels. Opus 5 runs with thinking enabled by default across all levels. At high effort and below, you can still disable it with thinking: {"type": "disabled"}. At xhigh and max, that same API call returns a 400 error. This is a breaking change for any team that previously ran Opus 4.8 with extended thinking suppressed to control token costs or latency. Every agent loop, every pipeline step, every orchestration layer that touches xhigh or max effort needs to be audited. And because thinking tokens count against your output budget, you need max_tokens set to at least 64k to avoid silent truncation mid-task.

Setting thinking: {"type": "disabled"} with effort xhigh or max returns a 400 error on Opus 5. If your migration script doesn’t catch this, your agent pipelines will fail at runtime — not at deployment.

The Fable 5 migration path has a hidden incentive. Teams currently running Fable 5 in production agentic pipelines face a real problem that has nothing to do with benchmarks: Fable 5’s safety classifiers flagged 42% of API calls across 26% of trials in the same FrontierBench run. Opus 5 flagged only 5% of calls across 4% of trials. That is not a marginal difference — it is the difference between an agent that completes a multi-step task and one that stalls unpredictably because a classifier blocked a tool call. If you’re paying $10/$50 for Fable 5 and losing nearly half your calls to refusals, Opus 5 at $5/$25 with a 5% refusal rate is not just cheaper — it is more reliable per dollar spent.

But migrating models is not like swapping a key. Fable 5 and Opus 5 have different thinking behaviors, different effort semantics, and different classifier sensitivities. Your existing prompt harness was tuned for Fable 5’s behavior. Switching to Opus 5 changes how the model interprets instructions, how it allocates thinking budget, and which calls get flagged. You are not just changing your bill — you are changing your system’s runtime behavior.

Before migrating from Fable 5, measure your actual refusal rate per pipeline step. If it’s significantly below 42%, Fable 5 may still be the right model for your specific workload. If it’s at or above that number, Opus 5 is likely both cheaper and more reliable.

Benchmark methodology deserves scrutiny. The FrontierBench v0.1 results use Opus 4.8 as the safety-classifier fallback for both Opus 5 and Fable 5 during evaluation. This means neither model’s benchmark numbers reflect pure single-model performance — there’s a safety net that doesn’t exist in your production environment unless you build it yourself. The 96.0% SWE-bench Verified score is impressive, but it was generated under controlled conditions with per-turn controls and a dedicated safety fallback. Verify against your own harness before committing headcount to the migration.

The comparison to previous Claude pricing changes is worth noting. When Opus 4.8 shipped with dynamic workflows, the cost trap was subagent spawning. When Opus 4.7 dropped, it was the hidden cost of the thinking upgrade itself. With Opus 5, the pattern continues: the sticker price stays flat while a new parameter — effort level — creates a non-obvious cost multiplier that only shows up in your billing dashboard two weeks after deployment.

The Take

I think Opus 5 at $5/$25 is genuinely the best price-to-performance ratio in frontier models right now. The benchmarks back it up, the refusal rate is dramatically better than Fable 5, and the cache threshold drop to 512 tokens is a quiet win for anyone running multi-turn agent loops.

But the effort ladder is not a feature — it’s a new responsibility. The fact that xhigh beats max on Anthropic’s own benchmark means there is no safe default. You have to treat effort level as a parameter to tune per workload, the same way you tune temperature or max_tokens. Teams that leave it at the API default of high are leaving performance on the table. Teams that crank it to max are paying more for worse results. And teams that don’t audit their thinking-suppression logic before migrating will hit 400 errors in production.

The correct migration strategy: pin effort to high initially (the default), benchmark xhigh against your specific workloads, and never touch max unless you have evidence it outperforms xhigh for your use case. Do not assume. Measure.