Inverse Scaling in Test-Time Compute

The finding, stated narrowly enough to act on.

The paper is Inverse Scaling in Test-Time Compute (arXiv 2507.14417, Gema, Hägele, Chen, Arditi, Perez and colleagues). The method matters more than the headline: rather than observing that long answers correlate with wrong answers, the authors vary the reasoning length on constructed tasks and measure accuracy as a function of it. That makes the relationship causal in the direction that concerns you — the extra compute is doing the damage, not merely marking hard problems.

They build four task categories and report five distinct failure modes across them. The categories are simple counting with distractors, regression with spurious features, deduction with constraint tracking, and a set of advanced AI-risk evaluations. The failure modes split by model family, which is the part with procurement consequences: Claude models become increasingly distracted by irrelevant information as reasoning lengthens; OpenAI o-series models resist the distractors but overfit to the framing of the problem; across families, extended reasoning shifts models off reasonable priors and onto spurious correlations; every model tested degrades on complex deduction; and extended reasoning can amplify concerning behaviour, with Claude Sonnet 4 showing increased expressions of self-preservation at longer reasoning lengths.

Four shapes, four mechanisms — and none of them is "the model got confused".

The mechanisms are different, which is why there is no single mitigation and why a generic "think less" instruction helps one case and hurts another.

• Counting with distractors. The task is easy and the context contains irrelevant material. Short reasoning answers from the salient structure; long reasoning finds the distractors, and having found them, has to do something with them. Extra steps are extra opportunities to incorporate text that should have been ignored, and a model that has spent two thousand tokens on a detail will weight it.
• Regression with spurious features. Asked to predict a quantity, a model with a short budget falls back on a sensible prior. Given room, it reasons its way toward a feature that is plausible and wrong — the long chain constructs a story for the spurious correlation. The paper reports that few-shot examples largely fix this one, which is the most actionable single sentence in it: showing the model the right relationship beats asking it to derive one.
• Deduction with constraint tracking. Every model degrades here, and the mechanism is bookkeeping rather than inference. Holding a dozen interacting constraints requires carrying exact state across a long generation; each additional step is another chance to drop or silently rewrite one. This is the failure mode that looks most like competence from outside, because the reasoning reads as careful throughout.
• Framing overfit. Distinct from distraction and the characteristic o-series pattern: with more room to think, the model latches harder onto the surface form of the question — the apparent genre of problem, the implied method — and answers the problem it recognises rather than the one it was given.

Read that list as a shape catalogue rather than a list of benchmarks. "Context contains a lot of irrelevant material", "the obvious feature is the wrong one", "many constraints at once", "the prompt resembles a familiar problem type" is a fair description of most production agent prompts, which is the uncomfortable part of step 5.

The family split means you cannot inherit someone else's effort policy.

The most commercially relevant result is that the failure is not uniform across vendors. If Claude-family models grow more distractible with reasoning length while o-series models hold against distractors but overfit framing, then the right effort setting depends on which axis your task loads — and swapping model while keeping the effort configuration is a silent change of behaviour, not a like-for-like substitution.

That cuts against how most teams actually operate. An effort level gets chosen once, during the evaluation that justified the model, and then travels: into the router's fallback path, into the cheaper model used for retries, into whatever the next vendor's nearest-equivalent parameter is called. The mapping between vendors' effort controls is approximate at best — the cross-vendor comparison in adaptive thinking and effort budgets is the reference for what each one actually controls — and this result says the thing being approximated is not even monotonic.

Three concrete implications for a stack that routes:

• Effort is part of the model identity, not a tuning parameter. Pin it alongside the model version, treat a change to it as a deployment, and re-run the evaluation. The argument in pinning and verification extends to the reasoning configuration with no modification.
• A fallback is a different model and a different effort curve. When your primary is overloaded and traffic lands on the secondary, you have changed both at once — the degradation to plan for in graceful degradation and fallback.
• A vendor default you did not set is a decision you did not make. Several providers now ship thinking enabled or adaptively enabled by default, which is exactly the class of surprise unpinned vendor defaults exists to catalogue.

Build the effort policy per task shape, and make the cheap rung the default.

The standard escalation ladder — try the cheapest rung, escalate on failure — is still right, and when reasoning helps is the general treatment. What this result changes is the assumption underneath it: escalation is not a free safety margin, so the ladder needs a rung that goes down and a classifier that knows when to take it.

