Claude Opus 5's Effort Parameter: Trading Cost for Capability

Every mainstream write-up of the Claude Opus 5 launch on July 24, 2026 named the same feature. Fortune called it a way to toggle between cost and capability. CNBC, Bloomberg, and TechCrunch all pointed at it. None of them said what it is, what the levels are, what happens when you change one, or what it does to your bill.

It is a request parameter called effort, it has five levels on Opus 5, and it defaults to high. That is the whole feature. What makes it worth an article is that Anthropic recalibrated the levels for this model, which means the settings you tuned on Opus 4.8 are now wrong, and one specific combination of settings returns a 400 error that will show up in a lot of migration logs this week.

💡

If you want to try the levels against a real endpoint while you read, Apidog is a straightforward way to fire the same request at five different settings and compare what comes back.

button

What the effort parameter actually is

Effort lives in the output_config object on a Messages API request:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "output_config": { "effort": "high" },
  "messages": [
    { "role": "user", "content": "Refactor this module and explain the tradeoffs." }
  ]
}

It controls how much internal reasoning the model does before it answers. Opus 5 runs adaptive thinking on by default, and effort is the dial that sets how generously that thinking budget gets spent. Higher effort means more reasoning tokens, more cost, and more latency. Lower effort means fewer of all three.

Consumer surfaces expose the same idea as an effort selector rather than a raw JSON field, which is where the press framing of a cost-versus-capability toggle comes from. Under it is this parameter. If you build on the API, the parameter is the thing you actually control, so that is what the rest of this article talks about. The full request shape is in our Opus 5 API walkthrough, and the parameter reference lives in Anthropic’s models overview.

One thing effort is not: a verbosity control. Anthropic’s prompting guide for Opus 5 is explicit that lowering effort cuts thinking, not the length of the visible response. Opus 5 already writes longer default answers and longer deliverables than Opus 4.8. If you want shorter output, ask for shorter output in the prompt. Dropping to low will not do it for you.

The five levels

Level	What it does	Typical fit
`low`	Minimal reasoning before answering	High-volume classification, extraction, routing, short summaries
`medium`	Moderate reasoning	Q&A over retrieved context, single-file edits, structured transforms
`high`	Default. Substantial reasoning	General purpose work when you have not measured anything yet
`xhigh`	Extended reasoning	Coding and agentic loops. Anthropic’s recommended starting point for both
`max`	Maximum reasoning budget	Hard one-shot problems where a wrong answer costs more than tokens

Two things about this table are easy to skim past.

The default is high, not low and not xhigh. If you send a request with no output_config at all, you get high. That matters for cost forecasting: an untouched request on Opus 5 is doing real reasoning work and billing you for it, where the same untouched request on Opus 4.8 did no thinking at all. That change is one of the two breaking changes in the Opus 4.8 to Opus 5 migration, and it is the one most likely to surprise a finance team.

And xhigh is the recommendation for coding and agentic work, not max. Anthropic positions xhigh as where you start for those workloads. max exists above it, but starting there means paying for headroom you probably cannot measure a benefit from. Start at xhigh, then sweep down.

What recalibration changed

Here is the part that makes carrying settings across models a bad idea.

Anthropic recalibrated what each effort level means on Opus 5. The label medium on Opus 5 does not describe the same amount of reasoning that medium described on Opus 4.8. Anthropic’s guidance is to run a fresh effort sweep on Opus 5 rather than porting your 4.8 configuration over.

The practical consequence is more interesting than the warning. On previous Opus models, low and medium were mostly theoretical for serious work: they were cheap, and they were also noticeably worse, so teams parked everything at high or above and paid for it. On Opus 5 the lower levels are meaningfully stronger than they were, which is the first time low and medium are genuinely usable on an Opus-tier model for production tasks.

That is the actual cost lever in the launch, and it is the one the press coverage compressed into the word toggle. Opus 5 costs $5 per million input tokens and $25 per million output tokens, the same as Opus 4.8. Reasoning tokens land on the output side of that bill. So the difference between running a classification pipeline at high and running it at low is not a rounding error, it is a large fraction of your output spend on a workload where the extra reasoning was never buying you accuracy in the first place. Our Opus 5 pricing breakdown has the full rate card, including the 50% batch discount and the 512-token cache minimum, both of which stack with a lower effort setting.

If you are hunting for savings across a whole Claude estate rather than one endpoint, the levers in cutting your Claude API bill apply here too, with effort now added to the list.

The `xhigh` and `max` interaction with `max_tokens`

max_tokens caps thinking tokens plus response tokens together. It is a hard ceiling on the whole output side of the request, not just the visible text.

Raise effort and you raise how much of that ceiling the model spends on reasoning before it starts writing. Push effort to xhigh or max while leaving max_tokens at a value you sized for a model that was not thinking, and the model can burn the budget reasoning and truncate before it finishes the answer. You get a cut-off response with nothing obviously wrong in the request.

The fix is to give it room. Anthropic’s guidance is to start at max_tokens: 64000 when you run xhigh or max on Opus 5:

{
  "model": "claude-opus-5",
  "max_tokens": 64000,
  "output_config": { "effort": "xhigh" },
  "messages": [
    { "role": "user", "content": "Fix the failing integration test and explain the root cause." }
  ]
}

A high max_tokens is a ceiling, not a purchase. You are billed for tokens actually produced, so setting 64000 does not mean paying for 64000. It means the model is not forced to stop mid-thought.

The 400 error nobody has written up yet

This one is going to generate support tickets.

