Manu Shukla

Posted on Jul 26 • Originally published at ecorpit.com

Claude Opus 5 effort levels: cut token costs with 5 reasoning dials (2026)

#claudeopus5 #aicost #effortparameter #llmfinops

Claude Opus 5 effort levels: cut token costs with 5 reasoning dials (2026)

Summary. Anthropic shipped Claude Opus 5 on 24 July 2026 at $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8, with a 1M-token context window, 128k maximum output, and thinking on by default. The model added one control that matters more than the price tag: a five-level effort parameter, from low through medium, high, xhigh and max, that sets how many tokens Claude spends on every request. Because you pay per token, effort is a direct spend dial. Anthropic reports Opus 5 at 96.0% on SWE-bench Verified and calls it frontier intelligence at half the cost of Claude Fable 5. OpenAI answers the same cost problem differently: its GPT-5.6 line, generally available since 9 July 2026, splits into three priced models (Sol at $5/$30, Terra at $2.50/$15, Luna at $1/$6 per million tokens). Opus 5 keeps one model and moves the dial instead. This guide explains what the dial controls, when each level pays off, and the five mistakes that quietly inflate the bill.

What the effort parameter actually controls

The effort parameter sets how many tokens Claude spends when it answers, trading response thoroughness against token efficiency on a single model. By default the API runs at high, and setting effort to high produces exactly the same behavior as omitting the parameter. You lower it to be more conservative with tokens, or raise it to max for the highest capability with no constraint on spend.

The reason this is a spending control and not just a quality knob is scope. Effort affects all tokens in the response: the visible text, the tool calls and their arguments, and the thinking tokens when thinking is active. Anthropic is explicit that lower effort means Claude makes fewer tool calls, combines operations, and drops the preamble around actions. On a chatty agent that fans out dozens of tool calls per task, cutting the number of calls and the text around them removes billed output tokens that a shorter prompt alone would never touch.

Two design choices make effort the primary cost lever on Opus 5. First, thinking is on by default: the model decides when and how deeply to think on each turn, and effort is the control for that depth. Second, Anthropic states that Opus 5 converts additional effort into better results more reliably than any earlier Opus model, which cuts both ways. Stepping up buys real quality on hard work, and stepping down on easy work drops tokens with little loss, because low and medium produce strong quality at a fraction of the tokens and latency of the higher settings.

The five effort levels, and when each one pays off

Opus 5 supports the full ladder. The table below maps each level to its documented behavior and the workload where it earns its cost, drawn from Anthropic's effort reference.

Effort level	What it does	Best-fit workload on Opus 5
`low`	Most efficient; significant token savings with some capability reduction	High-volume classification, quick lookups, subagents, simple well-scoped edits
`medium`	Balanced; moderate token savings	Everyday agentic tasks that need speed, cost and performance in balance
`high` (default)	Full capability; equal to omitting the parameter	Complex reasoning, difficult coding, nuanced analysis where quality leads
`xhigh`	Extended capability for long-horizon work	Coding and agentic runs over 30 minutes with token budgets in the millions
`max`	Absolute maximum capability, no cap on token spend	Genuinely frontier problems that justify unconstrained spend

Anthropic's own guidance for Opus 5 is to start at the high default and adjust from evals: step up to xhigh for demanding coding and agentic work, up to max when a task justifies unconstrained spend, and use low and medium liberally as the primary control for token cost and response time wherever your evals show quality holds. The company also warns against reusing effort settings carried over from an earlier model and recommends a fresh effort sweep on your own evaluation set.

The worked cost math: what the dial is worth

Prices are fixed at $5 per million input tokens and $25 per million output tokens across every effort level, so savings come entirely from token volume, mostly output tokens (thinking plus tool calls plus text). The table below is an illustration, not a benchmark: the per-request token counts are assumptions to show the shape of the saving, and you should replace them with measured numbers from your own workload before you budget against them.

Assume a constant 4,000 input tokens per request and output volume that scales with effort, priced at $5/$25 per million, across 100,000 requests per month.

Effort level	Assumed output tokens/request	Cost per request (in + out)	Monthly cost at 100k requests	Change vs high
`low`	1,500	$0.0575	$5,750	66% cheaper
`medium`	3,000	$0.095	$9,500	44% cheaper
`high` (default)	6,000	$0.17	$17,000	baseline
`xhigh`	12,000	$0.32	$32,000	88% dearer

