Opus 5 shipped July 24 at $5 per million input tokens and $25 per million output — unchanged from Opus 4.8. The price list didn't move, but the biggest lever on what you actually pay did: a five-rung effort dial. Most teams never touch it, so they run every request at the high default and overpay for classification jobs that a lower setting would nail for a fraction of the tokens.

The whole idea: one request-level field, output_config.effort, tells Opus 5 how hard to work. Lower it for cheap, high-volume work; raise it for the hard stuff. On Opus 5, Anthropic's own guidance is to use low and medium liberally wherever your evals show quality holds — this is the intended primary control for cost and latency, not an edge case.

1. The five levels#

low · medium · high (default) · xhigh · max. Setting high is identical to omitting the field. The rest trade capability for token efficiency in both directions:

import anthropic
client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    output_config={"effort": "low"},   # <- the lever
    messages=[{"role": "user", "content": "Classify this ticket: …"}],
)

The same field exists in every SDK (output_config: { effort: "low" } in TypeScript, OutputConfig.Effort in C#/Go/Java). No beta header required.

2. Why it beats lowering max_tokens#

max_tokens is a ceiling — it truncates a response that runs long. It saves nothing on a response that was going to be short anyway, and it can cut off a good answer mid-thought. effort is different: it changes the model's behavior across all tokens — text, thinking, and tool calls alike. At lower effort Opus 5 thinks less, makes fewer tool calls, combines operations, and skips the preamble. In a tool-heavy agent, fewer tool calls is often where the real bill lives, and that's exactly the axis effort moves and max_tokens can't.

effort is the only dial that turns down tool calls, thinking, and prose at once. max_tokens just caps the ceiling.

Set both: effort to economize, max_tokens as a guardrail.

3. Route work by effort, don't set it once#

The mistake is picking one level globally. The win is routing by job — the same instinct behind enforcing a token budget on an agent, applied per request:

Then do the one measurement that matters: an effort sweep on your eval set. Run the same tasks at low, medium, and high, and compare cost per completed task — not cost per token. A cheaper setting that holds quality is free money; one that needs a retry costs more, which is why one tokens-per-second number lies to you.

4. Two gotchas that bite#

Effort is not a length control. On Opus 5 it governs thinking volume, not the length of the visible answer — lowering it does not reliably produce a shorter response. If you need brevity, ask for it in the prompt. Treat cost and length as two separate knobs.

You can't disable thinking at the top. Opus 5 runs thinking on by default, and thinking: {"type": "disabled"} is rejected with a 400 error at xhigh or max effort. This is a breaking change from Opus 4.8. Keep thinking on and control cost with lower effort instead — it's the cheaper path anyway. (More on the Opus 5 migration breaking changes.)

And one caching note: because effort shapes the rendered prompt, changing it mid-conversation invalidates your prompt cache. Pick a level at the start of a cached session and hold it constant; vary effort across workloads, not within one cached thread.

The takeaway you can ship today#

Audit your top three highest-volume Opus calls. If they're running at the high default and they're classification, extraction, or subagent work, drop them to low or medium, run your eval set once, and compare cost per completed task. For most teams that's a same-afternoon change that quietly takes a chunk off the monthly bill — the kind of cost move that matters more than a benchmark in the current market.