Disabling thinking and requesting high effort are contradictory instructions, and Opus 5 rejects the combination outright. Sending thinking: {type: "disabled"} together with effort xhigh or max returns a 400, enforced per request:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "thinking": { "type": "disabled" },
  "output_config": { "effort": "xhigh" }
}

That request fails. Disabling thinking caps you at high effort. So the valid combinations are:

Thinking on (default) with any of the five levels.
Thinking disabled with low, medium, or high only.

The migration path that produces this error is predictable: a team carries over thinking: {type: "disabled"} from an Opus 4.8 config where it was harmless, then separately bumps effort to xhigh because that is the coding recommendation. Both edits look reasonable in isolation. Together they 400.

Anthropic’s own advice is to not disable thinking on Opus 5 at all. With thinking off, two failure modes show up occasionally: the model writes tool calls as plain text that never execute, and internal XML tags leak into the visible output. In an agentic loop the leaked text then poisons later turns. The recommended way to control cost on Opus 5 is a lower effort level, not disabled thinking. We go deeper on both artifacts in the Opus 5 prompting guide.

How to run an effort sweep on your own evals

Anthropic tells you to re-sweep. Here is a procedure that fits in an afternoon.

1. Freeze a task set. Pull 30 to 50 real prompts from production logs, not synthetic examples. Include the hard cases you actually worry about. Effort differences vanish on easy tasks, which is exactly why a clean sample set will tell you nothing.

2. Write down the pass criterion before you look at any output. Tests green, JSON validates against a schema, extracted field matches ground truth, a human rater says yes or no. If your criterion is a vibe, your sweep produces a vibe.

3. Run every prompt at every level. Five levels times 40 prompts is 200 calls. On Opus 5 that is cheap enough to not think about, and you can send it through the Batch API at half price since nothing is latency-sensitive.

4. Capture three numbers per run, not one: pass or fail, usage.output_tokens, and wall-clock latency. The usage block in the response is where the real cost signal lives, because it counts the reasoning tokens you would otherwise be guessing at.

5. Pick the cheapest level that clears your bar, then confirm it on a holdout set you did not tune against. Teams that skip the holdout tend to ship a setting fitted to 40 specific prompts.

6. Re-run it on the next model. The whole reason this sweep exists is that levels were recalibrated between 4.8 and 5. Assume it happens again.

Comparing levels side by side in Apidog

The mechanical part of a sweep is sending one request body five times with one field changed and lining up what comes back. That is a fair amount of curl copy-paste, and it is the part Apidog makes tidy.

A setup that works:

Create a request against the Anthropic Messages endpoint and store your key as an environment variable rather than pasting it into the body. Keys stay out of anything you share with the team.
Save the working request into a collection, then duplicate it five times and change only output_config.effort in each copy.
Inspect the usage object on each response so you can see output tokens per level directly, plus cache_read_input_tokens when you are checking whether your caching is landing.
Turn on streaming and read the SSE events if you want to watch where latency actually goes at xhigh versus low.
Add an assertion that stop_reason is present and is not max_tokens, so a truncated xhigh response fails loudly in your collection instead of quietly looking like a short answer.

That last assertion is the one worth setting up first, because a truncation at high effort is the single most likely thing to go wrong. Download Apidog if you want to build the comparison collection while you read. Nothing here requires it; it just beats maintaining five shell scripts.

The honest ceiling

Effort makes Opus 5 cheaper to run well. It does not make Opus 5 the top of the Claude stack.

Anthropic’s own launch numbers for Opus 5 are strong: more than double Opus 4.8’s Frontier-Bench v0.1 score, roughly 3x the next-best model on ARC-AGI 3, and within 0.5% of Fable 5 on CursorBench 3.2 at half the price. All of those are vendor-run figures, published by Anthropic, and none have been independently reproduced as of July 25, 2026. Treat them as claims with a source, not as neutral measurements, and see our Opus 5 benchmarks breakdown for the caveats on each one.

Above Opus 5, Fable 5 is still Anthropic’s most capable widely released model, at $10 per million input and $50 per million output. And Opus 5 still trails Mythos 5 on cybersecurity exploitation and autonomous biology research, which Anthropic states directly. Running Opus 5 at max does not close either gap. The honest summary is frontier-class capability at half the frontier price, with a named ceiling above it. Whether the price difference is worth it for your workload is the question we work through in Opus 5 vs Fable 5.

button

FAQ

What is the default effort level on Claude Opus 5? high. A request with no output_config field runs at high effort with adaptive thinking on.

What are the five effort levels? low, medium, high, xhigh, and max. Anthropic recommends starting at xhigh for coding and agentic work, and sweeping down from there against your own evaluations.

Why does my request return a 400 when I set effort to xhigh? Almost certainly because you also sent thinking: {type: "disabled"}. Disabling thinking caps effort at high, and the combination is rejected per request. Either remove the disabled-thinking block or drop effort to high or below.

Can I reuse my Opus 4.8 effort settings on Opus 5? No. The levels were recalibrated, so the same label means a different amount of reasoning. Anthropic asks you to run a fresh sweep. The full list of what changed is in the migration guide.

Does lowering effort make responses shorter? No. Effort controls reasoning, not visible length, and Opus 5’s default responses run longer than Opus 4.8’s. Prompt for conciseness explicitly if you want shorter output.

What max_tokens should I use at xhigh or max? Start at 64000. max_tokens caps thinking and response together, so a budget sized for a non-thinking model will truncate. You are only billed for tokens produced, so the high ceiling costs nothing on its own.

For the full spec sheet, availability matrix, and pricing context around all of this, start with what Claude Opus 5 is.