The point is not the exact figures, which depend on your prompts. The point is the slope. Moving a high-volume, low-complexity queue from high to low roughly two-thirds off the output bill, and the drop from high to medium is close to half, because output tokens are five times the price of input tokens and effort moves output volume the most. The same slope runs the other way: xhigh and max are worth it on the small share of work that genuinely needs them, and expensive everywhere else. Anthropic makes the same point about max in its own words, noting it adds significant cost for relatively small quality gains on most workloads. For a deeper split of Opus 5 spend on coding agents, see our note on Claude Opus 5 for coding agents and its cost against Fable.

One model with five dials, or three priced models

The effort approach is a genuine fork from how OpenAI prices the same decision. GPT-5.6, generally available across ChatGPT, Codex and the API since 9 July 2026, ships as three separate models at three price points, and you cut cost by selecting a smaller model. Opus 5 keeps one set of weights and cuts cost by spending fewer tokens on it. The trade-off is different in each case.

Dimension	Claude Opus 5 (effort dial)	OpenAI GPT-5.6 (Sol, Terra, Luna)
Cost control	One model, five effort levels set per request	Three models, pick the tier per request
Price per 1M tokens (in / out)	$5 / $25, flat across every effort level	Sol $5 / $30, Terra $2.50 / $15, Luna $1 / $6
What the cheaper setting changes	Fewer tokens across thinking, tool calls, text	A smaller model with less underlying capability
Quality trade-off	Same weights, less deliberation	Different model weights entirely
Control granularity	Per request, five steps on one model	Per request, three models

Both are valid. A three-tier line gives a hard floor on price: Luna at $1/$6 is cheaper than anything Opus 5 will reach, because the cheapest Opus 5 request still bills the Opus rate. The effort dial gives finer control on one quality profile: you keep the same model's judgement and pull tokens out where the task does not need them, without re-testing a different model's behavior. Teams already running an evaluation harness tend to prefer the dial, because varying one parameter is cheaper to validate than qualifying a second model. For the tier-by-tier view of the OpenAI side, see our GPT-5.6 Sol, Terra and Luna tier-selection guide and the companion GPT-5.6 inference-cost breakdown for enterprise AI.

How to set effort in code

Effort is a request-level field inside output_config. Each request carries its own value, so you can run different parts of a workflow at different levels. This example runs a routine analysis at medium to save tokens:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Summarize this support ticket and tag its priority."}
    ],
    output_config={"effort": "medium"},
)

To push a hard problem to the ceiling, set effort to max and raise max_tokens so the model has room to think and act. Anthropic suggests starting at 64k tokens for xhigh and max and tuning from there:

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "max"},
    messages=[
        {"role": "user", "content": "Refactor this module and prove the invariants hold."}
    ],
) as stream:
    final = stream.get_final_message()

Five gotchas that quietly cost money or break requests

The dial is simple, but Opus 5 changed enough behavior that carried-over habits will either overspend or error out. These five are worth putting in a code review checklist.

First, changing effort mid-conversation invalidates the prompt cache. Effort shapes the rendered prompt, so a different value on the next request does not preserve cached prefixes from earlier turns. On a long session that relies on prompt caching for its economics, pick one effort level at the start and hold it constant; vary effort across workloads, not within a cached conversation.

Second, max_tokens is a hard limit on total output, thinking plus response text. Because thinking is on by default in Opus 5, a max_tokens value tuned for the no-thinking Opus 4.8 can now truncate answers. Revisit it, and set it generously at xhigh and max.

Third, disabling thinking at high effort now errors. On Opus 5, thinking: {"type": "disabled"} is accepted only when effort is high or below; combine it with xhigh or max and the request returns a 400 error. Either keep thinking disabled and hold effort at high or below, or keep the effort level and remove the thinking field.

Fourth, on Opus 5 effort does not reliably shorten the visible response. Effort controls thinking volume, not output length, so if you want shorter user-facing answers to save output tokens, prompt for length explicitly rather than dropping effort and expecting terse prose.

Fifth, remove verification instructions carried from older models. Opus 5 verifies its own work without being told to, so lines like "include a final verification step" or "use a subagent to verify" cause over-verification and extra tokens. Delete them and let the model self-check.

A routing strategy that maps tasks to effort

