Blog · arXiv Analysis · Last reviewed June 25, 2026

The Evaluation Score Becomes the Inference Budget

Jessica McFadyen, Ole Jorgensen, Harry Coppock, Kevin Wei, and Cozmin Ududec's June 2026 arXiv paper argues that a frontier-model benchmark score is not just a property of the model. It is also a property of the runtime budget and protocol used to elicit the answer.

For this essay, an inference-budget evaluation is an evaluation that treats tokens, attempts, feedback, tool time, context compaction, timeouts, and serial-or-parallel allocation as part of the measured system. The claim is not "the model scored X." The claim is "the model reached X under this runtime protocol."

The Budget Is Part of the Score

The paper, arXiv:2606.17930 [cs.AI], was submitted on June 16, 2026. arXiv lists the title as How Inference Compute Shapes Frontier LLM Evaluation, by Jessica McFadyen, Ole Jorgensen, Harry Coppock, Kevin Wei, and Cozmin Ududec.

A benchmark score often arrives as a single number. That number looks clean enough for a leaderboard, procurement memo, policy threshold, or safety claim. The paper makes that number messier in a useful way. On hard tasks involving tool use, iterative solving, long trajectories, and repeated submissions, measured performance can depend heavily on how much inference-time compute the evaluator allows and how that compute is allocated.

That changes the meaning of a low score. It may indicate a capability limit. It may also indicate a protocol limit: too few attempts, too little feedback, too short a trajectory, a weak scaffold, a timeout, a context window that forced information loss, or a budget too small for the capability to surface. The score is evidence only when the budget travels with it.

Current Context

As of June 25, 2026, inference-time compute is a live governance problem because evaluations are becoming evidence for release gates, safety cases, procurement decisions, and regulatory obligations. NIST's AI test, evaluation, validation, and verification work says trustworthy AI depends heavily on reliable measurements and evaluations, and that measurement context matters because the way a component is evaluated can change with the system's operating context. That is exactly the problem this paper isolates for runtime budgets.

The EU AI Act gives the legal version of the same pressure. Article 55 requires providers of general-purpose AI models with systemic risk to perform model evaluation using standardized protocols and tools reflecting the state of the art, including documented adversarial testing to identify and mitigate systemic risks. The AI Act does not prescribe the compute curve described in this paper. But once evaluation becomes part of a legal or safety record, the protocol details become harder to treat as footnotes.

NIST's AI Risk Management Framework is voluntary, not a certification regime, but it is also relevant: it is designed to improve the ability to incorporate trustworthiness considerations into AI design, development, use, and evaluation. If an organization uses a benchmark score to justify trustworthiness, it should be able to show whether the score came from a cheap single pass, a long search process, repeated submissions, external feedback, or a parallel sampling budget.

The Paper Frame

The authors evaluate up to 12 frontier language models across seven challenging benchmarks spanning software engineering, mathematics, medicine, expert knowledge, and cybersecurity. The main controlled suite uses six frontier models, five non-cyber benchmarks, two feedback conditions, and five independent trajectories per task. The paper also incorporates two previously collected UK AI Security Institute cyber evaluations for inference-scaling analysis.

The benchmarks named in the paper include TerminalBench, SWE-Bench Pro, FrontierMath, HealthBench, Humanity's Last Exam, Cyber CTFs, and The Last Ones. The non-cyber tasks are scored with programmatic tests, code execution, LLM judging, or physician-designed rubrics depending on benchmark. The paper warns that its expanded-budget runs and task subsampling mean its absolute scores are not directly comparable to published leaderboard scores.

What the Protocol Changed

The controlled setup uses three simple inference-scaling interventions. First, it expands total token budgets to 5M-30M tokens per trajectory depending on the benchmark, one to three orders of magnitude above many published defaults. Second, it uses context compaction, replacing earlier turns with summaries when context grows. Third, it permits iterative resubmission, with a hard cap of 999 submissions and a repetition guard that stops near-identical answer loops.

