Modern reasoning models let you explicitly control how much internal reasoning effort a model spends before answering, and defaulting to "maximum, always" is a common and expensive mistake. The right setting depends entirely on what the specific task actually needs, and treating it as a single global setting instead of a per-task decision leaves real latency and cost on the table.
What reasoning effort actually controls
A higher reasoning effort setting lets a model work through more intermediate steps (more chain-of-thought reasoning) before producing a final answer, which generally improves accuracy on genuinely difficult, multi-step problems. That extra reasoning takes real time and costs real tokens. It's a tradeoff, not a free quality upgrade.
Why "always maximum" is the wrong default
A simple, well-defined task (a straightforward classification, a short factual lookup, a routine formatting operation) doesn't benefit meaningfully from extended reasoning, because there's no real ambiguity or multi-step logic for the extra effort to resolve. Running every request at maximum effort adds latency and cost to the majority of requests that never needed it in the first place, for accuracy gains that only show up on the harder subset.
How to actually decide the right setting for a task
Match effort to genuine task difficulty, not to a global policy
A system handling a mix of request types, some simple and some genuinely complex, gets more value from routing each request to an appropriate effort level than from applying one setting uniformly. This is the same principle behind cost-aware model selection more broadly: match the tool to the job, not the other way around.
Use latency requirements as a hard constraint, not an afterthought
If a use case has a real user-facing latency requirement (a live chat interface, a voice interaction), that constraint should set the reasoning effort ceiling directly. A more accurate answer that arrives too slowly to be useful isn't the better outcome for that interaction.
Reserve high effort for the requests that actually need it
Multi-step reasoning tasks, complex analysis, and anything genuinely ambiguous or requiring the model to weigh multiple considerations are where higher reasoning effort earns its cost. Routine, well-defined operations are where it usually doesn't.
Validate the setting against real evaluation data, not intuition
The same discipline covered in building a real evaluation harness applies here directly: measure actual accuracy at different reasoning effort levels for your specific task, rather than assuming higher is always meaningfully better for the particular problem you have.
The practical pattern that works well
A tiered approach works well: a fast, low-effort path for the majority of routine requests, and a higher-effort path reserved for requests flagged as genuinely complex or ambiguous. It captures most of the cost and latency benefit without giving up accuracy where it matters. The same tiered pattern is useful elsewhere in production AI: don't apply the expensive option uniformly when a cheaper one handles most cases just as well.
How we approach this
We treat reasoning effort as a per-task engineering decision, tuned against real evaluation data for the specific mix of requests a system actually handles, rather than a single global setting applied uniformly regardless of whether a given request needed it.