The Thinking Lever: How Effort Becomes a Design Choice
Three key takeaways
- Thinking is not a feature you toggle on or off. It is a capability the model uses when it decides the problem is worth the tokens. Treating it as a switch removes a tool you actually want available.
- Higher effort settings keep paying off on hard tasks, but the curve flattens fast. Most production use cases live happily at high or extra high, not max.
- A small model on max effort rarely beats a larger model on low effort. Pick the model first, then tune the lever.
Alexander Bricken from Anthropic's Applied AI research team ran a small demonstration during his Code with Claude London 2026 talk that did more to explain reasoning models than any benchmark chart could. He took one prompt, a simulation of cars on a one-way street with a traffic light, and ran it three times on Opus 4.7 at low, high, and max effort.
Low effort took fifty seconds and around 4,600 output tokens. The cars moved through. The light cycled. The simulation worked. It also placed the traffic light in the middle of the road, which makes no physical sense.
High effort took roughly twice as long and twice as many tokens. Now there were different vehicle types, including lorries for the British crowd. The traffic light was overhanging the road instead of sitting in it. Drivers reacted to nearby cars rather than driving as if they were alone.
Max effort took about ten times the tokens and ten times the time. The simulation gained a skyscape in the background, physically plausible traffic light placement, and the most natural vehicle behavior of the three. Bricken's verdict was straightforward. Each step up produced a better artifact. The size of each step shrank as effort increased.
That demonstration is what the talk hung on. Compute at inference time, what Anthropic calls test time compute, is a lever practitioners can pull. The lever has a real shape. Pulling it harder is not always wise. The interesting question is when to pull, how hard, and on which model.
Test time compute is the new training run
The talk opened with a familiar curve. Train a bigger model, get better performance. Anthropic showed the standard graph: Haiku, Sonnet, Opus, climbing toward roughly 80 percent on an internal agentic coding benchmark as parameters scale up.
Then they showed the same chart with a different axis. Instead of model size, the x-axis was tokens spent at inference time, plotted logarithmically. The curve looks similar. More tokens, more thinking, better answers.
The two graphs share their ceiling. Max performance from a big model and max performance from a small model thinking longer end up in similar territory on this particular benchmark. That is not always true, and it is not the lesson Anthropic wants you to take away. But it is the starting point for everything else in the talk.
Bricken cited the METR benchmark, which tracks the length of human-equivalent work a model can complete autonomously. The latest model in the lineup, called Mithos in the talk, hits about 16 hours of human work at 50 percent accuracy. That number doubles roughly every seven months according to METR's tracking. Within a few generations, we are talking days. After that, weeks.
The point is that compute, both kinds, is the dominant variable. Spend it during training. Spend it during inference. Either way, the model gets more capable per unit of work.
For practitioners, the operational consequence is that token budget is now a design parameter on the same level as model selection. Two years ago, you picked a model and lived with what it produced. Today you pick a model and you pick how hard it works on a given turn. Those are independent dials, and pretending they are not, by always running at default settings, leaves a meaningful slice of performance on the table.
The trickier consequence is that the cheapest call is rarely the cheapest outcome. A low-effort call that produces a wrong answer costs you the call plus the cost of fixing what it broke. A higher-effort call that gets there in one pass can be the dominant economic choice even when the per-call token bill looks higher. The teams that internalize this stop optimizing for tokens per response and start optimizing for tokens per resolved task.
Three places to spend tokens
Test time compute is not one thing. Bricken broke it into three categories, and the distinction matters because the right answer depends on which one you mean.
The first is thinking space. A scratch pad where Claude works through what was asked, reviews what it has, and plans next steps. Pure deliberation, no external action.
The second is tool calling. The model decides to read a file, call an MCP server, run a search, interact with Salesforce, write to disk. Anything that touches the world outside the prompt.
The third is text output. The actual response, whether that is a summary, a clarifying question, or a finished piece of work.
All three cost tokens. All three take time. And historically, the way users controlled this was crude. You turned thinking on or off. You set a max token cap. You crossed your fingers.
The interleaved thinking moment
Bricken walked through how Claude's reasoning has shifted over time. The first generation worked like a particular kind of human stereotype. You ask a question, the model thinks for a long block, then it acts on what it decided, then it returns.
That is not how good knowledge workers operate. They do something, see what happened, think about it, do the next thing. Anthropic called the next step interleaved thinking. The model gets a thinking step after every tool call. It can reflect on what just came back before committing to its next action.
Then came adaptive thinking, which is where the current models live. Now the model decides when to think, when to call a tool, when to output text, and in what order. It can think three times in a row if the problem calls for it. It can skip thinking entirely if the question is trivial.
This is the moment that reframes the whole topic. Bricken's line was direct. "Adaptive thinking isn't a model router. We're not classifying the request that comes through the door. Instead, it's actually telling Claude, hey, you have this thinking tool. You must think at one point in time, whereas now Claude doesn't have to think at all if it doesn't need to."
Thinking becomes a tool the model picks up when useful. Like search. Like a code interpreter. Anthropic's benchmarks show adaptive thinking is Pareto efficient compared to interleaved thinking. Same intelligence ceiling, fewer wasted tokens.
There is a secondary effect worth flagging. The shift from interleaved to adaptive thinking changes the shape of the trace you get back from the model. With interleaved thinking, you could expect a thinking block after every tool call, which made the trace predictable and easy to instrument. With adaptive thinking, the model might call three tools in a row without thinking, then think for a long block, then output text. Traces become more variable, which means observability tooling that was built around the older pattern needs adjustment. Teams running agents at scale tend to discover this when their dashboards start showing wide variance in thinking token counts and they assume something is wrong. Usually nothing is wrong. The model is just allocating differently per task.
Turning off thinking turns off a capability
Here is the part that should change how people configure their deployments.
When you disable extended thinking, you are not telling Claude to think less. You are removing a capability. The model can no longer use the scratch pad even when it would help. You have not adjusted effort. You have amputated a tool.
Bricken used a tools analogy that makes the point cleanly. We do not tell Claude to never search the web. We do not tell it to always search the web. We give it a search tool and trust it to reason about when to use it. Thinking should work the same way. Hand the model the capability. Let it decide.
The same logic applies to working with human colleagues. You do not tell a teammate to skip their inner monologue and just answer. You give them the problem and the constraints. They figure out how much to think.
This sounds obvious. It is also exactly the opposite of how most people configure their Claude deployments. The instinct to turn thinking off for cost reasons, or to force it on for "better answers," both miss the point. The model needs the capability available. The lever you actually want is effort, which controls how much budget the model has when it does choose to think.
The effort curve has a shape
Bricken then dug into the practical question. Which effort level should you start with?
Max effort, the highest setting, delivers gains on the hardest tasks. The curve also flattens out. The traffic light demo showed max using disproportionately more tokens than extra high for only a marginal bump in quality. Anthropic's advice is to not start here unless you know the use case requires it.
Extra high is the default Anthropic ships on Claude Code and Claude.ai. Their internal view is that this setting hits the best trade-off between intelligence, latency, and token cost across general use.
High remains a strong choice when any intelligence is needed but you want lower latency. Medium and low exist for tasks where the intelligence requirement is minimal. Classification. Summarization. Data extraction. Things where speed beats sophistication.
There was one delightful counterexample. Claude Plays Pokemon, where Claude attempts to beat the Elite Four in Pokemon Red, runs differently at different effort levels. On low effort, Claude found creative shortcuts. It used repels to avoid wild encounters. It used escape routes out of caves. It ran away from battles in the grass. The constrained thinking budget pushed it into an unusual attractor state, and the result was a faster path through the game.
Lower effort sometimes produces more interesting behavior because the model cannot afford to plan exhaustively. It has to commit. Worth keeping in mind when designing agents for environments where speed and decisiveness matter more than careful deliberation.
A practical implication is that effort is the right knob to tune for cost, not the thinking switch. If you want Claude to spend fewer tokens on a class of tasks, dial effort down. The model can still reach for the scratch pad when a particular task in that class actually needs it. You preserve the capability and reduce the average spend. That outcome is genuinely different from killing the scratch pad entirely.
Big model, low effort versus small model, max effort
The other lever question is model size. If you have a small budget, do you pick a tiny model and crank its effort, or a big model and starve its thinking?
Bricken showed the same traffic simulation prompt run on Haiku 4.5 at the same token budget as Opus low effort. Same tokens. Half the time. Visibly worse output. He described the result with admirable honesty. "I don't even know if those are cars."
The conclusion Anthropic draws is that if the task needs intelligence at all, you are usually better off with the larger model, even at low effort. Small models earn their keep on tasks where the outcome is so simple that scale and reasoning capacity are not the binding constraints. Classification of well-defined categories. Extraction of structured data from clean text. Anything where the heavy lifting is throughput, not intelligence.
This is a useful rule of thumb when you cannot run a full evaluation matrix. Start with the bigger model on a lower effort setting. Move to a smaller model only when you have evidence that the task does not need the headroom.
The trap teams fall into is reasoning about cost in isolation. Haiku looks cheaper on the price sheet, so it must be cheaper in production. That math only holds when the smaller model can actually do the job. When it cannot, you pay for Haiku's attempt, then you pay for Opus to clean up, then you pay for a human to verify that the cleanup worked. The intuition that big-model-low-effort beats small-model-high-effort is not a quirky preference. It reflects how the curves actually cross when you measure outcome quality, not just raw token spend.
The exception is volume. If you have a task running at very high volume where each individual call genuinely does not need much intelligence, like tagging incoming support tickets into five buckets, then small models earn their place. The right setup there is to use the small model as a first pass, with an escalation path to the larger model when confidence is low or the task does not fit a clean bucket. Two models in series often beats one model that has been pushed past its comfort zone.
What to actually do
Bricken closed with a short list that distills the talk into operating principles.
Enable Claude to reason. Give it the scratch pad. Do not amputate the thinking tool just because tokens look cheaper without it.
Control effort, not capability. Use the effort dial to manage cost. Do not confuse turning thinking off with making the model cheaper or faster in a useful sense.
Evaluate at multiple effort levels. The right setting depends on your task. Build a small set of hard, representative problems. Run them at low, high, and extra high. Look at where the curve bends.
When in doubt, use extra high. It is the default Anthropic ships, and it is a defensible starting point for almost any production use case.
Pick model size before effort. If you need intelligence, get the bigger model first. Tune the lever second.
The lever points forward
The shape of where this is going is implied throughout the talk. Today you set effort. Tomorrow you set bars and budgets. You tell Claude, here is a long-horizon task, here is what I am willing to spend, here is when I need it done, and Claude figures out how to allocate compute across the work. The model becomes the budget owner, with you as the constraint setter.
That changes the role of the operator. The skill is no longer choosing effort per call. The skill is articulating constraints clearly enough that the model can plan against them. Less micromanagement. More delegation.
For now, the lever is in your hand. The thing worth doing today is treating it that way. Stop disabling capabilities. Stop reaching for max as a default. Run the eval. Pick the model. Set the effort. Let the model decide when to think.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: The thinking lever at Code with Claude London 2026. https://youtu.be/T7KqH7kYnE4