Claude Opus 5 and the Effort Dial: Spend More Compute Only When the Work Deserves It

Claude Opus 5 is Anthropic's premium model for complex coding, agents, and enterprise work. It shipped on July 24, 2026, with a simple promise: much of Fable 5's capability at the old Opus price.

The model is an easy upgrade from Opus 4.8 on price. Production adoption is less automatic. Thinking now runs by default, effort changes how much work the model performs across text and tools, and an old output limit can cut off a task before the model finishes reasoning.

Claude Opus 5 is the daily premium model, not the absolute ceiling

Use Opus 5 for difficult work that happens every day. Use Sonnet 5 when volume and latency dominate. Reserve Fable 5 for a task that has already failed an Opus evaluation and where the cost of that failure exceeds a 2x token premium.

That hierarchy is also how Anthropic now describes its lineup. Its current model guide tells undecided developers to begin with Opus 5 for complex agentic coding and enterprise work, then move to Fable 5 when they need the highest available capability.

Opus 5 has a 1 million token context window and a 128,000-token maximum synchronous output. A context window is the material the model can keep in view during one request; it is not a promise that every token will receive equal attention. The output limit covers both hidden thinking and the visible answer, which becomes important during migration.

The model ID is claude-opus-5. It is available through the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry. In the Claude app, Anthropic made it the default on Max and the strongest model available on Pro.

This is not a permanent ranking. It is a routing policy that can survive the next model release because each move requires evidence from the workload, not loyalty to a model tier.

The benchmark headline is cost per successful task

Opus 5's useful benchmark result is not that it wins everything. It is that the model often reaches the same accepted outcome with a cheaper run.

Anthropic reports five results that shape the decision:

• On Frontier-Bench v0.1, Opus 5 more than doubles Opus 4.8's performance at a lower cost per task.
• On CursorBench 3.2, Opus 5 at max effort finishes within 0.5% of Fable 5's peak result at half the cost per task.
• On ARC-AGI 3, its score is three times the next-best model's score in Anthropic's comparison.
• On Zapier AutomationBench, its pass rate is around 1.5 times the next-best model for the same cost per task. At the lowest effort setting, it still passes more tasks than any other model in that comparison.
• On OSWorld 2.0, it exceeds Fable 5's best computer-use result at just over one-third of the cost.

Those are vendor-published launch results, not a universal leaderboard for every repository, policy document, or browser workflow. They are directional evidence that effort can convert extra tokens into accepted work. They do not tell you how many retries your own agent will need, how often a person will reject an answer, or whether a faster but slightly weaker result is better for your service-level target.

Cost per successful task captures those missing parts. Add the token cost of every attempt, tool-call charges, latency that matters to the product, and human review. Divide that total by the outputs that pass your acceptance rule.

For a coding agent, success could mean tests pass, the diff stays inside scope, and a reviewer accepts it without a corrective round. For an operations agent, it could mean the record is updated correctly, the right approval is requested, and no unsupported action is taken. The rubric must describe the outcome before you compare effort levels.

The model's apparent intelligence is not the metric. The accepted outcome at a known cost is.

The fixed-workload cost is $9, $22.50, or $45

For the same token shape, Opus 5 sits exactly between Sonnet 5's temporary price and Fable 5.

Take 100 tasks. Each task sends 20,000 input tokens and receives 5,000 output tokens. The batch consumes 2 million input tokens and 500,000 output tokens:

• Sonnet 5 at its introductory $2 input and $10 output rate costs $9.
• Opus 5 at $5 input and $25 output costs $22.50.
• Fable 5 at $10 input and $50 output costs $45.

The calculation uses Anthropic's live API prices. Sonnet 5's $2/$10 rate lasts through August 31, 2026; its standard price becomes $3/$15 afterward. The calculation excludes prompt caching, batch discounts, web search, code execution, retries, and any change in token use caused by the model or effort setting.

At this small scale, Opus costs $13.50 more than Sonnet and Fable costs $22.50 more than Opus. Opus only needs to prevent one correction worth more than $13.50 to justify the Sonnet premium across the batch. Fable needs to prevent more than $22.50 of failure or review to justify its step up.

At 10,000 tasks with the same shape, the totals become $900, $2,250, and $4,500. Opus is now $1,350 above Sonnet, while Fable adds another $2,250. A routing choice that looks trivial during a prototype becomes a budget line at production volume.

Fast mode makes the distinction clearer. It runs Opus 5 about 2.5 times faster at $10/$50, twice the normal price. The 100-task example would cost $45, the same base token total as Fable 5. Buy it when response time has enough product value to justify that premium, not as a default speed switch.

The effort dial is a policy, not a token budget

Start with high. It is the Claude API and Claude Code default, and Anthropic says explicitly setting high behaves the same as omitting the effort parameter.

