Bottom line up front
Reasoning-effort settings let you choose how much deliberation a model does before answering. They move cost and latency alongside depth, which makes them a budget control rather than a quality dial: the right setting is the lowest one that clears your quality bar on the task in front of you. Several 2026 model releases support multiple effort levels on the same weights, and adaptive routing — where the model adjusts effort based on how hard a prompt looks — is a direction analysts expect to continue. Either way, the setting is a measured condition, not a default to inherit.
What an effort setting actually changes
A reasoning-effort setting controls how much intermediate deliberation the model produces before its final answer. More deliberation generally means more output tokens, more latency, and a higher bill — and sometimes better results on tasks where the extra thinking helps. The key property is that all three move together, which is why treating the setting as a quality dial is the wrong frame.
Several of the models documented in this series expose multiple effort levels on the same weights: a 309-billion-parameter mobile-family model with a low and a high setting, a 550-billion-parameter reasoning model with a configurable inference-time reasoning budget, a 600-billion-parameter coding model with low, medium, and high, and a frontier model with low through max. The ranges differ, which means the level names are not comparable across models — a 'high' on one is not necessarily a 'high' on another.
- Record which effort levels a specific model exposes, and that the names are not comparable across models.
- Measure output tokens at each level, not just input, when estimating cost.
- Treat the level as part of your recorded conditions, not a fixed default.
The right level is the cheapest one that clears your bar
The practical rule is to find your quality bar first and then use the lowest effort setting that clears it. That is a measurement, not a lookup: run the same task at two or three levels, record the outcomes and the failures, and pick the lowest level whose failure mode you can accept. Running everything at maximum effort is a way of paying for depth you may not be using.
There is a second reason to prefer the lowest sufficient level. Where a free gateway endpoint is involved, the effort setting is often the difference between a usable trial and an exhausted rate limit, because the cost that the operator absorbs scales with the deliberation you request.
- Define the quality bar for the task before testing effort levels.
- Run the same task at two or three levels and record failures at each.
- Choose the lowest level whose failure mode is acceptable.
Adaptive effort is coming, and it moves the problem
Analysts describe adaptive reasoning as a direction for 2026: models that adjust their effort based on how difficult a prompt appears, reserving deep deliberation for problems that need it rather than spending tokens on a simple request. For a caller, that is attractive because it removes a dial you would otherwise have to tune.
It also removes a dial you were measuring. If a model adapts its effort automatically, your recorded conditions become incomplete unless you can observe what it did — which means the useful things to measure change from 'which level did I request' to 'how many tokens did it spend and did the effort match the task'. Where the platform exposes that, record it. Where it does not, the honest position is that the condition is unknown.
- Record whether the model adapts effort automatically or takes a fixed setting.
- Where adaptation is automatic, record tokens spent per request alongside the outcome.
- Flag requests where the observed effort did not match the task's difficulty.
Effort is a per-request decision, not a per-model one
The most useful framing is that effort belongs to the request, not the model choice. A classification or extraction step does not need deep deliberation; a planning or debugging step might. Choosing one model at one effort level for an entire workflow is a way of paying a single average for a distribution of very different tasks.
That also means the model comparison and the effort comparison are separate experiments, and conflating them produces a result you cannot interpret. Comparing two models at one effort level tells you about that configuration. Comparing one model at two levels tells you about the model's cost curve. Run them separately and keep the records apart.