← logs/

Test-time compute: when more thinking helps, and when models get lost

Test-time compute is the easiest lever in the reasoning stack: no retraining, no new data, no reward model. Just let the model think longer. But the lever has a failure mode that the field measured before it understood it: under the wrong conditions, more thinking does not fix the answer. It commits the model to a wrong path with more confidence.

This post reads three papers that bracket the phenomenon. s1 shows exactly what budget forcing buys. LIMO shows how much of "reasoning ability" was already in the weights. And the ICLR 2026 Outstanding Paper on LLMs getting lost in multi-turn conversation is the failure side of the story.

The field map: thinking is a budget, not a capability

The o1 era reframed reasoning as a resource: models spend tokens on hidden deliberation, and performance improves with more of it. The replication wave split into two camps. One treats test-time compute as a dial you can turn per request: terminate early, or force the model to keep going. The other argues that what looks like a thinking capability is mostly elicitation of knowledge that is already in the weights, and that the real lever is post-training data; the inference budget is secondary. Both camps are partially right, and the disagreement resolves into one question: what does extra thinking actually change in the model's internal state?

Close read: s1, and the dial that works

s1: Simple test-time scaling (Muennighoff et al., Stanford, January 2025) is the cleanest statement of the dial camp. Two ingredients. First, a small dataset: s1K, 1,000 questions with reasoning traces, curated on three criteria validated through ablations: difficulty, diversity, and quality. Second, budget forcing: a decoding-time controller that forcefully terminates the model's thinking, or lengthens it by appending "Wait" multiple times when the model tries to end. That single trick lets the model double-check its answer, and it often fixes incorrect reasoning steps.

The numbers are striking. After supervised fine-tuning of Qwen2.5-32B-Instruct on s1K, the resulting s1-32B exceeds o1-preview on competition math by up to 27 percent (MATH and AIME24). And budget forcing extrapolates beyond what the model achieves without intervention: from 50 percent to 57 percent on AIME24. No retraining, no new data, no reward model; the dial works.

What the paper reveals indirectly is the precondition: budget forcing only pays off when the model's next tokens are plausible reasoning steps. "Wait" is a cheap way to re-open a chain of thought that closed one step too early. It does nothing when the model is confidently wrong, because the extra tokens get spent re-deriving the same wrong frame.

The paper also reports the dial's own limits: the gains from budget forcing flatten as the budget grows, and the trick is bounded by the context window, because every appended "Wait" spends context that a long chain was already consuming (§4.4.3). The dial works, but it has a ceiling and a meter running.

Close read: LIMO, and the knowledge that was already there

LIMO: Less is More for Reasoning (Ye et al., February 2025) attacks the same problem from the training side. LIMO is a plain supervised fine-tune on 817 carefully curated math problems with long reasoning traces, roughly 1 percent of the training data prior approaches required. The result: 63.3 percent on AIME24 and 95.6 percent on MATH500, versus 6.5 percent and 59.2 percent for the previous fine-tuned models, plus a 45.8-point absolute improvement across diverse out-of-distribution benchmarks, beating models trained on a hundred times more data. The dataset is public.

The LIMO hypothesis states the mechanism: by the time a foundation model is pre-trained, the domain knowledge is already encoded in the weights. Post-training examples do not teach the model to reason; they act as cognitive templates that show which reasoning paths to take. Under this view, a large share of what test-time compute appears to add, the ability to produce a long correct chain, is latent capability being elicited.

The two papers do not contradict each other; they split the same phenomenon. s1 shows you can push a model to spend more of its latent capability at inference time. LIMO shows how little post-training data it takes to make that capability accessible. Both say the hard part is not the thinking budget; it is whether the model has a correct path available to spend it on.

Close read: LLMs Get Lost in Multi-Turn Conversation

The failure side is LLMs Get Lost in Multi-Turn Conversation (Laban, Hayashi, Zhou, and Neville, Microsoft Research and Salesforce Research), recognized as an Outstanding Paper at ICLR 2026. The setup: the authors shard fully-specified instructions from single-turn benchmarks into pieces revealed one per turn in a simulated conversation, then compare against the single-turn baseline where the whole instruction is given at once.

The results are a warning to anyone who treats context as free. Across 15 LLMs and six generation tasks, with more than 200,000 simulated conversations, average performance dropped 39 percent from single-turn to multi-turn, a 25-point absolute fall from roughly 90 percent to 65 percent. The paper decomposes the drop into a minor loss in aptitude and a large increase in unreliability. Models make assumptions in early turns, prematurely attempt final solutions, and then over-rely on them. In the authors' words: when LLMs take a wrong turn in a conversation, they get lost and do not recover.

The detail I find most damning: the model selection deliberately included two reasoning models, o3 and DeepSeek-R1, specifically to probe test-time compute in multi-turn conversations. They got lost too. Extra thinking did not rescue them, because the failure was not a missing reasoning step; it was commitment to an early assumption that no amount of subsequent deliberation revisits. That is the same pathology that limits budget forcing: "Wait" re-opens a chain of thought, but not the frame of the problem.

My position: make the budget conditional

The synthesis, for me, is that test-time compute is a dial on the path the model is already on, not a path-finder. It pays off under two conditions: the knowledge is in the weights, which is LIMO's point, and the model can still detect and revise its own errors, which is s1's point. It fails when the model has committed to a wrong frame, which is exactly the multi-turn failure mode. s1's own reported limits point the same way: when the gains flatten and the context window runs out, an unconditional budget is the wrong default even inside the dial camp.

The build that follows is a budget controller, conditional by design:

  • verifiable, competition-style tasks get large budgets, because success is checkable and re-opening the chain pays,
  • open-ended and conversational refinement tasks get caps, because their error mode is commitment, not premature stopping,
  • the controller watches the trace for commitment signals, an early final answer, a repeated assumption, a long stretch without revision, and intervenes by re-framing, adding a recap of the actual requirements, or terminating,
  • evaluation moves to multi-turn sharded settings, because single-turn scores systematically overestimate what the same model does in use.

One result in the multi-turn paper supports the cheapest intervention I know: the RECAP setting, a single extra turn that restates every shard after the conversation. The scope is worth stating precisely: RECAP was tested on two models and four tasks, the recovery is partial, and the single-turn ceiling stays out of reach. Even so, a real share of the loss comes back from one cheap turn, which makes re-grounding the best cost-benefit trade in the paper. The controller's job is not to maximize thinking. It is to notice when the model has locked onto the wrong path, and to do something about it.

What this changes for PiPlan.ai

PiPlan.ai's conversational planner-executor is still in progress, so this is a design note rather than a result. The multi-turn paper reads to me like a specification for what that agent must survive. A planning conversation is close to the paper's sharded setup: the user's constraints arrive over many turns, the model drafts a plan midway, and the failure mode is commitment to an early framing of what was asked.

Two design requirements follow. The first is shard-resistance: the agent cannot treat a drafted plan as fixed, because later turns routinely invalidate the assumptions the draft was built on. The second is re-grounding at plan time, the RECAP pattern applied to planning. Before any plan is committed, the executor restates the full requirement set it has accumulated and checks the plan against that restatement rather than against its running summary. Recap-before-commit costs one turn, and the paper's partial-recovery result is the evidence that cheap is not the same as weak. Whether it holds up in our workload is something to measure when the agent ships, not something I am claiming now.

Sources linked in this post were fetched and verified.