
Claude Opus 5's effort levels, and what they actually cost you
Same price as Opus 4.8, five effort levels not three, and a cache penalty that can make lower effort cost more
tldr: Claude Opus 5 costs $5 per million input tokens and $25 per million output tokens, exactly what Opus 4.8 cost. The "cheaper frontier model" coverage is comparing it to Fable 5 at $10/$50, which is a tier comparison, not a price cut. The effort control has five levels rather than the three widely reported, and changing it mid-conversation invalidates your prompt cache.
What is Claude Opus 5?
Anthropic released claude-opus-5 on 24 July 2026 at $5 per million input tokens and $25 per million output tokens, available through the Claude API, Claude.ai, Claude Code, and Claude Cowork. It became the default model on Claude Max and the strongest model available on Claude Pro. Like every Claude model from 4.6 onward it carries a one-million-token context window billed at standard rates, with no long-context surcharge.
Two cost controls ship with it. The effort parameter decides how many tokens the model spends on a response. Fast mode trades money for throughput. Neither behaves quite the way the launch coverage described.
Did Opus 5 actually get cheaper?
Not compared to what it replaced. Against the tier above it, yes.
| Model | Input | Output |
| Claude Fable 5 | $10 | $50 |
| Claude Opus 5 | $5 | $25 |
| Claude Opus 4.8 | $5 | $25 |
Fortune's headline framed the release around toggling between cost and capability, and most coverage followed with some version of "cheaper frontier model." Both rows that matter are on Anthropic's own pricing page: Opus 5 and Opus 4.8 carry identical rates. Nothing got cheaper per token. What changed is that near-frontier capability now sits at half of Fable 5's rate card, which is a real shift and a different claim. Our LLM API pricing comparison puts all three vendors in one table if you want to see where that leaves Opus 5 against GPT-5.6 and Gemini.
The tell that this release is about cost per task rather than cost per token is in Anthropic's own framing. Its announcement reports Opus 5 landing within 0.5% of Fable 5's peak CursorBench 3.2 score at half the cost per task, and beating Fable 5's best OSWorld 2.0 result at just over a third of the cost. Those are vendor-reported figures on vendor-chosen benchmarks, and we have not verified them. The unit they chose is the interesting part.
One trap if you are upgrading from further back: Anthropic's models from 4.7 onward use a newer tokenizer that produces roughly 30% more tokens for the same text than Sonnet 4.6 and earlier. Moving from Opus 4.8 to Opus 5 is tokenizer-neutral. Moving from Opus 4.6 or Sonnet 4.6 means the same prompts count about 30% heavier at the same rate card.
What does the effort parameter actually do?
Launch coverage reported three levels. The effort documentation lists five, and Opus 5 supports all of them.
| Level | What it is for |
max | Unconstrained token spending, deepest reasoning |
xhigh | Long-horizon agentic work, over 30 minutes, million-token budgets |
high | The default. Identical to omitting the parameter |
medium | Balanced, moderate token savings |
low | Most efficient, some capability reduction, good for subagents |

It is set as output_config.effort on the request, needs no beta header, and applies to the whole request. Three properties matter more than the level names.
It governs all tokens, not just thinking. Effort shapes response text, thinking, and tool calls together, and it works whether or not thinking is enabled. Lower effort means the model combines operations into fewer tool calls and skips the preamble. Higher effort means more tool calls, explained plans, and detailed summaries. For anything agentic, the tool-call count is where the money actually goes, so this is the property that matters.
It is a behavioural signal, not a token cap. Anthropic is explicit that at low effort Claude still thinks on hard problems, just less than it would at high effort. If you need a hard ceiling, max_tokens is the ceiling; effort is a lean.
On Opus 5 it does not shorten visible answers. The docs say plainly that changing effort does not reliably shorten responses on this model, and that you should prompt for length instead. Effort controls thinking volume. If you were planning to use it as a verbosity dial, it is the wrong lever.
What does effort do to your bill?
Effort moves output tokens. Since output costs five times input on Opus 5, how much you save depends entirely on how output-heavy your workload already is. Take the same 40% reduction in output tokens across two shapes:
| Workload | At high effort | Output cut 40% | Saving |
| Write-heavy: 30,000 in, 5,000 out | $0.275 | $0.225 | 18% |
| Read-heavy: 50,000 in, 1,000 out | $0.275 | $0.265 | 3.6% |

Both requests cost the same at the default. The same effort reduction is worth five times more on the write-heavy one. A coding agent that reads a few files and writes a patch is exactly the shape effort helps; a retrieval pipeline that stuffs 50,000 tokens of context in and gets a paragraph back is exactly the shape it does not. Our Gemini API pricing breakdown works through the output-share formula if you want to compute your own ratio properly.
The dial is not free to turn
Here is the part nobody mentioned on launch day, and it can reverse the calculation above entirely.
Effort is a request-level setting, and it changes the rendered prompt. Change it between requests and you do not keep your cached prefixes. Anthropic's guidance is direct: pick an effort level at the start of a conversation and hold it constant, varying effort across workloads rather than within a cached session.
Cache reads cost 10% of base input, so on Opus 5 a cached token reads at $0.50 per million instead of $5. Consider a request with 30,000 input tokens where 25,000 are a stable cached prefix, writing 5,000 tokens out:
| Scenario | Input cost | Output cost | Total |
| High effort, cache hit | $0.0375 | $0.125 | $0.1625 |
| Low effort, cache invalidated | $0.15 | $0.075 | $0.225 |
Dropping to low effort cut output spend by 40% and still made the request 38% more expensive, because losing the cache hit on 25,000 tokens cost more than the reasoning savings returned. Dynamic per-request effort selection, the obvious thing to build once you see a cost dial, is an anti-pattern inside any conversation with a large cached prefix.

