Claude Opus 5 Is Live: The Model ID Changes, Effort-Based Cost Curve, and Routing Decision Every Operator Must Know

Anthropic shipped Claude Opus 5 on July 24, 2026. The model ID is claude-opus-5, pricing holds at $5 / MTok input and $25 / MTok output — the same as Opus 4.8 — and performance is substantially higher. If the gap between Opus 4.8 and Fable 5 was the problem you were navigating, Opus 5 changes the routing math for most production workloads.

But before you flip the config, there are three things every operator routing to Opus needs to know that the launch blog does not lead with.

What actually changed in the API surface

Model IDs across platforms:

The Bedrock naming convention shifted — anthropic.claude-opus-53 does not follow the same 4-8 versioning pattern as the prior release. If you pin Bedrock model IDs in your routing config, this is a manual update, not an alias swap.

Adaptive thinking is on by default — and it bills.

On Opus 5, thinking is always active. You do not need "thinking": {"type": "enabled"} in your request — that was the Haiku 4.5 syntax. Opus 5 (like Fable 5 and Sonnet 5) runs with adaptive thinking on by default. The implication that matters for operators: thinking tokens are billed as output tokens even when the thinking text is not returned to your application. The default display setting is "omitted", so your response body won't include a thinking block — but the compute ran, and you pay for it.

If you benchmarked Opus 4.8 costs and are projecting Opus 5 costs purely from the list price, your estimates will be off on thinking-intensive tasks. On complex reasoning and multi-step agentic work, the model will consume more output tokens than a flat per-request estimate assumes.

The effort parameter controls the cost-intelligence tradeoff:

Opus 5 exposes an effort dial. From the Anthropic announcement, at CursorBench 3.2, max effort brings Opus 5 within 0.5% of Fable 5's peak score at half the cost per task; at lower effort settings it runs faster and cheaper. This is the first Opus-tier model where the routing decision is not just "which model" but "which model at which effort."

For routing teams, this means your prompt routing policy now has three levers for Claude-tier calls: model choice (Opus 5 vs Fable 5), effort level, and whether you want thinking output surfaced to your application.

The Fable 5 vs Opus 5 routing decision

Fable 5 prices at $10 / MTok input, $50 / MTok output — exactly 2× Opus 5. The announcement is explicit: on CursorBench 3.2 at max effort, Opus 5 is within 0.5% of Fable 5 at half the cost per task.

For coding agents and agentic software engineering, Opus 5 at max effort is a near substitute for Fable 5 on most tasks, at half the cost. The cases where Fable 5 remains the right choice: cybersecurity tasks (where Mythos 5 is the ceiling), tasks where Fable 5's "always-on" extended thinking is materially different from Opus 5's adaptive thinking, and workloads where you have already tuned Fable 5 outputs and do not want to re-validate.

For knowledge work, business automation, and multi-step agentic tasks — Zapier AutomationBench, ARC-AGI 3, OSWorld 2.0 — the announcement data shows Opus 5 outperforms all other models including Fable 5 on a per-cost basis. At any given compute budget, Opus 5 completes more tasks.

The routing policy update for most teams: if you are sending Fable 5 calls for coding or agentic work, Opus 5 at max effort is worth an A/B test. If you are sending Opus 4.8 calls for general enterprise work, Opus 5 at high or max effort is a direct upgrade with no price change.

What to check before migrating from Opus 4.8

Token budget assumptions are stale. Because adaptive thinking is always-on and bills as output, your average output token count per request will increase on complex tasks. Re-benchmark before updating cost projections.

Bedrock routing configs need a manual ID update. anthropic.claude-opus-53 is not discoverable by a wildcard pattern match on prior Bedrock Opus IDs. Update routing tables explicitly rather than relying on pattern-based version detection.

Thinking display defaults changed. On Opus 5, display defaults to "omitted". If your application previously depended on thinking content blocks being absent (a reasonable assumption for Opus 4.8 which did not have thinking), the behavior is the same — but if you want to surface thinking to end users or log it for debugging, you now need to explicitly set "display": "summarized" in the thinking config.

Effort is not a free variable. Lower effort settings reduce cost but also reduce performance. If you are switching from Opus 4.8 (which had no effort dial) to Opus 5 at low effort, you may regress on complex tasks even though you are on a newer model. Test at high or max effort first, then optimize down.

What TheRouter users should watch

For teams routing Claude calls through an AI gateway, the concrete update is two routing table entries:

# Claude API
claude-opus-4-8  →  claude-opus-5

# Amazon Bedrock
anthropic.claude-opus-4-8-v1:0  →  anthropic.claude-opus-53

Vertex AI and Microsoft Foundry use the same claude-opus-5 string as the Claude API. The docs cover how to configure model IDs and per-provider routing policies for multi-cloud Claude deployments.

The effort parameter is a request-level field, not a routing-level field — your gateway passes it through unchanged. Set it in your application request or in a default request template for Opus 5 routes.

For the prior Fable 5 vs Opus 4.8 tradeoff analysis, see Claude Fable 5 Is Live: What the New Model ID, Refusal Semantics, and Token Accounting Mean for Your Routing Layer. Opus 5 changes the equation substantially in favor of routing to Opus for cost-sensitive coding workloads.