Claude Effort Levels, Cost Levers and Breaking Changes Across Model Releases

1.Effort: the tradeoff inside one model

Effort controls how many tokens Claude spends on a response. It applies to every output token: text, tool calls and thinking. So it works with or without thinking, and lower effort also means fewer and shorter tool calls. You set it with output_config.effort.

Each model has its own recommended effort settings, and they override the general table above:

- Fable 5.1 and Opus 5: start at high. Step up to xhigh or max for capability-sensitive work, and step down wherever your evals show quality holds. - Opus 5.5: medium is the default. Thinking is always on there, so effort is the main control over how much the model reasons and what a request costs. - Opus 4.8 and 4.7: start at xhigh for coding and agentic work, and use high as the minimum for other intelligence-sensitive work. The API default is still high, so to get xhigh you have to set it explicitly.

At xhigh or max, set a large max_tokens. It is a hard cap on thinking plus response text, and 64k is a reasonable place to start.

Sources12

2.Choosing the right cost lever

The cost guidance splits levers into two groups:

- Free wins cut spend without lowering quality: prompt caching, trimming unneeded tokens, a prompt audit, batch processing at 50% off, and spend limits. - Tradeoffs give up some intelligence to save cost: model choice, effort, output caps and task budgets, an elapsed-time clock, and multi-model architectures.

Model selection is in the second group. That is why it should follow evidence, not a price list.

Two rows need a closer look. A model with a higher price per token can still cost less overall if it finishes more tasks, so compare models on cost per completed task. And when quality is too low, the first fix is to undo an effort cut, not to jump straight to the most expensive tier.

Multi-model setups pair a cheaper model with a frontier model, so most tokens are billed at the lower rate. There are two common patterns:

- An executor handles the work and passes hard decisions to an advisor. - An orchestrator hands bulk work out to cheaper workers.

Anthropic labels its measured results directional, so measure on your own workload.

Sources32

3.Breaking changes when moving to a newer model

A newer model is not always a drop-in replacement. Claude Opus 5.5 is cheaper than Claude Opus 5 ($4 / $20 against $5 / $25 per million input/output tokens), but it rejects several request patterns that earlier models accepted. Each rejected setting returns a 400 error.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Analyze the trade-offs between microservices and monolithic architectures",
        }
    ],
    output_config={"effort": "medium"},
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Response parsing can break too:

- Reading by position. Opus 5.5 always thinks, so a response can start with thinking blocks. Code that reads content[0].text, or treats the first streamed block as text, breaks. Read blocks by their type field instead, as the loop above does. - Tool-use loops. Pass thinking blocks back complete and unmodified, including the empty ones. Edited, reordered or dropped blocks get a 400 error. - Streamed reasoning. Display defaults to "omitted", so a product that shows reasoning to users will look like it is stuck. - Routers and fallbacks. If a conversation can move from Opus 5.5 to another model, expect that model to run without Opus 5.5's thinking blocks. Fable 5.1 and Mythos 5.1 on the Claude API are the exception.

Some changes alter behaviour without any error. Claude Opus 4.7 follows effort levels more strictly than 4.6, especially at low and medium, where it limits its work to what was asked. If reasoning looks shallow, the docs say to raise effort rather than work around it in the prompt.

Sources41

4.Re-baselining after a switch

Fixing the request is only half the migration. Settings tuned on the old model don't carry over:

- Effort. Run a new effort sweep on your own evals instead of reusing the old value. - Cost and latency. Measure both again at the effort level you choose. - max_tokens. Workloads that used to run without thinking now think on every request. Those thinking tokens are billed as output and count against max_tokens, so raise it (start at 64k for xhigh or max). Lower effort if you want less thinking. - Capacity. Plan it separately if you rely on Priority Tier, which Opus 5.5 does not support.

The model table also lists retirement dates, such as "not sooner than October 15, 2026" for Haiku 4.5. That lets you schedule a migration before a model is retired.

Sources4

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Leaving effort unset on Claude Opus 5.5 gives the same reasoning depth as it did on Claude Opus 5.Why is that wrong?

   Opus 5.5 defaults to medium, while Opus 5 and earlier Opus models default to high. The same request runs one level lower unless you set effort explicitly.

   Covered in Effort: the tradeoff inside one model

2. 2.On Claude Opus 5.5 you can still disable thinking at low effort to save tokens, as on Claude Opus 5.Why is that wrong?

   Opus 5.5 rejects thinking: {"type": "disabled"} at every effort level. Lowering effort is the only way to reduce thinking.

   Covered in Breaking changes when moving to a newer model

3. 3.The model with the lowest price per token is the cheapest choice.Why is that wrong?

   Model comparisons should use cost per completed task. A model that solves more tasks can cost less overall even if its per-token price is higher.

   Covered in Choosing the right cost lever

Practise it for real

Watch Claude Opus 5.5's breaking changes happen in a real request

1. 1.Send the documented claude-opus-5-5 request with output_config={"effort": "medium"} and print only the blocks whose type is "text".

   Why: Shows the recommended request shape and reading blocks by type.

   You should see: A text answer is printed, and response.content also holds a thinking block ahead of it.

2. 2.Print the type and thinking field of response.content[0].

   Why: Shows why content[0].text is unsafe on this model.

   You should see: A thinking block whose thinking field is empty, because display defaults to "omitted".

3. 3.Add thinking={"type": "disabled"} to the same request and send it again.

   Why: Confirms that thinking cannot be turned off on Opus 5.5.

   You should see: A 400 error.

4. 4.Remove the thinking field, and send the request again at effort low and at effort high, comparing output token usage.

   Why: Effort, not a thinking switch, controls reasoning depth and cost here.

   You should see: The high-effort request uses more output tokens than the low-effort one.