/p/2026-09-16 · explainer
Paper explainer · 2609.15309 · Liu, Mang et al.

Where more tokens
stop paying.

Giving an agent a bigger budget always makes its answer better, so nobody asks the next question: better than what? The honest comparison is throwing the same tokens at independent attempts and keeping the best, which earns exactly 400 rating points per tenfold increase in compute. Four agent harnesses on four open-ended benchmarks all start above that line and all end below it — and on one task, splitting a 100M-token budget at the crossing beat one long session by 264 rating points.

01 · The ruler

There is an exact answer to "how much should more compute buy?"

Open-ended tasks — packing shapes, tuning a GPU kernel, improving a model — give every intermediate submission a score, so you can watch quality climb as the tokens go in. But raw scores lie about progress: on a packing problem, moving from 1 to 2 is trivial and moving from 2.634 to 2.635 set a world record. So the authors stop scoring and start rating: at each token budget, a system's best-so-far solution is compared head to head against every other system and budget on that task, and those win/lose outcomes are fitted into a single rating scale.

On that scale one strategy has a closed-form answer. Solve the problem k separate times with no shared memory and keep the best attempt: the rating gain is exactly 400 × log₁₀(k), whatever the score distribution is. Drag the number of attempts.

Interactive · what independent attempts are worth
rating gain
what that means
chance the k-attempt result beats the single attempt, from the rating difference alone

That line is the thing to beat. An agent that revises, backtracks, reads its own history and decides when to stop is doing something more sophisticated than starting over 10 times — so its curve should climb faster than 400 points per decade of tokens. The paper's whole question is whether it does, and for how long.

02 · The measurement

Every harness starts above the line and ends below it

Four agent systems — Kimi Code, Codex, Claude Code and Gemini CLI — ran five sessions each on fourteen problems drawn from four open-ended benchmarks, to a target of 100 million tokens per task. Every system improved throughout. Every system's local slope, the rating it earned per tenfold increase in budget, peaked early and then fell, and in the pooled fit every one of them drops below 400 by the largest budgets.

Drag the budget. Above the dashed line, spending the next token inside this session beats starting a fresh one; below it, the opposite.

Interactive · local slope against the sampling reference illustrative
rating per tenfold, here
cheaper next token

The last crossing has a name: the scaling inflection point. It is not a curve-fitting artefact — the paper proves that past it, freezing the agent's state and sampling independent continuations from there eventually beats letting the session carry on. The session may still find better solutions; it just finds them less efficiently than a fresh start would.

Specialised strategies do not change the shape. Two outer-loop optimisers that evolve solutions or prompts from evaluator feedback lead the plain agent by more than 300 points at 100K tokens, get caught after about 1M, and finish within about 20 points of it. Test-time training, which updates the model's own weights from task feedback as it goes, shows the same brief burst and the same decline. What does keep climbing is people: on seven algorithm contests, the top human cohorts' curves bend upward in log time, and on one contest reproduced end to end the top-10 cohort overtook both agents while the agents' curves had already flattened within 72 hours.

03 · The rule

Cap the session at the crossing, then buy breadth with what is left

The inflection point converts directly into an allocation. Run each session only as far as the crossing, so every session gets the part of the trajectory where the harness beats sampling, then spend the remaining budget on more sessions and keep the best result. The number of sessions is the total budget divided by the crossing, rounded up.

On the packing task the authors profiled, the crossing sat at 38 million tokens — so a 100-million-token budget says three sessions. Set your own numbers.

Interactive · the allocation rule
sessions to run
rating over one long session
the breadth part is worth 400 × log₁₀(sessions); the depth part is whatever your harness earned before the crossing

04 · The test

Three sessions beat one long one, and beat ten short ones

Predicting an allocation is easy; the paper then ran the comparison. Six ways of splitting 100 million tokens on the same packing task were rated against each other on one scale, with every allocation's rating averaged over 20,000 random assignments of sessions to groups. The rule's prediction won.

Interactive · how to spend 100M tokens on one task
relative ratingbest of the six allocations

Note which extreme loses harder. Ten short sessions is worse than one long one — each of those sessions gets cut off well before the crossing, so none of them ever reaches the part of the curve where the harness is earning its keep. Breadth is not free; it is what you buy after depth stops paying, and the measured order flips as the total budget grows. One session is genuinely best at small budgets.

The authors' explanation for the flattening is worth holding onto even though it is a hypothesis rather than a result. Early in a session an agent commits to an approach — an algorithmic idea, a code structure — and as context accumulates that commitment gets harder to abandon. Improvements continue inside the chosen basin; the choice of basin does not get revisited. If that is right, a fresh session is not just extra samples, it is another draw at the decision that dominates the outcome.

05 · On your agents

What this changes about how you run a long job illustrative

Most production agent loops have exactly one knob for hard tasks: let it keep going. This paper says that knob has a measurable end, that the end is task-specific, and that the cheapest way to find it is to record what you already have — a score for each intermediate result, and the tokens spent when it landed.

Interactive · a budget you might actually have illustrative
one long session
capped at the crossing

One honest caveat before you build on it: the crossing does not generalise across tasks in the same domain. The domain-level curve for the benchmark this packing task belongs to crosses somewhere other than 38 million tokens, and the same mismatch shows up on the second benchmark they replicated. Predicting the crossing without profiling the task is listed as open work, so treat a measured cap as a per-task setting, not a global constant.

Results

What the paper actually measured

What it does not show

In practice