When to restart a reasoning model

Sources checked 6 October 2026.

A reasoning model has spent several minutes on a problem. It has written a lot, abandoned a few steps and returned to an earlier approach. You can let it continue, stop it or start another attempt. The amount of text on screen gives you little help choosing.

A 4 October preprint by Adib Hasan, Lay Jain and Thanic Nur Samin examines mathematical reasoning by separating strategy discovery from execution. The researchers studied four models using 35 fresh Olympiad problems and an additional non-geometry benchmark set. Runs with a supplied strategy sketch helped estimate the execution component. [1]

That is a useful distinction to keep in mind. A system can struggle to find a promising method and be quite good at carrying one out. Another can find a plausible approach and then fail to complete the argument. Giving each another block of time may have different effects.

What a supplied approach can reveal

Imagine a geometry problem where an auxiliary line makes the solution much easier. This is an illustration, not a reported problem from the study. An unaided attempt has to discover the line and use it correctly. An attempt given the line still has to execute the argument, but it has received information the first attempt lacked.

If you compare those attempts, you can learn something about where the difficulty sits. You cannot describe their success rates as equivalent measures of independent problem solving. The help supplied in the prompt is part of the experimental condition.

The paper uses its decomposition to forecast the effect of additional reasoning and explores whether to continue or restart. Results vary by model. The framework is predictive; it does not claim to reveal the model’s actual internal reasoning process. [1]

Four attempts can still be one mistake

A simple probability calculation explains why restarts are attractive. Suppose an attempt has a 25% chance of being correct and each attempt is independent. Four attempts give a 1 − 0.75⁴ chance that at least one is correct, about 68.4%. That is an illustrative assumption, not a measured success rate for any model.

Now suppose all four attempts make the same mistake on exactly the same problems. The chance stays at 25%. Real attempts can lie between those extremes. Repeating a prompt gives more samples, but it does not guarantee a new approach to the problem. A shared misconception can survive every restart.

There is a second condition hidden in the attractive number: being able to find the correct answer among the candidates. “At least one correct” is an oracle outcome. A product that picks the wrong candidate has not delivered that success to its user. The selection process needs its own evaluation and its own share of the budget.

The arithmetic also does not compare four short attempts with one long attempt. Shortening an attempt may change its success probability. To make that budget comparison, we would need the success curve at each allowed length, including the time spent judging the candidates. The drawing is a way to expose assumptions, not a restart policy.

Give additional attempts a purpose

For a team evaluating its own tasks, I would first fix the total budget and the acceptance test. Then compare a longer attempt with several fresh attempts using the same total allowance. Record both success and the cost of deciding which answer to accept.

This is a proposed evaluation plan, not a result from running those tests here. A team might find that fresh attempts repeat the same mistake. It might find that a longer run resolves details a short run repeatedly leaves unfinished. Either outcome would be useful if it changes how the team spends its budget.

Earlier work by Snell and colleagues, published at ICLR 2025, found that allocation should depend on problem difficulty and the method used to spend inference compute. [2] That is consistent with treating a time limit as a decision to evaluate. It offers no reason to expect one setting to suit every problem a product receives.

Gema and colleagues’ Inverse Scaling in Test-Time Compute, published in TMLR in December 2025, constructed tasks where additional reasoning reduced performance, including distraction and overfitting to the framing of a question. [3] Those deliberately revealing tasks do not establish how often the problem occurs in normal use. They do undermine the assumption that more reasoning must always improve an answer.

A restart need not throw away everything. If an attempt has produced a checked intermediate result, a new attempt can receive that result as an explicit input. The experiment then becomes a continuation with validated help, rather than an independent fresh solve. Keep that distinction in the record so the apparent gain has an explanation.

For a code-generation task, for example, a failed attempt might still uncover a real input constraint. Keep the constraint and the test that demonstrates it; discard the unverified claim that the whole implementation works. A second attempt can use the evidence without inheriting every design decision from the first.

The acceptance test is the difficult part outside mathematics. A generated explanation can sound confident while leaving the important question unanswered. Several similar answers can also share a mistaken assumption. Counting agreement between them would not provide independent confirmation.

For work with a checkable result, keep the checker separate from the decision about how long to reason. A test can establish whether an output meets a condition. It cannot, by itself, tell you whether another minute would have produced a better attempt.

The study’s mathematical tasks leave a substantial question for ordinary product work: how to tell that an attempt is making progress when the final answer has no reliable checker. A team can compare allocation policies under a fixed budget, but it will still need a defensible way to judge the outputs. The evaluation should record that judgement and its cost.

Sources

• [1] Hasan, Jain and Samin: When Does Longer Reasoning Help

• [2] Snell et al.: Scaling LLM Test-Time Compute Optimally

• [3] Gema et al.: Inverse Scaling in Test-Time Compute