Claude Opus 5: The Effort Ladder and a Million Tokens

Claude Opus 5 is a straightforward upgrade over Opus 4.8 at the same price, and the interesting part for anyone building on it is not the benchmark numbers. It is that the model’s configuration surface has settled into a shape that is genuinely different from a year ago: you no longer choose whether the model reasons, you choose how much budget it has to.

Thinking is now the default

On Opus 4.8, requests ran without thinking unless you explicitly set thinking: {"type": "adaptive"}. On Opus 5 the same request runs with thinking on, and the model decides when and how much to think on each turn. The wire value is unchanged — adaptive remains valid and is equivalent to the default.

One breaking change to audit before migrating: thinking: {"type": "disabled"} is accepted only at effort high or below. Combining it with xhigh or max returns a 400. Opus 4.8 accepted that combination, so if your code disables thinking anywhere, check what effort level accompanies it.

The effort ladder

Effort is set at output_config.effort, not inside the thinking object, and it is the primary lever for balancing quality against cost and latency.

• low — minimises thinking, skips it entirely for simple tasks where speed matters most.
• medium — moderate thinking, may skip it for simple queries.
• high (default) — almost always thinks, with deep reasoning on complex tasks.
• xhigh — always thinks deeply, with extended exploration.
• max — always thinks, with no constraints on depth.

Anthropic’s guidance is that Opus 5 converts additional effort into better results more reliably than earlier Opus models, which means the level you pick carries more weight than it used to. Start at high, then move in both directions based on your evaluations: down where quality holds, to save tokens and latency, and up for the most demanding work.

The advice worth acting on is the one that is easy to skip: if you carried effort settings over from an earlier model, run a fresh sweep rather than reusing them. The mapping between effort and quality has changed.

A million tokens, and what to do with it

The 1M context window is the default and the maximum, with no smaller variant to choose. That simplifies configuration and it does not make long context free.

Two things remain true regardless of window size. Cost scales with what you put in it, so a habit of stuffing the context because you can is a habit that shows up on the bill. And retrieval quality still matters — a large window means you can include more, not that including everything is better. A context filled with marginally relevant material is a context where the important part competes for attention.

Where the size genuinely changes what is possible: reasoning across a whole codebase rather than a curated subset, long agentic sessions that no longer need aggressive history truncation, and analysis over large document sets in a single pass. Those are real capability unlocks and they are worth designing for deliberately rather than by default.

Where it fits in a delivery team’s stack

Our practical read, after using it across a range of work:

Low or medium effort for high-volume, well-specified tasks: classification, extraction, summarisation, routine transformation. These are where the cost savings are, and where quality usually holds well below the default.

High effort, the default, for ordinary development work: writing and reviewing code, debugging, drafting technical content. Most requests belong here and the default is well chosen.

xhigh or max for the small number of tasks that justify it: difficult architectural analysis, tracing an intermittent bug through a large system, long agentic sessions with many tool calls. The reported gains on hard, vaguely specified work are the most credible part of the release — and unconstrained token spending is exactly what these levels mean.

The efficiency finding worth noting from reported customer use is that higher effort sometimes costs less overall on agentic work, because the model reaches the answer in fewer turns and fewer tool calls. Optimising for tokens per request is the wrong measurement; measure tokens per completed task.

What has not changed

Three things are worth stating plainly, because each release brings a fresh round of expectations that outrun the tool.

The model still cannot verify its own claims. More thinking produces better-reasoned output, not output that is grounded in facts the model does not have. Anything requiring current or organisation-specific information still needs retrieval, and anything consequential still needs checking.

Long context does not remove the need for good retrieval. A million tokens changes what you can include; it does not change the fact that precision in what you include improves the answer. Teams that respond to a larger window by dropping their retrieval work usually get worse results at higher cost.

Evaluation remains the thing that separates working systems from demos. A stronger model raises the ceiling on what your system can do and tells you nothing about whether a change you made helped. That is still your evaluation set’s job, and it is still the most commonly skipped part of building on these APIs.

How to evaluate it for yourself

The temptation with a new model is to try a few prompts, form an impression, and switch. That impression will be wrong in at least one direction.

The approach that works is the same as it always was. Keep a set of real inputs from your application with known-good outputs. Run them across the effort ladder and record quality, latency and token cost at each level. Pick the lowest level where quality holds for each distinct task type, rather than one setting for the whole application.

That last point is where most of the savings are. Applications typically have a small number of hard requests and a large number of easy ones, and running everything at the level the hardest request needs is the most common source of avoidable spend.

Boolean Solutions experience with model upgrades

We use these models daily and we build them into client products, and our position on new releases is deliberately unexcited: the model is rarely the constraint. Retrieval quality, prompt specificity, evaluation coverage and the surrounding architecture determine how well a system works, and a stronger model improves a well-built system more than it rescues a poorly built one.

What Opus 5 does change is that effort tuning is now a real engineering decision with measurable cost implications, and it belongs in the same conversation as caching and batching rather than being set once and forgotten. If you are building on these APIs and want help with the evaluation and cost side, talk to us, and our AI and ML services page describes how we work.

Further reading

• Introducing Claude Opus 5 — the announcement, including effort-level performance charts
• Effort — the parameter documentation and per-model recommendations
• Model migration guide — the breaking changes worth auditing before you switch
• Context windows — how the 1M window behaves in practice