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 explained what it is, what the levels are, what changes when you switch one, or what it does to your bill.

Try Apidog today

It is a request parameter named effort. Opus 5 supports five levels, and the default is high. Anthropic also recalibrated these levels for this model, so settings tuned for Opus 4.8 do not directly transfer. There is also one invalid configuration that returns a 400 error and can affect Opus 4.8-to-Opus-5 migrations.

💡 If you want to test the levels against a real endpoint, use the same request at five different settings and compare the responses, usage, and latency. Apidog can help organize those comparisons.

What the effort parameter actually is

Set effort inside the output_config object of 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."
    }
  ]
}

effort controls how much internal reasoning the model performs before responding. Opus 5 enables adaptive thinking by default, and effort sets how generously the model spends its thinking budget.

In practice:

• Higher effort means more reasoning tokens, higher cost, and more latency.
• Lower effort means fewer reasoning tokens, lower cost, and less latency.

Consumer interfaces expose this as an effort selector, which explains the “cost versus capability” framing in launch coverage. For API users, the JSON field is the actual control surface.

See the full request structure in the Opus 5 API walkthrough, and refer to Anthropic’s models overview for parameter details.

effort is not a verbosity setting

Lowering effort reduces internal thinking, not the visible response length. Anthropic’s Opus 5 prompting guide explicitly distinguishes the two.

If you need shorter output, specify that in your prompt:

Return a concise answer in no more than five bullet points.

Do not expect effort: "low" to automatically produce shorter responses.

The five effort 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 before you have eval data
xhigh	Extended reasoning	Coding and agentic loops; Anthropic’s recommended starting point
max	Maximum reasoning budget	Hard one-shot problems where a wrong answer costs more than tokens

Two details matter when applying this table.

First, the default is high. If you omit output_config, Opus 5 runs at high effort. That affects cost forecasting: an unchanged Opus 5 request performs meaningful reasoning and bills for it, while an unchanged Opus 4.8 request did no thinking.

This is one of the breaking changes in the Opus 4.8 to Opus 5 migration, and it can surprise teams that budgeted based on previous defaults.

Second, use xhigh, not max, as the initial setting for coding and agentic workloads. Anthropic positions xhigh as the recommended starting point. Start there, measure results, and sweep downward before paying for max.

What recalibration changed

Anthropic recalibrated the meaning of each effort level for Opus 5.

In other words, medium on Opus 5 does not represent the same reasoning budget as medium on Opus 4.8. Do not copy old effort configurations unchanged. Run a new effort sweep on Opus 5.

The practical impact is that lower effort levels are more useful than they were on earlier Opus models. Previously, low and medium were often too weak for serious production work, so teams defaulted to high or above. On Opus 5, lower levels are stronger and can be viable for production workloads.

That makes effort a real cost-control lever.

Opus 5 costs $5 per million input tokens and $25 per million output tokens, the same as Opus 4.8. Reasoning tokens are billed on the output side. If a classification pipeline works equally well at low instead of high, the difference can represent a substantial part of output-token spend.

See the Opus 5 pricing breakdown for the full rate card, including the 50% batch discount and 512-token cache minimum. Both can stack with lower effort settings.

For broader optimization ideas, see how to cut your Claude API bill.

How xhigh and max interact with max_tokens

max_tokens caps thinking tokens and visible response tokens together. It is a hard ceiling for the entire output side of the request.

When you raise effort, the model can use more of that budget for reasoning before it starts generating visible text. If you use xhigh or max with a max_tokens value sized for a non-thinking model, the request may truncate before the response is complete.

For xhigh and max, Anthropic recommends starting at max_tokens: 64000:

{
  "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 larger max_tokens value is a ceiling, not a prepaid commitment. You are billed for tokens actually generated, not for the full limit. Setting 64000 gives the model room to reason and respond without forcing an early cutoff.

The 400 error: disabled thinking with xhigh or max

Disabling thinking while requesting high effort is a contradictory configuration.

This request fails with a 400:

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

When thinking is disabled, effort is capped at high.

Valid combinations are:

• Thinking enabled, which is the default, with any of the five effort levels.
• Thinking disabled with low, medium, or high.

A common migration failure looks like this:

1. A team carries over thinking: { "type": "disabled" } from an Opus 4.8 configuration.
2. The team sets effort to xhigh because it is recommended for coding or agents.
3. The request returns 400.

Anthropic recommends not disabling thinking on Opus 5. With thinking disabled, the model can occasionally write tool calls as plain text instead of executable tool calls, and internal XML tags can leak into visible output. In agentic workflows, leaked text can contaminate subsequent turns.

Use a lower effort level to control cost instead of disabling thinking. See the Opus 5 prompting guide for more on these artifacts.

How to run an effort sweep on your own evals

Anthropic recommends re-sweeping effort levels. Here is a practical process.

1. Freeze a representative task set

Select 30 to 50 real prompts from production logs. Include difficult cases, not only clean or easy examples.

Effort differences are often invisible on trivial tasks. A synthetic or overly simple sample will not tell you whether higher reasoning is worth the cost.

2. Define a pass criterion before reviewing results

Use an objective success condition where possible:

• Tests pass.
• JSON validates against a schema.
• Extracted values match ground truth.
• A human reviewer gives a binary pass/fail rating.

Avoid relying on subjective impressions alone.

3. Run each prompt at every effort level

For 40 prompts across five effort levels, you will run 200 calls.

Because the sweep is not latency-sensitive, you can use the Batch API at half price.

4. Record pass rate, output tokens, and latency

Capture at least these values per run:

• Pass or fail
• usage.output_tokens
• Wall-clock latency

The usage object provides the direct cost signal because it includes reasoning-related output token usage that would otherwise be difficult to estimate.

5. Choose the cheapest effort level that meets your quality bar

Do not choose the highest-performing level automatically. Choose the lowest-cost setting that reliably meets your acceptance criteria.

Then validate the selected level against a holdout set that was not used for tuning.

6. Repeat the sweep for future model upgrades

The purpose of this process is that effort levels can be recalibrated between models. Treat effort settings as model-specific configuration, not permanent infrastructure defaults.

Comparing levels side by side in Apidog

The mechanical part of a sweep is simple but repetitive: send the same request five times while changing only one field.

A practical setup in Apidog:

1. Create a request for the Anthropic Messages endpoint and store your API key in an environment variable instead of embedding it in the request body.
2. Save the working request in a collection.
3. Duplicate it five times.
4. Change only output_config.effort in each copy.
5. Compare the usage object for output tokens at each level.
6. Check cache_read_input_tokens when validating cache behavior.
7. Enable streaming and inspect SSE events to compare latency at xhigh versus low.
8. Add an assertion that stop_reason exists and is not max_tokens.

That last assertion catches truncated responses explicitly instead of letting them look like unexpectedly short answers.

Download Apidog if you want to build and share the comparison collection. It is not required, but it is easier to maintain than five separate shell scripts.

The honest ceiling

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

Anthropic’s 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.

These are vendor-run figures published by Anthropic and had not been independently reproduced as of July 25, 2026. Treat them as sourced claims, not neutral measurements. See the Opus 5 benchmarks breakdown for caveats on each benchmark.

Above Opus 5, Fable 5 remains Anthropic’s most capable widely released model, at $10 per million input tokens and $50 per million output tokens.

Opus 5 also trails Mythos 5 on cybersecurity exploitation and autonomous biology research, according to Anthropic. Running Opus 5 at max does not close those gaps.

The practical summary: Opus 5 offers frontier-class capability at half the frontier price, but it has a defined ceiling. Whether the higher-tier price is justified depends on your workload. See Opus 5 vs Fable 5 for that comparison.

FAQ

What is the default effort level on Claude Opus 5?

high. A request without output_config runs at high effort with adaptive thinking enabled.

What are the five effort levels?

low, medium, high, xhigh, and max. Anthropic recommends starting at xhigh for coding and agentic work, then sweeping downward against your own evaluations.

Why does my request return a 400 when I set effort to xhigh?

You likely also sent thinking: { "type": "disabled" }. Disabling thinking caps effort at high, and xhigh or max is rejected. Remove the disabled-thinking configuration or use high or below.

Can I reuse my Opus 4.8 effort settings on Opus 5?

No. The effort levels were recalibrated, so the same label represents a different reasoning budget. Run a fresh sweep. See the migration guide for the full change list.

Does lowering effort make responses shorter?

No. Effort controls internal reasoning, not visible response length. Prompt explicitly for concise output if that is your goal.

What max_tokens value should I use with xhigh or max?

Start at 64000. max_tokens covers both thinking and visible response tokens, so a limit sized for a non-thinking request can cause truncation. You are billed only for generated tokens, not the full maximum.

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