Split View: 더 생각한다고 더 맞는 것은 아니다: 테스트타임 컴퓨트와 과잉사고

More Thinking Is Not More Accuracy: Test-Time Compute and the Overthinking Cliff

• Introduction — the default of "just burn more reasoning tokens"
• What the paper actually reports
• Why more thinking abandons a correct answer
• What to change — difficulty-aware budgets
• Closing
• References

Introduction — the default of "just burn more reasoning tokens"

For the past year or two, the easiest lever for improving reasoning models has been to make them think longer. Longer chains of thought, bigger reasoning-token budgets, more rounds of reconsideration. Benchmark scores went up, and "scale test-time compute" quietly became a default that is hard to argue against.

In April 2026, Shu Zhou, Rui Ling, Junan Chen, Xin Wang, Tao Fan, and Hao Wang aim straight at that default in "When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling". Their point is simple but uncomfortable: existing research has implicitly assumed that longer thinking always yields better results, and that assumption has largely gone unexamined.

This piece works from the paper abstract to trace where the "more tokens, more accuracy" reflex breaks down, and what that should change in practice. The abstract only supports so much, so I carry over the direction the authors report and leave the rest open.

What the paper actually reports

The authors say they systematically studied how the marginal utility of additional reasoning tokens changes as the compute budget grows. The abstract lands on three conclusions.

First, marginal returns diminish sharply at higher budgets. This is ordinary diminishing returns, but the authors describe the drop as "substantial". Doubling the tokens buys back not double the accuracy but only a sliver of it.

Second, and this is the heart of the paper, models exhibit "overthinking". In the authors words, extended reasoning is "associated with abandoning previously correct answers". So the return does not merely converge to zero; over some range it goes negative. More thinking makes the model switch off a right answer onto a wrong one.

Third, the optimal thinking length varies with problem difficulty, which is why the authors call uniform compute allocation suboptimal. They add that their cost-aware evaluation framework shows that stopping at a moderate budget can cut computation significantly while keeping accuracy comparable.

It is worth separating out what is genuinely new here. Diminishing returns are old news; scaling laws have said as much for years. What makes this paper uncomfortable is the stronger claim that the curve does not merely flatten but bends downward over some range. The break in the implicit assumption of monotonic improvement is the part of the abstract most worth dwelling on.

To be honest about the limits: the abstract does not name which models were tested, which benchmarks were used, or the exact size of the effect. Read the sentences above as directions the authors report, and check the full paper for the numbers.

Why more thinking abandons a correct answer

The abstract reports the phenomenon without committing to a mechanism. From here on this is my reading, so take it as that.

The most plausible picture is this. As the chain of thought lengthens, the model re-examines its own intermediate results longer and more often. That self-correction is a gift on hard problems. But on an easy problem where the model already reached the right answer, endlessly asking "is that really right?" injects doubt into a perfectly good answer. A weakly grounded second guess pushes out a strongly grounded first judgment.

That is why "overthinking" is a well-chosen name; it is a failure mode humans know well. You pick the right answer on a test, have time to spare, keep staring at it, and finally change it to the wrong one. The authors reported "abandoning correct answers" looks like the machine version of that human mistake.

One thing deserves to be stated plainly. The abstract says "associated with", not "causes". What the authors report is a correlation, and it should not be read as a proven causal mechanism. The picture I sketched above is only a hypothesis meant to explain that correlation.

There is an important implication. If the loss were only diminishing returns, the worst case would still be "you paid more and broke even". But if overthinking is real, more compute can be actively harmful, not just wasteful. The safe-looking default of "leave the budget generous, it cannot hurt" turns out not to be safe.

What to change — difficulty-aware budgets

The practical guidance that follows from the paper is not "more" but "the right amount, and knowing when to stop".

• Drop the uniform budget: giving every request the same token ceiling is, by the authors observation, too much for easy problems and too little for hard ones. The budget should attach to the problem, not to the pipeline.
• Estimate difficulty first: a short upfront judgment of how hard a problem is, then a budget allocated to match, is the natural next step. This is exactly where the recent "adaptive reasoning effort" line of work meets the paper.
• Design a stopping rule: turn the paper stop-at-a-moderate-budget into an actual stop condition. Early exit when the answer converges quickly; a watchdog that intervenes once answers start oscillating between iterations.
• Look at cost, not accuracy alone: the point of a cost-aware evaluation is that the accuracy curve alone always seems to favor burning more, but the moment you put cost on the same axis the optimum slides far to the left.

These guidelines are attractive because they reinforce one another. If you can estimate difficulty you can split the budget; if you can split the budget you can choose where to stop; and all of it is justified on the cost axis.

An honest difficulty remains, though. Every one of these prescriptions assumes you can tell in advance how hard a problem is. But estimating difficulty before you reason is itself an unsolved problem. The paper points a direction; the difficulty signal you need to travel it is not handed to you for free.

Closing

"Scale test-time compute" is still a powerful lever. This paper does not deny the lever. It shows, from the authors measurements, that the lever has an end, and that over some range pulling it reverses direction.

The lesson I take is modest. "Thinking more" is neither free nor always correct; it is a hyperparameter in its own right. Something to tune, not a value to crank up without bound.

Of course the abstract alone cannot tell us how broadly this holds, or across which models and tasks. I leave that open. But against the reflex of treating "just burn more" as the default, this paper applies a healthy brake. Knowing when to stop now matters as much as knowing how much further to go.

References

• Shu Zhou et al., "When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling" (arXiv:2604.10739, 2026-04-12): https://arxiv.org/abs/2604.10739
• Same paper, PDF: https://arxiv.org/pdf/2604.10739