Effort controls how much work Claude puts into the whole response. That includes visible text, thinking, tool calls, and function arguments. Lowering it can reduce token use and tool activity; raising it can support deeper exploration. It remains a behavioral signal rather than a hard ceiling, so a difficult request at low can still trigger thinking.

The five levels have distinct jobs:

low is for cheap, bounded work. Use it for classification, extraction, simple transformations, and narrow subagent tasks whose output is easy to check. A triage agent deciding which queue receives a ticket is a better fit than an agent resolving the ticket.

medium is the balanced production setting. Use it for routine tool-assisted work where the path is known but the input varies: summarizing a customer record, drafting a standard response, or applying a well-defined operating procedure. It is the first step down from the default when token cost or latency matters.

high is the default for difficult daily work. Use it for code changes, nuanced analysis, and multi-step agents where mistakes are expensive enough to warrant careful reasoning. This is the correct first measurement point because every higher or lower setting can be compared against it.

xhigh is for long-horizon work. Anthropic describes the level for agentic or coding tasks that can run longer than 30 minutes with token budgets in the millions. Use it when the model must explore repeatedly, call many tools, or preserve a plan across a long execution.

max is an exception path. It removes constraints on token spending in pursuit of the highest capability. A task belongs here only after xhigh fails or when the outcome is valuable enough that token efficiency is secondary.

There are two easy mistakes.

First, do not use effort to control writing length. Anthropic's documentation says changing effort does not reliably shorten Opus 5's visible response. Ask for the desired length in the prompt.

Second, do not begin every hard-looking task at max. That prevents you from learning whether high would pass and makes every later cost discussion hypothetical. The useful comparison is the lowest setting that reliably meets the outcome, not the highest score you can purchase.

Who should use Opus 5, Sonnet 5, or Fable 5

Most buyers should not choose one model for every request. They should choose a default and a narrow escalation path.

A funded founder building an agent product

Use Sonnet 5 for high-volume interactions that are easy to validate and Opus 5 for the steps that plan, reconcile conflicting context, or recover after a tool failure.

The founder's risk is putting Opus on every turn because it looks safest. If most requests follow a predictable path, the premium is spent on work that never needed it. Keep the cheap path broad and the Opus path consequential.

Start complex orchestration at Opus high. Escalate a known hard class to xhigh only when the acceptance rate improves enough to cover its additional token use. Send a task to Fable only after Opus fails a representative version and the business impact warrants the 2x unit price.

A mid-market CTO standardizing the model layer

Make Opus 5 the premium default and keep model routing visible in policy. That means a workload owner can state why a task uses Sonnet, Opus, or Fable and what evaluation would change the route.

Do not migrate every Opus 4.8 request by changing one model string and calling the job done. Default thinking changes output behavior and token consumption. Existing max_tokens settings, cached conversation design, and verification prompts all need review.

The Claude Sonnet 5 analysis is the useful lower-bound reference: Sonnet wins when its accepted output holds at the current price. Fable is the upper bound. Opus owns the middle until either boundary proves better on a named workload.

A senior operator automating business work

Use Opus when the job crosses systems or policy boundaries. Reading a request, checking an account, applying a rule, and choosing whether a person must approve is harder than drafting a summary because each step changes the consequence of the next.

Use medium for a stable procedure with bounded tools. Move to high when exceptions, ambiguous records, or conflicting policy text are common. Keep human approval around irreversible actions even when the benchmark is strong. A better model reduces routine review; it does not erase accountability.

Fable becomes reasonable only when the task is both unusually hard and unusually valuable. If a person will review every result anyway, the extra model premium may buy less than improving the review interface.

A solo technical builder

Start on Sonnet 5 while the product shape is changing. Move difficult debugging, architecture review, and cross-file implementation to Opus 5. The difference matters most when a failed attempt causes costly context reconstruction, not when the task is a small edit.

The broader cross-vendor choice remains separate. GPT-5.6 and Claude Sonnet 5 differ in execution systems as well as model quality. Opus 5 strengthens Anthropic's premium route, but it does not make orchestration, tool permissions, or observability interchangeable.

The decision flips at the same point for all four readers: upgrade when measured failure and review cost exceeds the model premium. If no one has measured that cost, the safe business decision is to evaluate before escalating.

Migration from Opus 4.8 has two breaking behaviors

Changing claude-opus-4-8 to claude-opus-5 keeps the same $5/$25 unit price, but it does not preserve the same runtime behavior.

The first break is default thinking. Opus 4.8 could run without thinking unless the request enabled it. Opus 5 decides when and how much to think by default. Because max_tokens caps thinking plus the visible answer, a limit that comfortably held an Opus 4.8 response can truncate an Opus 5 agent before it finishes.

The second break is the relationship between thinking and effort. If a request disables thinking while setting xhigh or max, the API returns HTTP 400. Keep effort at high or below when thinking must remain disabled, or remove the disabled-thinking field at higher effort.

