For a while, controlling how much a model reasoned meant handing it a token allowance up front. You picked a number — sixteen thousand, say — and hoped it was enough for hard problems without being wasteful on easy ones. It was a bad interface for an obvious reason: you were guessing the difficulty of a task before seeing it, which is precisely the thing the model is better at than you are.
That mechanism is gone on current models. What replaced it is a coarser and considerably more useful dial: an effort level that sets how ambitious the model should be, with the model deciding how much thinking each particular request warrants.
What changed in 2026
- Fixed thinking budgets were removed, not deprecated. On current-generation models, passing the old token-allowance parameter is rejected outright rather than ignored. It is the most common break when migrating older code.
- Adaptive thinking became the default posture. The model varies reasoning depth per request instead of spending a fixed allowance whether the question needs it or not.
- A tier appeared between "high" and "maximum". The gap between the general-purpose setting and the expensive one was wide enough that most agentic and coding work fell awkwardly between them; the intermediate level is now where a lot of that work belongs.
- Effort started mattering more than it used to. On earlier models the setting was a modest cost adjustment. On current ones it visibly changes behaviour, which means settings carried over from an older integration are probably mistuned.
What each level is for
| Level |
Typical use |
Watch for |
| Low |
Classification, extraction, formatting, subagent leaf tasks |
Skips verification steps; poor on multi-step logic |
| Medium |
Routine generation, summarisation, straightforward code |
Occasionally under-thinks genuinely hard cases |
| High |
General default; most production work |
Fine for nearly everything; the sensible starting point |
| Extra high |
Complex coding, long-horizon agent runs |
Noticeably more expensive; worth it on hard tasks |
| Maximum |
Correctness matters more than cost |
Diminishing returns outside genuinely difficult problems |
The mistake most teams make on first contact is treating this as purely a cost slider and pinning it at maximum for anything that feels important. That reasoning is backwards. Effort should track task difficulty, not task importance. A high-stakes classification is still a classification, and running it at maximum buys nothing except a larger bill.
Behaviour changes, not just spend
The part that surprises people: lowering effort does not simply produce the same output more cheaply. It produces a different working style.
At low effort a model makes fewer tool calls and consolidates them — batching what it needs rather than exploring incrementally. It writes less preamble, confirms more tersely, and is likelier to act on a reasonable assumption than to verify it first. For a mechanical subtask that is exactly right; the verification was overhead. For an ambiguous task it is exactly wrong, because the assumption it skipped checking is the thing that was going to go sideways.
At high effort the pattern inverts. More exploration, more explicit checking, more willingness to backtrack when something does not fit. On a hard problem that is the whole value. On a simple one it is an expensive way to arrive at the same answer.
This is why effort and task routing belong together. Classifying incoming work by difficulty and assigning effort accordingly beats any single global setting, and it is usually a smaller engineering job than it sounds — a cheap model can do the triage.
Effort, budgets, and cost
Effort and agent token budgets are complementary controls that people frequently confuse.
Effort governs depth per step — how much the model thinks before each action. A budget governs how many steps the loop can afford in total. Turning effort down reduces the cost of each move while leaving the agent free to make all the moves the task requires. Cutting the budget reduces how much of the task gets done.
The practical implication: when an agent is too expensive, reach for effort first. It preserves scope and coverage. Cutting the budget should come second, because it trades away completeness — and a truncated audit is often worth less than no audit, since it looks finished.
For a broader treatment of the spend side, AI inference cost optimization covers the levers beyond this one.
Common mistakes
- Carrying over a fixed thinking budget. It is rejected on current models, and the error message is not always obvious about why.
- Maximum everywhere. Pays a premium across all traffic for a benefit concentrated in a small slice of it.
- Low effort on ambiguous work. The skipped verification is precisely what an ambiguous task needed.
- Disabling thinking entirely to save money. On some models this introduces its own failure modes and is worse than simply lowering effort. Turning it down beats turning it off.
- One global setting. Different task classes want different depths; a single value is a compromise that fits none of them well.
- Not re-tuning after a model change. Effort behaviour differs between model generations. A setting tuned last year is a guess this year.
FAQ
Does higher effort always produce better answers?
No. It produces more thorough reasoning, which helps on problems where thoroughness is the constraint. On a task that was never hard, extra reasoning adds cost and latency and occasionally over-complicates a simple answer.
How much does effort actually affect cost?
Enough to matter — it is one of the larger single levers available — but the exact multiple depends on the model and the task's natural reasoning depth. Measure it on your own traffic rather than trusting a rule of thumb; a task that never needed much thinking will barely differ between settings.
Should subagents run at lower effort than the orchestrator?
Usually yes. Leaf tasks tend to be well-specified reading and filtering work, which is where low effort performs well. Synthesis at the root is where depth earns its cost. Subagent architecture covers that split in more detail.
Can I see how much thinking happened?
Usage reporting tells you the token cost. Whether the reasoning itself is visible depends on the model and its display setting — and on current models the default is often to omit it, which surprises people building a UI that streams reasoning to users.
Where to go next
For pacing whole agent runs rather than individual steps, read agent token budgets. For keeping spend visible once you are tuning it, agent cost attribution, and for planning around the model changes that reset all of this, AI model deprecation planning.