Reasoning Models and Overthinking

Recent language models are increasingly difficult to compare by headline benchmark scores alone. Newer models typically solve more benchmark tasks while potentially being less useful in demanding interactive work, as they may spend much more time in inference exploring alternatives, revisit conclusions already supported by the evidence, make unnecessary tool calls, or delay acting after the problem is effectively solved. This reflects a broader trend in model development in that a growing fraction of capability now comes from post-training models to search, verify, retry, use tools, and recover from mistakes at inference time. This has produced substantial gains in mathematics, coding, and long-horizon agent tasks, but it has also exposed a less mature capability in deciding when further computation is warranted.

We can frame the problem as a distinction between capability, search, and control. A model may be capable of finding a solution, may have learned an effective search policy, and may still be poor at deciding when the available evidence is sufficient to answer or act. Our previous work on epistemic control and intent alignment suggests that these dimensions can move independently.^{1 2} Recent external work on LLM overthinking reaches a similar conclusion from the structure and efficiency of reasoning trajectories.^{3 4}

The central issue is that recent model development has made search much stronger faster than it has made stopping stronger. Models are increasingly trained to persist, verify, retry, use tools, recover from failures, and continue until some externally checkable objective is satisfied. Those capabilities produce real gains, especially on mathematics, coding, and long-horizon agent tasks. They also make it easy to confuse improved task completion with improved local judgment.

Pretraining, post-training, and inference-time search

A model can improve for several different reasons, and they should not be treated as equivalent. Pretraining changes the underlying representations and capabilities of the base model. Post-training changes how those capabilities are expressed: which strategies the model prefers, how it uses tools, how it follows instructions, and how aggressively it searches or verifies. Test-time compute then determines how much inference the trained policy is allowed to spend on a particular problem. A simplified RL objective is:

$$ \max_\theta E_{\tau \sim \pi_\theta}[R(\tau)] $$

where $\tau$ is a reasoning or agent trajectory and $R(\tau)$ is the reward assigned to its outcome.

This becomes especially powerful when the outcome is easy to verify. Code either passes tests, a mathematical answer verifies, or an environment reaches the requested state. Large amounts of post-training can therefore optimize the model against final outcomes without requiring humans to judge every intermediate decision. The resulting improvement may come from better immediate reasoning, better recovery from an initially wrong path, more persistent search, more effective tool use, or some combination of these. A benchmark that only records eventual success does not distinguish them.

We find that GLM-5.2 and GLM-5.3 illustrate this particularly well. Z.ai states that GLM-5.3 uses the same pretrained base model as GLM-5.2 and attributes the improvement to scaled post-training across more environments and longer-horizon tasks.³ Large gains between those models therefore demonstrate a stronger task-solving policy, but they do not imply an equally large improvement in every local reasoning decision. So a model can become much better at eventually recovering without becoming proportionally better at immediately identifying the right abstraction.

Outcome training favors persistence

Suppose a model identifies the correct diagnosis on 75% of tasks after its first serious attempt. If further checking, branching, and retries raise eventual success to 82%, reinforcement learning has a clear reason to preserve those extra behaviors.

The resulting policy may resemble:

$$ \text{diagnose} \rightarrow \text{verify} \rightarrow \text{branch} \rightarrow \text{retry} \rightarrow \text{verify again} \rightarrow \text{finish} $$

If both a 5,000-token successful trajectory and a 50,000-token successful trajectory receive approximately the same reward, there is little pressure to learn which of those intermediate steps were actually necessary. Persistence is easier to reward than restraint. We don’t want to imply that reinforcement learning inherently makes models verbose or inefficient. Better post-training can improve reasoning quality without increasing chain length. Ballon, Algaba, and Ginis found that o3-mini improved over o1-mini without requiring longer reasoning traces, while simply increasing the inference-time reasoning budget caused substantially greater token use for relatively modest gains.⁴ The important distinction is between improving the policy and allowing the policy to search longer. Recent models increasingly expose this as a separate axis. The model may be strong, but the chosen reasoning mode or agent harness can still allocate compute badly.

Overthinking is misallocated computation

Some problems genuinely require a large search budget. The useful question is whether another reasoning step is still expected to improve the result.

A rough stopping condition is:

$$ E[\Delta Q] > C_{\text{compute}} + C_{\text{latency}} + C_{\text{error}} $$