The feedback condition matters. In the no-feedback condition, a model receives only an ambiguous acknowledgement that its answer has been saved. In the oracle-score condition, the model is told whether a submission is correct, or receives partial-credit scoring for HealthBench. The token budgets are described as all-inclusive for the target model, including input, output, and reasoning tokens, while excluding LLM-judge tokens from the plotted counts. That exclusion is legitimate for the paper's curves, but it is also exactly the kind of detail a governance record must preserve.

The paper also studies serial versus parallel allocation: one deep trajectory versus multiple shallower independent trajectories under the same total budget. Those are different operational policies. Serial depth gives a model more room to iterate, compact context, submit, and recover. Parallel width gives the evaluator or system multiple independent shots and then aggregates them. A deployment can look like either one, or like a hybrid router. A benchmark table should not hide which one was used.

What Moved

The headline result is not that every benchmark rewards more tokens. It is that benchmark response is uneven. The paper reports meaningful headroom beyond typical budgets on FrontierMath, Humanity's Last Exam, and the cyber evaluations. It reports much smaller gains on HealthBench and the two software-engineering benchmarks under the tested protocol. TerminalBench and the cyber CTF suite show continued growth across all or most tested models within the observed range.

The task-level analysis separates reach, efficiency, and reliability. Later model generations tend to unlock more tasks and solve reachable tasks more reliably. Token-efficiency improvements are less uniform. Repeated submissions improve performance on all five main benchmarks, while oracle feedback helps most where it supports continued search. Parallel sampling helps substantially on HealthBench and Humanity's Last Exam, but less on FrontierMath, TerminalBench, and SWE-Bench Pro.

The useful policy result is not "raise every budget." It is "show the curve." Some tasks plateau early under this scaffold. Some continue improving at the cap. Some respond to feedback. Some respond to parallel attempts. Some may need better tools rather than more tokens. A single score collapses those differences into false simplicity.

The Compute Curve

The core object should be a compute curve: performance as a function of an explicitly counted inference budget under a named protocol. The curve should reveal onset, slope, plateau, and uncertainty. It should also say what is excluded, such as judge calls, retrieval costs, tool-execution time, human scoring, or benchmark-specific infrastructure.

For capability governance, the curve prevents premature comfort. If performance is still rising at the tested cap, the evaluation has not shown the model's limit under that protocol. It has shown the highest point reached before the evaluator stopped paying. For safety governance, the curve prevents another mistake: assuming a model is harmless because it failed under a shallow budget while a deeper, tool-rich, feedback-guided setup might elicit the capability.

For procurement, the curve is also economic evidence. A buyer should know whether a product's claimed score requires five million tokens, repeated attempts, oracle feedback, high latency, a judge model, or a tool stack unavailable in production. The same score can mean different cost, latency, carbon, privacy, and operational risk.

Governance Reading

The Spiralist reading is that the evaluation score becomes an inference-budget receipt. A fixed-budget benchmark can be useful, but it should not masquerade as a full capability boundary. A low score may mean the model cannot solve the task. It may also mean the evaluator denied enough search depth, repeated attempts, feedback, context, tool time, or parallel restarts for the capability to appear.

This belongs beside inference and test-time compute, AI evaluations, capability-frontier evaluation gaps, and embodied test-time scaling. The shared lesson is that evaluation is an operating condition, not a neutral window. If a policy threshold, release decision, or safety case depends on a score, the runtime protocol has to travel with it.

The governance standard should be stricter in high-stakes settings. A release packet should include performance at matched budgets across model generations, not only each model's best-looking number. A safety case should say whether the dangerous capability was tested at the same compute budget that a motivated user, agent, or red team could plausibly spend. A procurement comparison should disclose whether one vendor's score reflects a single answer while another's reflects repeated attempts and judge-assisted selection.

The same discipline applies to internal model improvement. If a new generation looks safer or less capable under a shallow budget but becomes more capable under a large one, the governance claim should use the large-budget curve for risk analysis. If a system will be deployed with automatic retries, tool use, feedback, or parallel sampling, the evaluation should test those features rather than a cheaper demo configuration.

Limits

