flowchart TD
  A["The answer that needs a<br/>document, not another thought"] --> B["On this page"]
  B --> C["A budget is not a method"]
  C --> D["The meta-decision: which<br/>computation is worth doing<br/>next?"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#D95545,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

A budget is not a method

Test-time compute is any additional computation used after a task instance arrives and before the system commits to its answer or action. It can include a longer single trajectory, several independent trajectories, search over partial states, retrieval, code execution, simulation, model-based verification, deterministic checking, or a human review. These operations consume different resources and address different failure mechanisms.

The modern language-model literature made the budget visible. Self-consistency samples several reasoning paths and aggregates their answers. Tree-of-Thoughts explores partial alternatives with lookahead and backtracking. Repeated sampling raises the chance that at least one candidate is correct. Long-reasoning models allocate more generated or latent steps to one trajectory. Verifier-guided search scores candidate states or completed solutions. Each can improve performance in the settings studied, but none gives a universal instruction for the next unit of compute.

The dependency on task difficulty is now well supported. Snell and colleagues found that the effective mixture of parallel search and sequential revision varied by problem difficulty, and their compute-optimal allocation used substantially less test-time computation than a uniform best-of-N baseline in the evaluated mathematics setting. Damani and colleagues learned input-dependent allocation policies across mathematics, code and dialogue, reporting equal quality with materially less compute or better quality at a fixed budget. These are important results, but their deepest implication is not merely “route easy and hard questions differently”. It is that marginal value belongs to a task, an operation and a current state together.

Six distinct compute moves

A useful controller starts by refusing to collapse unlike operations into “reasoning”. The following six moves cover most practical cases. Stopping is included because a system that cannot decline another computation does not control its budget.

Continue

Extend one trajectory when the procedure is serial, the current direction remains promising, and additional steps can be checked.

Branch

Generate alternatives when uncertainty concerns which path is right and a voter, reward model, test or rule can discriminate among them.

Retrieve

Acquire authoritative world evidence when the answer depends on facts absent from current context. Retrieval changes knowledge, not merely prose.

Simulate

Run a model, program or operational twin when the uncertainty concerns what will happen after an intervention rather than what is presently true.

Verify

Spend compute on independent checking when a candidate already exists but its correctness, support or policy fit is uncertain.

Stop or escalate

Return the current result, abstain, request evidence or involve a person when no permitted computation has positive expected value.

This decomposition also reveals why common scaling curves are easy to misread. A best-of-N curve mixes the generator’s ability to place a correct answer somewhere in the candidate set with the verifier’s ability to select it. A long-chain curve mixes useful intermediate computation with repetition, second-guessing and context cost. A tool-using agent mixes inference with external computation and new evidence. The x-axis may be “tokens” or “samples”, but the causal mechanism is the state change those resources purchase.

Research supports both sides of the thought experiment. Repeated sampling can greatly increase coverage when correct outputs can be recognised, as shown by Brown and colleagues. Setlur and colleagues provide theoretical and empirical arguments that verification becomes increasingly important as test-time compute scales. Yet verification itself consumes budget and can be a weak instrument. Singhi and colleagues found that, under their fixed-budget comparisons, self-consistency was more compute-efficient than generative verification across most practical budgets, with the generative verifier requiring much more inference before matching it. “Verify more” is no more universal than “solve more”.

The meta-decision: which computation is worth doing next?

The problem predates language models. Work on anytime algorithms asked how a system should return progressively better answers when interrupted at different times. Decision-theoretic metareasoning then asked whether the expected improvement from another computation justifies its cost. The language-model setting adds new operations, uncertain verifiers and expensive generated context, but the central question is unchanged: should the system act now, or compute first?

Let the current observable state be s. It contains the task, evidence already acquired, candidate answers, tool results, verifier scores, deadline, consequence tier and remaining authority. Let c be a candidate computation such as retrieving one source, generating four branches, running a simulator or checking a claim. Let L be consequence-weighted loss, not merely zero-one error. A practical expected-value-of-computation rule is:

If the expected loss reduction rises, perhaps because a missing record is likely to settle a high-consequence question, the value of the computation rises. If latency becomes costly, the value falls. If the operation creates an uncheckable action or accesses data beyond entitlement, the control charge may dominate. If no operation has positive value, the controller stops. If residual loss remains above tolerance and the system lacks authority to proceed, it escalates.

No deployed controller knows the expectation exactly. It approximates it from validation data, calibrated models, deterministic business state and conservative rules. This is not a defect unique to metareasoning. Ordinary model routing already predicts which model will perform well on an input. The difference is that an adaptive compute controller predicts marginal improvement from a specific next operation, rather than a general label such as “hard”.

The compute allocation phase diagram

The controller first identifies the dominant deficit. Is the uncertainty mostly internal, meaning several complete interpretations remain plausible? Is it external, meaning the relevant world fact is absent? Then it asks whether feedback is strong enough to recognise an improvement. Exact unit tests, calculators and formal rules sit near the top. An uncalibrated self-critique sits much lower. Consequence changes the boundary: weak feedback may be tolerable for a reversible draft, but not for an irreversible decision.

When longer thinking is the right move

Longer sequential reasoning is valuable when the task has a serial dependency, the model is capable of the procedure, and intermediate progress remains informative. The s1 work showed that budget forcing could improve competition-mathematics performance before flattening and entering repetitive loops. Recent work on overthinking tracks correct-to-incorrect answer flips at higher budgets and reports that optimal lengths vary with difficulty. Medical-reasoning experiments similarly found that additional thought could plateau or introduce errors when missing knowledge, rather than insufficient deliberation, was the bottleneck.

These results do not prove that visible chain length is a faithful measure of internal reasoning. They do establish a practical boundary: sequential compute has a task-specific saturation point, and it can cross from diminishing return into negative return. A controller must therefore monitor outcome-relevant signals, not reward length itself.

When branching is the right move

Branching is attractive when success probability per attempt is non-trivial, candidates are sufficiently diverse, and selection is strong. If the base model’s probability of producing any correct candidate is effectively zero, more samples multiply failure. If all samples repeat one shortcut, parallelism is decorative. If the checker is weak, the blind-tournament problem returns.

A useful branch controller estimates three quantities separately: the chance another branch adds a materially different candidate, the chance the candidate set already contains a satisfactory answer, and the chance the selector will recognise it. Manvi and colleagues trained models to predict whether restarting could yield a better response, using those predictions to reduce sampling and prune poor partial generations. The operational lesson is broader than their method: ask whether the next branch can change the choice, not whether more branches are generally good.

When retrieval, simulation or verification dominates

Retrieval dominates when uncertainty is reducible by an authoritative observation. Simulation dominates when the question concerns an intervention and a trusted dynamics model can project consequences. Verification dominates when a candidate exists and a lower-variance mechanism can check a decisive property. These operations are often cheaper and more legible than extending a language trajectory.

The controller should also account for systems cost. Kinetics argues that memory movement and long-attention cost can change the apparent efficiency of test-time scaling, sometimes favouring a larger model with fewer tokens over a smaller model with a very long trace. Whatever one thinks of its exact empirical thresholds, the general correction is sound: FLOPs, tokens, wall-clock latency, memory occupancy and provider charges are not interchangeable budgets.

An adaptive controller that can be tested

A controller needs a bounded state representation, a small action set and a release policy. It does not need access to hidden chain-of-thought. In fact, relying on hidden or unbounded prose makes control harder. Observable state is enough: evidence completeness, candidate disagreement, tool availability, verifier calibration, task deadline, consequence tier, current cost, remaining budget and authority.

The controller can be learned, rule-based or hybrid. A learned marginal-gain predictor is useful in the residual where rules cannot identify the bottleneck. Deterministic routing should take precedence where business state is explicit. A missing mandatory field is not a probabilistic difficulty judgement. Neither is an expired approval, a transaction threshold or an unavailable authoritative source.

Minimal worked example: 3, 3, 8, 8 and the number 24

Consider the task: use each of the numbers 3, 3, 8 and 8 exactly once with basic arithmetic operations to make 24. The first attempt fails. The inputs are complete, so retrieval has little value. The task admits many discrete branches, and a candidate can be checked exactly by parsing the expression and evaluating it. The controller therefore buys parallel exploration rather than a single long monologue.

Suppose it generates eight structurally diverse expressions. Seven fail the exact checker. One succeeds: 8 / (3 - 8 / 3). The checker confirms that every input is used once and the result equals 24 within a numerical tolerance. The controller stops because the goal state is verified. It does not ask the generator whether its own expression “looks correct”.

Now remove the exact checker and replace it with a language-model judge that sometimes overlooks duplicated inputs. The value of branching falls sharply. The controller may still generate a small number of candidates, but its EVC estimate must charge for false acceptance. This is the same task with one causal feature changed: feedback quality.

The controller’s release contract

The compute policy should be versioned beside the model, prompt, tools and evaluators. At minimum, it needs the following fields:

The synthetic positive case gives each bottleneck a matching operation. The negative control shuffles routing features across cases while preserving policy cost. If the adaptive advantage survives the shuffle, the controller is benefiting from a hidden artefact rather than causal matching. In the default run, the advantage collapses, which is the intended result. The experiment demonstrates a property of the constructed environment only: adaptation earns value from informative routing signals, not from the label “adaptive”.

function chooseAction(features, consequence, costWeight, delayWeight) {
  const base = clamp(0.97 - 0.60 * maxDeficit(features), 0.25, 0.97);
  const improvement = {
    answer: 0,
    continue: 0.18 * serialNeed(features) * (1 - 0.35 * features.evidenceGap),
    branch:   0.47 * features.branchNeed * features.verifierStrength,
    retrieve: 0.56 * features.evidenceGap * features.evidenceAvailable,
    simulate: 0.48 * features.dynamicsNeed * features.simulatorQuality,
    verify:   0.34 * features.verificationNeed * features.verifierStrength,
    escalate: 0.62 * features.authorityGap
  };

  return permittedActions(features)
    .map(action => ({
      action,
      evc: improvement[action] * consequence
         - costWeight * (COST[action] - COST.answer)
         - delayWeight * (LATENCY[action] - LATENCY.answer)
    }))
    .sort((a, b) => b.evc - a.evc)[0];
}

stateDiagram-v2
  [*] --> Claim
  state "Six distinct compute moves" as Claim
  state "Figure 1. One budget can<br/>purchase six different changes<br/>of state" as Test
  state "Thought experiment 1, the<br/>blind tournament" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Operating the controller where mistakes have consequences

A benchmark controller can optimise answer accuracy under a token budget. An operational controller must also preserve identity, evidence, authority and recoverability. Retrieval may access data the requester is not entitled to see. Simulation may use an unvalidated dynamics model. Verification may share the generator’s blind spot. Branching may multiply private context. Continuing may exhaust a service deadline. Escalation may overwhelm a human queue.

The controller therefore belongs outside the model proposal. The model may suggest that it needs another source or another attempt. A deterministic policy decides whether that operation is permitted, what budget it receives, which tool contract applies, and which observations count as completion. This separation prevents a model from purchasing unlimited compute or expanding its own authority merely by claiming uncertainty.

Worked scenario: a covenant renewal decision

A commercial-lending assistant is asked to prepare a recommendation on whether an existing facility can proceed to renewal review without a covenant exception. The current context contains the latest financial statements, a facility summary and a policy extract. A first pass calculates leverage at 3.7 times against a 4.0 threshold and proposes “within policy”.

The controller does not simply grant a high reasoning budget because the case is financially material. It inspects the decision state. The ratio calculation can be reproduced exactly. The financial statements are current. Candidate disagreement is low. One required state is unresolved: the policy extract references a temporary sector overlay, but its effective-to date is absent.

The highest-value operation is retrieval from the governed policy register. The returned overlay remains effective and lowers the relevant threshold to 3.5. The controller then runs the ratio calculation through a deterministic tool, not through a second language trajectory. The result violates the overlay. A verification step confirms the policy version, source identity, effective time and arithmetic. The model revises the recommendation to “exception review required”.

The system stops before approval. No amount of inference gives it delegated authority to waive the covenant or approve the renewal. Its final output is a proposal with a decision receipt: evidence identifiers, policy version, calculation inputs, selected operations, unresolved judgement and the named human decision right. Adaptive compute changes the quality of the proposal without silently changing who may decide.

Calibration must follow the operation

A single router accuracy is insufficient. Each operation has a distinct false-negative risk. A false-easy decision denies useful compute. A false-evidence-gap decision can trigger needless data access. A false-branch decision creates cost and correlated candidates. A false-verifier-confidence decision may turn weak checking into false assurance. A false-stop decision commits too early. A false-continue decision wastes resources or overthinks a correct answer.

Calibrate marginal gain separately by task slice, action and budget. For branching, measure diversity, coverage and selection error. For retrieval, measure whether the retrieved item was authoritative, temporally applicable and actually changed the decision. For simulation, measure transfer from simulated to observed outcomes. For verification, report false acceptance and false rejection by defect type. For stopping, track correct-to-incorrect flips, unresolved evidence and downstream overrides.

Recent work explores several controller forms: classifiers that predict oracle allocations, bandit algorithms that distribute a shared budget across queries, constrained policies that target average compute, and self-evaluators that decide whether another sample is likely to help. These are promising mechanisms, not a settled architecture. The stable requirement is a credible evaluation that can distinguish why they work.

Failure injection for the controller

Ordinary benchmark cases show average performance. A controller needs targeted failures. Inject an apparently easy problem whose decisive exception appears late. Remove the authoritative source while leaving a plausible stale copy. Correlate all branches through the same misleading hint. Give the verifier a formatting bias. Delay a tool response until the deadline expires. Return an ambiguous commit from an external action. Mark an irreversible case as low consequence. Each injection should predict a visible policy response.

The strongest release test is paired. Keep a clean case and change exactly one causal feature. The controller should change only the operation implied by that feature. If adding a missing-source flag causes it to branch rather than retrieve, the policy has learned a surface association. If degrading verifier accuracy does not reduce branching, its EVC model ignores selection risk.

Where the mechanism breaks

Adaptive test-time compute cannot repair absent capability, unavailable evidence, unmodelled reality or missing authority. If the base model never produces a viable solution, branching only creates more failures. If the relevant fact cannot be retrieved, additional prose cannot make it known. If the simulator omits the causal variable that matters, more rollouts produce precise fiction. If the verifier cannot distinguish the material defect, search optimises the wrong score. If the decision is reserved for a person, computation may support but cannot inherit that right.

There is also a meta-cost. Predicting the value of computation consumes computation. A controller with dozens of expensive evaluators can cost more than the work it saves. Rational metareasoning is itself an approximation problem. The action set should therefore remain small, its features observable, and its cheap rules dominant. Learned control belongs where the residual value justifies its own overhead.

A second boundary is distribution shift. An adaptive policy can appear efficient by learning benchmark-specific markers of difficulty. New product forms, languages, codebases or policy structures can reverse those markers. Monitor not only blended accuracy and cost, but route rates, marginal gains, false-stop cases and the residual errors within each route. A stable average can conceal a shrinking hard-case recall.

A third boundary is operational capacity. An escalation policy that sends thirty per cent of cases to a team capable of reviewing five per cent is not safe. It creates a latent queue, delayed decisions and pressure to rubber-stamp. The controller’s cost function must include scarce human attention, and its release test must exercise adverse traffic in which both volume and case difficulty rise.

A practical decision protocol

1. State the decision and consequence. Define what must be correct, what can be reversed, who may decide and the deadline.
2. Diagnose the dominant deficit. Separate missing evidence, internal search, uncertain dynamics, candidate checking and human-dependent judgement.
3. Enumerate permitted operations. Give each a typed input, expected state change, cost, latency, verifier and authority boundary.
4. Estimate marginal value. Use local evidence for expected loss reduction and charge compute, delay, privacy, security and review burden.
5. Execute one bounded operation. Observe its result and update the state. Do not grant a free loop around per-call ceilings.
6. Stop on evidence, not exhaustion. Stop when a verified goal is reached, the best EVC is non-positive, the deadline binds, or authority requires escalation.
7. Write a compute receipt. Preserve why the operation was selected, what changed, what remains uncertain and which policy version governed the choice.

Compact glossary

Test-time compute

Computation spent after a task instance arrives and before the system commits to an answer or effect.

Marginal gain

The expected improvement from the next unit or operation, rather than total performance at a budget.

Verifier

A mechanism that scores or checks a candidate. It may be exact, learned, model-based or human.

Coverage

The probability that a candidate set contains at least one satisfactory answer, irrespective of whether it is selected.

Stopping rule

A condition that ends computation because a verified target is met, value is exhausted, a deadline binds or authority ends.

Compute receipt

An observable record of state, candidate operations, expected values, chosen operation, result, cost and residual uncertainty.

Spend the next unit where it can change the decision

The test-time-compute question is usually phrased as quantity: how many tokens, samples, revisions or verifier calls should a system receive? Quantity matters, but it arrives one decision too late. The prior question is what uncertainty currently blocks a defensible answer and which permitted operation can reduce it.

Sometimes the answer is a longer trajectory. Sometimes it is a branch with an exact checker. Sometimes it is a document, a calculator, a simulator or an independent verification pass. Sometimes the system already has enough evidence and should stop. Sometimes no machine computation can close the gap and the correct action is to escalate.

The architecture changes when test-time compute becomes a governed portfolio of state-changing operations. A global reasoning setting becomes a versioned policy. A confidence score becomes one input among evidence, consequence, verification and authority. A token ceiling becomes a trajectory ceiling. A scaling curve becomes a set of marginal-value curves by operation and task slice. An expensive answer becomes a replayable decision with a compute receipt.

The research programme is equally concrete. Compare bottleneck-aware control with uniform budgets and scalar difficulty routing. Match total compute, latency and verifier cost. Inject missing evidence, correlated branches, weak judges and false-easy cues. Preserve a shuffled-signal negative control. Measure verified decisions, not verbal elaboration. The winning controller is the one that knows not merely how to think longer, but what to do next, when to stop and when not to decide.