where $E[\Delta Q]$ is the expected improvement from another reasoning step. Overthinking begins when the left side has fallen below the right side but the model continues anyway.

DeepMind’s recent structural analysis of Qwen3 and DeepSeek-derived reasoning models identifies two recurring patterns: Explorer, where the model repeatedly opens new reasoning branches, and Late Landing, where the answer has effectively been reached but the model continues checking and reconsidering before terminating.⁵ These are better descriptions of the phenomenon than raw chain length because they identify the structure of wasted search.

Wu et al. independently find an inverted-U relationship between reasoning length and accuracy: additional reasoning helps initially, then becomes neutral, and eventually can reduce performance. Their results also show that the optimal amount of reasoning depends on both task difficulty and model capability.⁶ The implication is that for the same problem, a more capable model should often need less search, not more.

$$ \text{better reasoning} \neq \text{longer reasoning} $$

A model that quickly identifies the governing structure and commits may be doing more useful reasoning per token than one that produces a much longer trace.

Extra reasoning can reduce quality

Once a model has enough correct information to solve the task, continued inference introduces new failure opportunities. Every additional hypothesis can contain an error. Every verification can reopen a settled premise. Every unnecessary tool call can enlarge the context with more material that subsequent inference must interpret. The system can therefore move from a correct compact state into a larger and less stable one.

Consider a compiler problem where the model has correctly established:

$$ S = { \text{target ABI}, \text{object format}, \text{relocation semantics}, \text{linker behavior} } $$

If those constraints determine the answer, good reasoning should largely move forward:

$$ S_0 \rightarrow S_1 \rightarrow S_2 \rightarrow S_3 \rightarrow \text{fix} $$

A poorly calibrated model may instead produce:

$$ S_0 \rightarrow S_1 \rightarrow S_2 \rightarrow S_1' \rightarrow S_3 \rightarrow S_2' \rightarrow S_4 $$

The model has not discovered materially new evidence; it has reopened established conclusions because another hypothesis is merely conceivable. This is hypothesis churn. Tool-using systems amplify the problem. An unnecessary branch produces a tool call, the tool call adds context, and that context creates more opportunities for additional branches:

$$ \text{weak hypothesis} \rightarrow \text{tool call} \rightarrow \text{more context} \rightarrow \text{more apparent uncertainty} \rightarrow \text{further search} $$

The resulting trajectory can look sophisticated while making little net progress. This also explains why longer reasoning can occasionally make a correct answer worse. Intrinsic self-correction without new external evidence has long been known to sometimes degrade answers rather than improve them.⁷ Recent work on reasoning length gives a more general account: additional steps accumulate opportunities for error and distraction once the useful part of the chain is already complete.⁶

Certain tasks expose problems more clearly

Deeper dataflow problems such as cross-compilation failures may involve a large repository, several toolchains, multiple build systems, and many misleading symptoms, but the valid solution space can collapse quickly once a few facts are established:

$$ \text{target} \rightarrow \text{ABI} \rightarrow \text{object format} \rightarrow \text{relocation semantics} \rightarrow \text{linker behavior} $$

Once the decisive invariant is known, much of the remaining search space becomes impossible rather than unlikely. Good reasoning therefore depends not only on discovering constraints but on preserving them as constraints. We found heavily search-oriented models sometimes worse despite stronger benchmark results. They may be excellent at generating and testing alternatives but comparatively weak at treating an established technical fact as closed unless contradictory evidence appears. For expert work, the key is a stable transition from uncertainty to constraint to action. A model that reaches the right compiler diagnosis in 4,000 tokens and preserves it may be substantially more useful than one that reaches the same diagnosis after 3,000 tokens, then spends another 25,000 tokens exploring weaker alternatives before returning to the original conclusion.

Eventual success can hide weaker local judgment

A simple example shows why benchmark rankings can diverge from interactive experience. Suppose Model A identifies the correct diagnosis immediately 90% of the time. Model B does so 86% of the time, but its larger search policy recovers half of the remaining failures:

$$ 86% + 0.5(14%) = 93% $$

A completion benchmark ranks Model B higher. An experienced engineer may still prefer Model A because it reaches the useful state earlier, creates less irrelevant context, requires fewer interventions, and is less likely to wander after finding the answer. Both evaluations are valid but measure different properties.