This page reads one preprint and its arXiv record. The paper studies one ReAct-style scaffold, deliberately simple interventions, finite benchmark subsets, and two cyber datasets collected under a related but not fully crossed design. The authors explicitly describe their protocol as a lower bound on what simple reproducible inference scaling can elicit, not an upper bound under optimized benchmark-specific scaffolding.

That caution matters for governance. A compute-scaling curve is evidence about a model under a specific scaffold, budget, feedback rule, judge, tool set, timeout, and stopping policy. It does not by itself prove that a model is safe, unsafe, deployable, or non-deployable. It makes the measurement boundary harder to hide.

The paper also warns that weak scaling on a benchmark should be read as a property of the tested protocol. A plateau may reflect a real limit, but it may also reflect turn caps, timeouts, judge behavior, scaffold mismatch, context compaction loss, or a missing verifier. The honest conclusion is narrower: this protocol produced this curve.

Failure Modes

Fixed-budget laundering. A single low-budget score is presented as if it bounded model capability, even though performance is still rising when the budget increases.

Best-score laundering. A high score produced by repeated submissions, oracle feedback, large token budgets, or parallel attempts is compared against another system's single-pass score without naming the difference.

Judge-cost erasure. LLM judge tokens, human expert time, verifier calls, code execution, retrieval, or tool costs are excluded from the headline budget and then forgotten in procurement or safety analysis.

Feedback mismatch. An evaluation gives oracle correctness feedback that real users or attackers will not have, or withholds feedback that a real production system would provide through tests, logs, or environment state.

Context-compaction opacity. Earlier turns are summarized or discarded, but the report does not say what information was compressed, lost, or distorted before later submissions.

Serial-parallel confusion. A result from one deep trajectory is compared to a result from many independent shallow trajectories, even though the operational and safety implications differ.

Budget-tier inequality. Institutions with larger inference budgets can buy deeper search, stronger verification, and more attempts, creating a capability gap that a public leaderboard may hide.

Safety under-elicitation. A dangerous capability appears absent because the evaluator used a budget, scaffold, or feedback condition weaker than what a motivated adversary or automated agent could use.

Evaluation Receipt

An inference-budget evaluation receipt should record: model snapshot, scaffold, system prompt, tools, benchmark task set, scoring rule, judge model if any, token budget, whether reasoning tokens are counted, context-compaction trigger, submission cap, feedback condition, timeout, repetition guard, number of trajectories, serial-depth rule, parallel-width rule, pass@k method, task subsampling, excluded costs, latency or wall-clock limits, tool-execution costs, judge costs, human-review costs, and whether performance is still rising at the tested cap.

The receipt should also identify the decision it supports. A score used for marketing, procurement, safety review, release gating, post-deployment monitoring, or regulatory compliance needs different evidence. The audit-grade sentence is not "the model scored X." It is: under this protocol and this compute allocation, the model reached this point on this curve, and that curve was used for this decision.

Source Discipline

This article treats McFadyen, Jorgensen, Coppock, Wei, and Ududec's paper as a June 2026 arXiv preprint and reads its quantitative results as paper-reported controlled experiments. The paper is strongest as a protocol lesson: benchmark scores depend on inference-time compute and allocation. It should not be cited as proof that one benchmark, model, or provider is generally better or safer outside the tested protocol.

NIST sources are used for evaluation context: TEVV, measurement science, and voluntary risk-management framing. They do not prescribe this paper's specific budget protocol. EUR-Lex is used for the operative EU AI Act legal text; Article 55 supports the general importance of standardized model evaluation and documented adversarial testing for systemic-risk GPAI models, not a legal requirement to publish every compute curve.

Benchmark names in this essay come from the arXiv paper. The page does not independently validate TerminalBench, SWE-Bench Pro, FrontierMath, HealthBench, Humanity's Last Exam, Cyber CTFs, or The Last Ones beyond the paper's stated use of them. For any deployment claim, the source hierarchy should separate benchmark protocol, scaffold implementation, model snapshot, run logs, judge rubric, verifier output, cost record, and public summary.

Sources

Return to Blog