The saving comes from routing, not from a single global setting. Treat effort as a per-task attribute and set it at the point you dispatch work. A workable default map for an Opus 5 estate looks like this: classification, extraction, routing and other high-volume, well-scoped jobs go to low; subagents doing narrow sub-tasks in a larger plan also run low, which Anthropic names as a fit; general agentic and knowledge work sits at medium; the default high covers difficult coding and nuanced analysis; and only long-horizon coding runs, repeated tool calling and deep exploration climb to xhigh, with max reserved for the rare frontier problem.

Two habits keep the map honest. Run an effort sweep on your evals whenever you change models or prompts, because Opus 5 respects the levels differently from earlier Opus models. And meter spend by effort level in your logs, so a queue silently pinned at high when low would hold quality shows up as a line item rather than a surprise at month end. Our broader take on measuring return sits in the AI coding productivity paradox and the ROI plateau.

India-specific considerations

For teams billing in rupees, the effort dial is a rupee-budget lever, because the Anthropic API prices in US dollars and the rupee traded near 96 to the dollar through late July 2026. The illustrative high-effort load above, at $17,000 a month, is roughly 16.3 lakh rupees; the same queue at low effort, at $5,750, is about 5.5 lakh rupees. On high-volume, low-complexity Indian workloads such as vernacular support triage, KYC document tagging or catalogue classification, that gap is the difference between an AI feature that clears its unit economics and one that does not.

Two India-specific notes. Route personally identifiable data with the Digital Personal Data Protection Act 2023 in mind: effort changes token spend, not where data is processed, so pair a low-effort classification queue with the data-residency and consent controls your deployment already requires. And model effort routing alongside your cloud spend rather than in isolation, since inference is now a top line in most AI budgets; our guide to AI cloud cost control across AWS, Azure and GCP in India covers the surrounding infrastructure bill.

FAQ

What is the effort parameter in Claude Opus 5?

It is a request-level control that sets how many tokens Claude spends when answering, trading thoroughness against token efficiency on one model. It affects text, tool calls and thinking tokens. Opus 5 supports five levels: low, medium, high, xhigh and max, with high as the default.

Does changing effort change the price per token?

No. Claude Opus 5 bills $5 per million input tokens and $25 per million output tokens at every effort level, unchanged from Opus 4.8. Lower effort saves money only by spending fewer tokens, mostly output tokens across thinking and tool calls, not by lowering the per-token rate.

What is the default effort level on the Claude API?

The API defaults to high effort, and setting effort to high behaves exactly like omitting the parameter. Anthropic recommends starting at high on Opus 5, then stepping down to medium or low where your evaluations show quality holds, or up to xhigh and max for demanding work.

Why does disabling thinking sometimes return a 400 error?

On Claude Opus 5, thinking cannot be disabled at xhigh or max effort. A request that sets thinking to disabled with either of those levels returns a 400 error. Keep thinking disabled only at high effort or below, or keep the high effort level and remove the thinking field entirely.

How much can lower effort save?

Savings scale with the token volume you remove, since price is fixed. In an illustrative model at 100,000 requests a month, moving from high to medium cut the bill about 44%, and high to low about 66%. Real savings depend on your prompts, so measure on your own workload first.

How is this different from OpenAI's GPT-5.6 tiers?

GPT-5.6 splits into three priced models, Sol, Terra and Luna, and you cut cost by choosing a smaller model. Opus 5 keeps one model and cuts cost by spending fewer tokens through the effort dial. One gives a lower price floor; the other gives finer control on a single quality profile.

Does effort make Claude Opus 5 write shorter answers?

Not reliably. On Opus 5 the effort parameter controls thinking volume, not visible output length, so lowering effort will not dependably shorten the response text. If you want shorter user-facing answers to save output tokens, prompt for length explicitly instead of relying on a lower effort level.

Should I set max_tokens differently on Opus 5?

Yes. Because thinking is on by default and max_tokens is a hard limit on total output, thinking plus text, a value tuned for Opus 4.8 can truncate Opus 5 answers. Revisit it, and set it generously, starting near 64,000 tokens, when running at xhigh or max effort.

How eCorpIT can help

eCorpIT is a Gurugram technology consultancy, founded in 2021 and assessed at CMMI Level 5, that builds and runs production AI systems for global and Indian teams. We design effort-routing and model-selection layers that hold answer quality on your own evaluation set while metering spend by effort level, so a queue that could run at low is never quietly billed at high. As partners of AWS, Microsoft and Google, we deploy Claude Opus 5 and comparable models across the Claude API, Amazon Bedrock and cloud endpoints with cost telemetry built in. To scope an AI cost review or an effort-routing design, contact our team.