For long-horizon coding benchmarks, a model that is better at recovering from mistakes over hundreds of turns can improve dramatically on repository-level tasks without being proportionally better at each individual technical decision inside the trajectory. A completion benchmark measures:

$$ \text{Can the agent eventually finish?} $$

while the interactive user often cares more about:

$$ \text{How quickly does it reach the right abstraction, and does it stay there?} $$

Why this has become common recently

The current incentive structure makes aggressive search attractive as verifiable RL provides scalable feedback on final outcomes. It is straightforward to reward a coding agent because its tests eventually pass. It is much harder to determine that the agent had already solved the problem fifteen minutes earlier and that everything afterward was redundant. Benchmarks often share that asymmetry, and it can lead to counterintuitive rankings. If one model solves a repository task in ten minutes and another solves it in forty, both may receive a pass. If the slower model’s additional search recovers two more tasks out of one hundred, it can rank higher.

The optimization target is therefore often close to:

$$ \max \text{eventual success} $$

while the user may care more about:

$$ \max \frac{ \text{correct useful work} }{ \text{latency} \times \text{compute} \times \text{supervision} } $$

Test-time compute is also attractive because it offers another scaling axis. Once a strong base model exists, additional search, tool use, verification, retries, and agent loops can extract more benchmark performance without requiring a proportionally larger pretraining run. While the gains are real, the problem is that benchmark and training objectives often value recovery more clearly than stopping quality, so the models learn persistence faster than they learn restraint.

A token penalty may also be insufficient

The obvious corrective could be thought of as penalizing long reasoning, but this merely shifts the failure toward premature termination. Some problems genuinely require extensive search. A model should not stop early because tokens are expensive if another few thousand tokens have a high probability of finding the decisive fact.

The real objective is therefore something closer to:

$$ \max \left( \text{task utility} - \lambda C_{\text{inference}} \right) $$

with $\lambda$ effectively modulated by task difficulty, uncertainty, latency requirements, and the value of being correct. This is an adaptive-compute problem. The ideal system should allocate little inference to problems it already understands, more to genuinely difficult problems, and extensive search only when uncertainty remains both material and reducible.

OpenAI’s recent framing of GPT-5.6 is notable in this respect because it treats task success and inference efficiency as joint objectives, reporting improvements not only in benchmark quality but also in tokens, completion time, and cost.⁸ Whatever the exact proprietary training mechanism, this is a more useful product objective than maximizing score at an unconstrained reasoning budget.

Thinking mode is not a quality switch

Our prior evaluations also showed that additional reasoning is highly model-dependent.^{1 2} Some models benefit substantially when thinking is enabled, while others become slower with little or negative quality change. This should change how we compare models. A model name alone is not always the relevant unit. The actual operating point may include the model, reasoning level, context-management strategy, tool harness, retry policy, and termination behavior. The same model can therefore occupy several different places on the capability-efficiency frontier.

This is also why apparently weaker models can feel surprisingly competitive. If a smaller model already has enough underlying capability for the workload and uses a direct policy, it may behave like:

$$ \text{observe} \rightarrow \text{infer} \rightarrow \text{act} $$

while a stronger reasoning model behaves like:

$$ \text{observe} \rightarrow \text{infer} \rightarrow \text{branch} \rightarrow \text{verify} \rightarrow \text{reconsider} \rightarrow \text{tool} \rightarrow \text{branch again} \rightarrow \text{act} $$

If both ultimately solve the same problem, the larger model’s additional search may contribute little. Move to a task beyond the smaller model’s immediate capability and the larger model’s search can become valuable again. The ranking is therefore workload-dependent.

Token use is noisy and often poorly calibrated

Inference usage also varies substantially between trajectories. Microsoft Research found that repeated runs of the same model on the same SWE-bench task could differ by as much as 30× in token consumption, while greater token use did not reliably correspond to greater accuracy.⁹ This weakens the interpretation that a long run necessarily reflects a legitimately hard problem. Sometimes the model correctly allocates more effort to a difficult task. Sometimes it enters a bad trajectory and keeps feeding that trajectory more computation.

A model that typically solves a task in 10,000 tokens but occasionally falls into a 150,000-token loop behaves differently from one that consistently uses 15,000. Median token usage alone hides this distinction, as does average benchmark score, requiring us to look at tail behavior. For interactive use, p90 or p95 latency and token consumption can matter much more than a small difference in mean success rate.