Route by workload, not by request. Pick the effort level per pipeline and keep it stable within a session.

Is Fast mode worth twice the price?
Fast mode runs Opus 5 and Opus 4.8 at $10 input and $50 output. That is exactly double, and it lands precisely on Fable 5's rate card. In return you get up to 2.5x higher output tokens per second, from the same weights with no change to capability.
Read the fine print before budgeting for it. The gain is in output tokens per second, not time to first token, so it is most visible when streaming a long response and does nothing for the latency before the first word appears. It is a research preview requiring an account manager or the waitlist. It runs on the first-party API only, not Bedrock, Google Cloud, or Microsoft Foundry. It cannot be combined with the Batch API or a Priority Tier commitment. And switching between fast and standard speed invalidates the prompt cache, the same trap as effort.
The break-even is straightforward: paying 2x for 2.5x throughput only makes sense when something expensive is blocked waiting for tokens, which usually means a human. Batch jobs, CI runs, and background agents are never blocked in that sense, and for them the comparison is worse than it first looks. Batch processing takes 50% off, giving Opus 5 at $2.50 and $12.50. So the spread between the fastest interactive setting and the cheapest asynchronous one is 4x, not 2x.
What this changes for agent pipelines
Once effort exists, model selection stops being the only cost decision you make. You are choosing a model, an effort level, and a speed, per workload, and the effort choice reaches into tool-call counts rather than just answer length.
The practical shape that falls out of the numbers above: default to a lower effort level than instinct suggests and escalate on measured failure, because Anthropic's own Opus 5 guidance is to use low and medium liberally as the primary cost and latency control wherever evals show quality holds. Set effort per pipeline rather than per request so caching survives. Reserve xhigh for the long-running agentic work it was built for, and pair it with a large max_tokens, starting around 64k. Keep Fast mode for interactive paths only.
One more piece of Anthropic's guidance is easy to skip and expensive to ignore: if you carried effort settings over from an earlier model, run a fresh sweep on your evals rather than reusing them. The recommended starting point moved between generations, with Opus 4.7 and 4.8 guidance suggesting xhigh for coding while Opus 5 starts at high.
The broader point is that per-task cost control only pays off if you measure per task. Log output token counts per request rather than trusting response length, since on Opus 5 the two have come apart. Count tool calls, because effort changes them. And cache anything you re-run, which is the same reason Passmark caches AI test steps instead of re-executing them on every pass: work you repeat is work you pay for twice.
Key takeaways
- Opus 5 costs the same as Opus 4.8, at $5 and $25. It is half of Fable 5, which is where "cheaper" comes from.
- Effort has five levels, not three: low, medium, high (the default), xhigh, and max.
- Effort shapes tool calls and thinking, not visible response length. On Opus 5, prompt for length separately.
- Changing effort or speed mid-conversation invalidates the prompt cache, which can cost more than the effort saving returns. Set it per workload, not per request.
- Fast mode is exactly 2x for up to 2.5x output throughput, excludes the Batch API, and makes the fast-to-cheap spread 4x.
FAQ
How much does Claude Opus 5 cost?
$5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8. Cache reads cost $0.50 per million, and the Batch API halves both rates to $2.50 and $12.50. Our LLM API pricing comparison has the same figures for every current Claude, GPT, and Gemini model.
Is Claude Opus 5 better than Fable 5?
Anthropic reports Opus 5 within 0.5% of Fable 5's peak CursorBench 3.2 score at half the cost per task, and above Fable 5's best OSWorld 2.0 result at about a third of the cost. Those are the vendor's own numbers on benchmarks it selected, and we have not independently verified them. Fable 5 remains the higher tier at $10 and $50.
What are the Claude Opus 5 effort levels?
Five: low, medium, high, xhigh, and max. The API default is high, which behaves identically to omitting the parameter. Set it as output_config.effort on the request. No beta header is required.
Does lower effort make Claude's answers shorter?
Not reliably on Opus 5. Anthropic's documentation states that effort controls thinking volume rather than visible response length on this model, and recommends prompting for length if that is what you want.
What is Claude Opus 5 Fast mode?
A research-preview setting that delivers up to 2.5x higher output tokens per second at double the standard rate, $10 and $50 per million. It affects output throughput rather than time to first token, requires access through an account manager or the waitlist, runs on the first-party API only, and cannot be used with the Batch API.
Is Opus 5 available in Claude Code?
Yes, along with Claude.ai, Claude Cowork, and the API. It is the default model on Claude Max and the strongest model on Claude Pro.
Do effort levels change the price per token?
No. The rate card is fixed. Effort changes how many tokens get spent reaching an answer, which is why the saving depends on how output-heavy your workload is.
Written by
Software Developer @Bug0 | @Hashnode, Contributing writer to The Foreword by Hashnode