Anthropic also warns that disabling thinking can occasionally make Opus 5 write a tool call into normal text or expose internal XML tags instead of emitting a proper tool_use block. Keep thinking enabled where possible and control spend with effort.

This is a valid Python request for an extended coding or agent task:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

The 64,000-token limit is Anthropic's suggested starting point for xhigh or max, not a requirement for every request. Lower it after observing actual use and completion behavior.

Expect qualitative differences too. Anthropic says Opus 5 tends to write longer deliverables, narrate progress more during agent sessions, delegate to subagents more readily, and verify its work without a separate instruction. Those behaviors can be valuable, but an agent UI, log pipeline, or orchestration layer built around quieter Opus 4.8 behavior may need adjustment.

Three production details decide the bill

Effort, caching, and speed interact. Optimizing any one in isolation can make the other two worse.

Keep effort constant inside a cached conversation

Changing output_config.effort between requests changes Anthropic's rendered prompt, so the later request does not preserve the cached prefix. A system that turns effort up and down inside one long conversation may lose the cache saving it expected to gain.

Pick an effort level at the start of a cache-dependent session and hold it. If later work needs a different effort, route it into a new conversation or accept the cache miss as part of the escalation cost.

Opus 5 lowers the minimum cacheable prompt from 1,024 tokens on Opus 4.8 to 512 tokens. That makes caching available to shorter repeated instructions, but only if the prompt prefix and effort remain stable.

Buy Fast mode for latency, not capability

Fast mode is about 2.5 times the normal speed and costs $10/$50 per million tokens. It does not turn Opus into Fable. For the fixed 100-task example, it raises the Opus total from $22.50 to $45 before caching or retries.

Fast mode is a research preview on the Claude API. It is not currently available on Amazon Bedrock, Google Cloud, or Microsoft Foundry. A multi-cloud architecture cannot assume the speed setting will follow the model everywhere.

Treat the new beta controls as beta

Mid-conversation tool changes let an application add or remove tools between turns while preserving the prompt cache. The feature uses the mid-conversation-tool-changes-2026-07-01 beta header.

Automatic fallbacks can route a classifier-flagged Opus 5 or Fable 5 request to an Anthropic-recommended fallback instead of blocking it. Default and explicit fallback lists use the server-side-fallback-2026-07-01 beta header.

Both controls solve operational problems. They also change what a single logical session can do and which model may answer. Test permission changes, failure handling, and output quality before enabling them on an irreversible workflow.

Run a five-level effort sweep before rollout

A 375-run evaluation is enough to turn the effort dial from opinion into routing data: 25 representative tasks, five effort levels, and three repetitions of each combination.

The repetitions matter because an agent can pass once through luck and fail on the next tool path. The task set matters more than its size. It should include ordinary work, known edge cases, and failures that previously required human correction.

Do not vary effort mid-session during this test if production relies on prompt caching. Test each level in a stable conversation design, otherwise cache misses become an uncontrolled variable.

A useful result might show medium passing routine account work, high needed for exception handling, and xhigh improving a narrow debugging class. That result does not justify xhigh everywhere. It justifies three routes with different economics.

The same process decides whether Fable 5 earns its price. Add Fable only to the Opus tasks that remain below threshold. If Fable does not change acceptance enough to cover its $22.50 premium in the 100-task example, keep Opus.

The safety boundary is different from Fable 5

Opus 5 is less restrictive than Fable 5 for legitimate security work, but it is not an unrestricted cyber model.

Anthropic says its Opus 5 cyber classifiers should intervene about 85% less often than Fable 5's. The model can find vulnerabilities in source code, while safeguards block binary-based vulnerability scanning, penetration testing, and exploit generation. It also remains behind Mythos 5 in offensive cybersecurity and biology research.

That boundary matters for debugging and security agents. A source review may work, while a later exploit-validation step is refused or routed elsewhere. Design the workflow so a refusal is a handled state, not an unexpected parser failure.

The Cyber Verification Program gives eligible enterprises and researchers access to a version with fewer security restrictions. General users should not plan a production workflow around that path until access is confirmed.

Anthropic's internal behavioral audit gives Opus 5 a 2.3 score for overall misaligned behavior, its lowest among recent models. Treat that as evidence about Anthropic's own test suite, not permission to remove approvals, sandboxing, or least-privilege tool access.

The decision

Claude Opus 5 should replace Opus 4.8 for new premium workloads and most existing ones after a staged migration. It costs the same, scales more reliably with effort, and approaches Fable 5 on several consequential evaluations.

It should not replace Sonnet 5 on every high-volume route, and it should not make max the default. The economic win comes from routing: Sonnet or lower effort for cheap accepted work, Opus high for difficult daily work, xhigh for measured long-horizon cases, and Fable only where an Opus failure proves costly.

The effort dial is valuable because it makes that policy explicit. Use it as an evaluation variable, hold it stable where caching matters, and attach every escalation to a named failure.

Want the next model change translated into a production decision? Join the newsletter.