What public benchmarks can tell us

Public benchmarks are still helpful if we stop reading them as one-dimensional rankings. For coding agents, the most informative presentation is a capability-efficiency frontier. Artificial Analysis, for example, publishes pass@1 together with token usage, execution time, cost, and configuration details for coding-agent evaluations.¹⁰ Where the desirable region is high success with low token use and low wall-clock time.

If one system is both less accurate and more expensive than another, it is dominated. More interesting decisions involve systems near the Pareto frontier. For example:

$$ A = 76% \text{ at } 20k \text{ tokens} $$

$$ B = 78% \text{ at } 55k \text{ tokens} $$

B is better on raw benchmark score. It is however not automatically better for interactive engineering. The additional success may be worthwhile for autonomous overnight work, where human attention is expensive and eventual completion dominates. For interactive debugging, the extra latency and trajectory instability may be more costly than the two-point gain is valuable.

Pass@1 is generally more useful than pass@k when evaluating this behavior because repeated attempts can hide weak first-trajectory judgment. Wall-clock time is important because token-efficient models can still waste time through excessive tool calls or slow agent loops. Cost is useful but partly reflects provider pricing rather than model efficiency itself.

Benchmark shortcomings

The public metrics still fail to capture two properties that matter heavily in what we consider to be expert work. The first is time to correct commitment: how long the model takes to reach and act on the correct interpretation. Suppose Model A reaches the right diagnosis after three minutes and applies the fix after five. Model B reaches the same diagnosis after two minutes but explores alternatives for another eighteen before applying the same fix. Model C reaches the right diagnosis, continues reasoning, and eventually abandons it for a wrong one. A binary benchmark simply records:

$$ A = \text{pass}, \qquad B = \text{pass}, \qquad C = \text{fail} $$

For interactive work, the ranking is closer to:

$$ A \gg B \gg C $$

and Model B’s weakness is largely invisible. The second missing property is reasoning damage: the probability that continued inference degrades an already sufficient reasoning state. If $S^*$ contains enough information to solve the task, the relevant quantity is:

$$ P( Q_{\text{final}} < Q(S^*) \mid \text{continued reasoning} ) $$

A strong stopping policy should keep this probability low. These metrics are difficult to measure because they require inspecting intermediate trajectories rather than only final outcomes. They are nevertheless closer to what expert users actually experience.

A better practical model of quality

For technical work, model quality is better treated as multidimensional:

$$ Q_{\text{practical}} = f( \text{capability}, \text{calibration}, \text{reasoning efficiency}, \text{boundary preservation}, \text{state stability}, \text{tool efficiency}, \text{latency}, \text{reliability} ) $$

Capability determines whether the model can solve the problem at all. Calibration determines whether it correctly estimates uncertainty and difficulty. Reasoning efficiency determines how much useful progress it extracts from additional inference. Boundary preservation determines whether it respects the limits of evidence and intent. State stability determines whether established constraints remain established until new evidence contradicts them.

These dimensions interact, but they do not necessarily improve together. A model can therefore have a higher aggregate benchmark score while being worse for a particular engineering workflow because the benchmark heavily weights eventual completion and weakly weights the dimensions that dominate interactive productivity. The practical selection rule is to prefer models near the Pareto frontier of success, time, and inference, and treat small score gains bought with very large increases in search cautiously.

Conclusion

Recent reasoning models have become substantially better at inference-time search. They verify more, recover from mistakes more effectively, use tools more persistently, and complete longer trajectories. A corresponding control problem has received insufficient attention. A model must not only know how to continue reasoning, but it must estimate whether continuing is still useful.

Once the decisive structure is known, additional reasoning can become redundant verification, hypothesis churn, context growth, or a mechanism for introducing new errors. In systems work, where a small number of technical constraints often determine the valid solution space, this failure becomes especially visible.

The relevant target is therefore adaptive inference, spend computation while it reduces material uncertainty, preserve established constraints, and stop when another step is unlikely to improve the decision. For model evaluation, this means reading benchmark scores together with the equivalent of e.g. pass@1, token use, wall-clock time, tail behavior, and agent configuration. It also means recognizing that current leaderboards still under-measure time to correct commitment and reasoning damage.

The frontier is increasingly about whether models can govern the amount of reasoning they perform.