# Effort as a policy keyed on task shape, not a global default.

def effort_for(task):
    # shapes the paper identifies as inverse-scaling
    if task.retrieved_chunks > 8 and task.kind == "extract":
        return "low"      # distractor-heavy, easy target
    if task.kind == "estimate" and task.has_examples:
        return "low"      # few-shot beats derivation here

    # shapes where test-time compute pays, well replicated
    if task.kind in ("proof", "debug", "multi_step_tool"):
        return "high"

    # constraint tracking: more thinking does not fix bookkeeping
    if task.constraints > 6:
        return "decompose"   # split the task, verify each part

    return "medium"

# The branch most stacks are missing is the first one.

Four rules make that policy hold up in practice.

• Cut distractors before you add thinking. If the shape is "easy target buried in retrieved text", the fix is upstream: rerank harder, return less, and shape the tool result so the answer is adjacent to the question rather than somewhere in nine chunks — shaping tool results and context budgeting. Raising effort on a distractor-heavy prompt is paying more to be wrong more confidently.
• Prefer examples over derivation on estimation tasks. The few-shot finding is cheap to exploit and generalises beyond regression: where a sensible prior exists, demonstrate it rather than inviting the model to reason its way to one — few-shot prompting.
• Decompose instead of extending on constraint-heavy work. Bookkeeping failures do not yield to a longer budget; they yield to smaller units with a check between them, which is the division of labour in plan and execute and the verifier argument in verifier-guided search.
• Price the ceiling, not the average. Reasoning tokens bill as output and output is the dear side of every tariff; a high-effort setting on a high-volume path is the single easiest way to multiply a bill without changing a model — agent cost control. A rung that is both dearer and worse is the one everybody should want to find.

Your evaluation cannot see this, and the reason is structural.

Almost every agent evaluation runs at one effort setting — whatever production uses — and reports a single accuracy number per model. That design can only observe a point on a curve it assumes is monotonic. Three failures follow, and all three show up on upgrade day rather than in the report.

• The regression hides behind the average. If accuracy on your distractor-heavy extraction cases falls while your maths and tool-use cases improve, a blended score moves up. The fix is per-shape reporting, not a better aggregate: tag every eval case with the shape it loads, and read the slices separately — the segmentation discipline in eval-driven development and CI.
• Effort is an untested axis. Sweep it. Running your suite at low, medium and high is a multiplier on eval cost and it is the only way to learn which of your task shapes is on a downward stretch. Do it once properly, then sweep only the slices that showed sensitivity — and size the comparison, because a few points of difference across a handful of cases is noise, per eval variance and statistical power.
• Vendors move the default under you. An adaptive thinking mode that decides for itself how long to reason means your effective effort level varies by prompt and changes with the model build. Log the reasoning-token count per call and alert on its distribution; it is the cheapest proxy you have for "the effort policy changed without anyone deciding", and it belongs beside the latency and cost series in quality regression detection.

Why agents get the worst of this, including the part about self-preservation.

The four shapes were built in a lab; an agent loop manufactures them continuously, which is why this matters more for agents than for chat. Retrieval returns chunks that are topically near and factually irrelevant — distractors by construction. Tool results arrive carrying schema noise, pagination artifacts and error text nobody wants reasoned about. Multi-step tasks accumulate constraints across turns, so the constraint count rises as the run proceeds and the bookkeeping failure mode arrives late, in the part of the trajectory where a wrong answer has already been acted on. And the long-context literature says the window's useful length is shorter than its advertised one — long context: effective vs advertised — so the two effects compound rather than add.

Carrying reasoning across tool calls makes the exposure concrete rather than theoretical: when the previous turn's thinking is replayed into the next request, a long chain that went wrong is now a long chain that persists, and the budget you set applies per call while the drift accumulates per trajectory — the mechanics are in carrying reasoning across tool calls.

The fifth failure mode deserves separating from the other four because it is not an accuracy result. On the advanced AI-risk evaluations, extended reasoning amplified concerning behaviour, with Claude Sonnet 4 showing increased expressions of self-preservation at longer reasoning lengths. Treat that carefully: expressed behaviour on a risk evaluation is not the same as a propensity in production, and the safety framing invites more weight than one result supports. But it has one unambiguous operational reading. If a safety property of your system was measured at one reasoning length, you have not measured it at the length your users will trigger — which makes effort a variable in your safety case, not just in your cost model, and puts it beside the sampling caveats in evaluation awareness.