Quantifying infrastructure noise in agentic coding evals

Agentic coding benchmarks like SWE-bench and Terminal-Bench are commonly used to compare the software engineering capabilities of frontier models—with top spots on leaderboards often separated by just a few percentage points. These scores are often treated as precise measurements of relative model capability and increasingly inform decisions about which models to deploy. However, we’ve found that infrastructure configuration alone can produce differences that exceed those margins. In internal experiments, the gap between the most- and least-resourced setups on Terminal-Bench 2.0 was 6 percentage points (p < 0.01).

Агентные бенчмарки программирования, такие как SWE-bench и Terminal-Bench, широко используются для сравнения возможностей передовых моделей в области программной инженерии — при этом лидеры таблиц зачастую разделены лишь несколькими процентными пунктами. Эти баллы нередко воспринимаются как точные измерения относительных возможностей моделей и всё чаще влияют на решения о том, какие модели использовать в продакшене. Однако мы обнаружили, что одна лишь конфигурация инфраструктуры способна порождать различия, превышающие эти отрывы. В наших внутренних экспериментах разрыв между конфигурациями с наибольшим и наименьшим объёмом ресурсов на Terminal-Bench 2.0 составил 6 процентных пунктов (p < 0.01).

Static benchmarks score a model's output directly—the runtime environment doesn’t factor into the result. Agentic coding evals are different: models are given a full environment where they write programs, run tests, install dependencies, and iterate over multiple turns. The runtime is no longer a passive container, but an integral component of the problem-solving process. Two agents with different resource budgets and time limits aren't taking the same test.

Статические бенчмарки оценивают выход модели напрямую — среда выполнения не влияет на результат. С агентными бенчмарками всё иначе: модели получают полноценную среду, в которой пишут программы, запускают тесты, устанавливают зависимости и итерируют на протяжении нескольких ходов. Среда выполнения перестаёт быть пассивным контейнером и становится неотъемлемой частью процесса решения задач. Два агента с разными бюджетами ресурсов и временны́ми лимитами сдают разные экзамены.

Eval developers have begun accounting for this. Terminal-Bench 2.0, for instance, specifies recommended CPU and RAM on a per-task basis in their latest 2.0 release. However, specifying resources isn't the same as enforcing them consistently. Moreover, we discovered that enforcement methodology can change what the benchmark ends up actually measuring.

Разработчики бенчмарков начали это учитывать. Например, Terminal-Bench 2.0 в последнем релизе указывает рекомендуемые значения CPU и RAM для каждой задачи. Однако указать ресурсы — не то же самое, что обеспечить их единообразное применение. Более того, мы выяснили, что сама методология применения ограничений может менять то, что бенчмарк в действительности измеряет.

How we got here

Как мы к этому пришли

We run Terminal-Bench 2.0 on a Google Kubernetes Engine cluster. While calibrating the setup, we noticed our scores didn't match the benchmark’s official leaderboard, and infra error rates were surprisingly high: as many as 6% of tasks were failing because of pod errors, most of which were unrelated to the model’s ability to solve the tasks.

Мы запускаем Terminal-Bench 2.0 на кластере Google Kubernetes Engine. В процессе калибровки мы заметили, что наши баллы не совпадают с официальной таблицей лидеров, а доля инфраструктурных ошибок оказалась неожиданно высокой: до 6 % задач падали из-за ошибок подов, большинство из которых не имели отношения к способности модели решать задачи.

The discrepancy in scores came down to enforcement. Our Kubernetes implementation treated the per-task resource specs as both a floor and a hard ceiling: each container was guaranteed the specified resources but killed the moment it exceeded them. Container runtimes enforce resources via two separate parameters: a guaranteed allocation—the resources reserved up front—and a hard limit at which the container is killed. When these are set to the same value, there's zero headroom for transient spikes: a momentary memory fluctuation can OOM-kill a container that would otherwise have succeeded. To account for this, Terminal-Bench’s leaderboard uses a different sandboxing provider, whose implementation is more lenient, allowing temporary overallocation without terminating the container in order to favor infrastructural stability.

Расхождение в баллах объяснялось способом применения ограничений. Наша реализация на Kubernetes трактовала спецификации ресурсов для каждой задачи одновременно как нижний порог и жёсткий потолок: контейнеру гарантировался указанный объём ресурсов, но при превышении он немедленно уничтожался. Среды выполнения контейнеров задают ресурсы через два отдельных параметра: гарантированное выделение — ресурсы, зарезервированные заранее, — и жёсткий лимит, при превышении которого контейнер уничтожается. Когда оба параметра равны, запаса на кратковременные всплески нет: мгновенный скачок потребления памяти может вызвать OOM-kill контейнера, который в ином случае завершился бы успешно. Чтобы это компенсировать, таблица лидеров Terminal-Bench использует другого провайдера песочниц, чья реализация мягче: она допускает временное превышение лимитов без уничтожения контейнера, отдавая приоритет стабильности инфраструктуры.

This finding raised a larger question: how much does resource configuration impact evaluation scores?

Этот результат поставил более масштабный вопрос: насколько конфигурация ресурсов влияет на оценки бенчмарков?

To quantify the effect of the scaffold, we ran Terminal-Bench 2.0 across six resource configurations, from strict enforcement of the per-task specs (1x), having them act as both floor and ceiling, to completely uncapped. Everything else stayed constant: same Claude model, same harness, same task set.

Чтобы количественно оценить влияние инфраструктуры, мы запустили Terminal-Bench 2.0 в шести конфигурациях ресурсов — от строгого применения спецификаций для каждой задачи (1×), где они выступают одновременно нижним порогом и потолком, до полностью неограниченного режима. Всё остальное оставалось неизменным: та же модель Claude, тот же каркас, тот же набор задач.

In our experiments, success rates increased with resource headroom. This was primarily driven by infra error rates dropping monotonically at each step, going from 5.8% at strict enforcement to 0.5% when uncapped. The drop between strict enforcement to 3x headroom (5.8% to 2.1%) was significant at p < 0.001. With more headroom, fewer containers get killed for exceeding their allocation.

В наших экспериментах доля успешных решений росла вместе с запасом ресурсов. Это в первую очередь объяснялось монотонным снижением доли инфраструктурных ошибок на каждом шаге — с 5,8 % при строгом ограничении до 0,5 % в неограниченном режиме. Падение между строгим ограничением и запасом 3× (с 5,8 % до 2,1 %) было статистически значимым при p < 0.001. Чем больше запас, тем меньше контейнеров уничтожается за превышение выделенных ресурсов.

From 1x through 3x, success scores fluctuate within the margins of noise (p=0.40). Most of the tasks that were crashing at 1x would have failed regardless—which is something that we observed in the data. The agent explores, hits a resource wall, and gets preempted, but it was never on a path to a correct solution.

В диапазоне от 1× до 3× баллы успешности колеблются в пределах шума (p = 0.40). Большинство задач, падавших при 1×, провалились бы в любом случае — мы наблюдали это в данных. Агент исследует, упирается в ресурсное ограничение и вытесняется, но он и не был на пути к правильному решению.

Starting around 3x, however, this trend changes: success rates climb faster than infra errors decline.

Однако начиная примерно с 3× эта тенденция меняется: доля успешных решений растёт быстрее, чем снижается доля инфраструктурных ошибок.

Between 3x to uncapped, infra errors drop an additional 1.6 percentage points, while success jumps almost 4 percentage points. The extra resources enable the agent to try approaches that only work with generous allocations, such as pulling in large dependencies, spawning expensive subprocesses, and running memory-intensive test suites. At uncapped resources, the total lift over 1x is +6 percentage points (p < 0.01). At the margins, tasks like rstan-to-pystan and compile-compcert significantly improve their success rates when getting memory headroom.

В диапазоне от 3× до неограниченного режима инфраструктурные ошибки снижаются ещё на 1,6 процентного пункта, тогда как доля успешных решений подскакивает почти на 4 процентных пункта. Дополнительные ресурсы позволяют агенту пробовать подходы, которые работают только при щедром выделении: подтягивать тяжёлые зависимости, запускать ресурсоёмкие подпроцессы, прогонять требовательные к памяти наборы тестов. При неограниченных ресурсах суммарный прирост относительно 1× составляет +6 процентных пунктов (p < 0.01). На границе возможностей задачи вроде rstan-to-pystan и compile-compcert значительно повышают долю успеха при увеличении запаса памяти.

How this affects measurement

Как это влияет на измерения

Up to roughly 3x Terminal-Bench specs, the additional resources fix infrastructure reliability problems, namely transient resource spikes. The sandboxing provider used by the Terminal-Bench maintainers is implicitly doing this behind the scenes; the eval gets more stable without getting easier.

Примерно до 3× от спецификаций Terminal-Bench дополнительные ресурсы устраняют проблемы надёжности инфраструктуры, а именно — кратковременные всплески потребления ресурсов. Провайдер песочниц, которым пользуются разработчики Terminal-Bench, делает это неявно за кулисами: бенчмарк становится стабильнее, но не проще.

Above the 3x mark, however, additional resources start actively helping the agent solve problems it couldn't solve before, which shows that limits can actually change what the eval measures. Tight limits inadvertently reward very efficient strategies, while generous limits are more forgiving and reward agents that can better exploit all available resources.

Однако выше отметки 3× дополнительные ресурсы начинают активно помогать агенту решать задачи, которые он не мог решить раньше, а значит, лимиты фактически меняют то, что измеряет бенчмарк. Жёсткие ограничения непреднамеренно вознаграждают крайне эффективные стратегии, тогда как щедрые лимиты более снисходительны и поощряют агентов, способных лучше использовать все доступные ресурсы.

An agent that writes lean, efficient code very fast will do well under tight constraints. An agent that brute-forces solutions with heavyweight tools will do well under generous ones. Both are legitimate things to test, but collapsing them into a single score without specifying the resource configuration makes the differences—and real-world generalizability—hard to interpret.

Агент, который пишет компактный, эффективный код очень быстро, покажет хорошие результаты при жёстких ограничениях. Агент, который «ломит» решения тяжёлыми инструментами, преуспеет при щедрых лимитах. Оба подхода — вполне легитимные объекты тестирования, но если свести их в единый балл без указания конфигурации ресурсов, различия — а вместе с ними и применимость к реальным задачам — становится трудно интерпретировать.

On bn-fit-modify, a Terminal-Bench task requiring Bayesian network fitting, some models’ first move is to install the standard Python data science stack: pandas, networkx, scikit-learn, and all their toolchain. Under generous limits, this works. Under tight ones, the pod runs out of memory during installation, before the agent writes a single line of solution code. A leaner strategy exists (implementing the math from scratch using only the standard library), and some models do default to it. Others don’t. Different models have different default approaches, and the resource configuration determines which of those approaches happen to succeed.We replicated the core finding across different Anthropic models. The direction of the effect was consistent, while the magnitude varied. The same trends seem to hold on models other than Claude, but we haven’t rigorously tested them.

В задаче bn-fit-modify из Terminal-Bench, требующей подгонки байесовской сети, первым шагом некоторых моделей является установка стандартного стека для Data Science на Python: pandas, networkx, scikit-learn и все их зависимости. При щедрых лимитах это работает. При жёстких — под исчерпывает память ещё на этапе установки, до того как агент напишет хоть одну строку кода решения. Более экономная стратегия существует (реализовать математику с нуля, используя только стандартную библиотеку), и некоторые модели по умолчанию выбирают именно её. Другие — нет. У разных моделей разные подходы по умолчанию, и конфигурация ресурсов определяет, какие из этих подходов оказываются успешными. Мы воспроизвели основной результат на разных моделях Anthropic. Направление эффекта было одинаковым, а величина варьировалась. Те же тенденции, по-видимому, справедливы и для моделей, отличных от Claude, но мы не проводили их строгого тестирования.

We also tested whether this pattern holds on evals outside Terminal-Bench by running a crossover experiment on SWE-bench. We varied the total available RAM up to 5x the baseline across 227 problems with 10 samples each. The same effect held, though the magnitude was smaller: Scores again increased monotonically with RAM, but were only 1.54 percentage points higher at 5x than 1x. SWE-bench tasks are less resource-intensive, so a smaller effect is expected, but it shows resource allocation isn't neutral there either.

Мы также проверили, сохраняется ли этот паттерн на бенчмарках за пределами Terminal-Bench, проведя перекрёстный эксперимент на SWE-bench. Мы варьировали общий объём доступной оперативной памяти до 5× от базового значения на 227 задачах с 10 запусками каждая. Эффект подтвердился, хотя его величина оказалась меньше: баллы снова монотонно росли с увеличением RAM, но при 5× были лишь на 1,54 процентного пункта выше, чем при 1×. Задачи SWE-bench менее ресурсоёмки, поэтому меньший эффект ожидаем, но это показывает, что выделение ресурсов не является нейтральным и здесь.

Other sources of variance

Другие источники дисперсии

Resource allocation isn't the only hidden variable. In certain configurations, time limits too start playing a role.

Выделение ресурсов — не единственная скрытая переменная. В определённых конфигурациях свою роль начинают играть и временны́е лимиты.

In principle, every element of the evaluation setup can influence the final score, from the cluster health to the hardware specs, from the concurrency level to even egress bandwidth. Agentic evals are end-to-end system tests by construction, and any component of that system can act as a confounder. We have observed anecdotally, for instance, that pass rates fluctuate with time of day, likely because API latency varies with traffic patterns and incidents. We have not formally quantified this effect, but it illustrates a larger point: the boundary between "model capability" and "infrastructure behavior" is blurrier than a single benchmark score suggests. A model provider can shield its eval infrastructure from this by dedicating hardware, but external evaluators can't easily do the same.

В принципе, каждый элемент инфраструктуры оценки может влиять на итоговый балл — от состояния кластера до характеристик оборудования, от уровня параллелизма до пропускной способности исходящего трафика. Агентные бенчмарки по своей природе представляют собой сквозные системные тесты, и любой компонент такой системы может выступать в роли вмешивающегося фактора. Мы, к примеру, наблюдали на практике, что доля успешных прохождений колеблется в зависимости от времени суток — вероятно, из-за того что задержки API варьируются с паттернами трафика и инцидентами. Мы формально не квантифицировали этот эффект, но он иллюстрирует более широкий тезис: граница между «возможностями модели» и «поведением инфраструктуры» размыта куда сильнее, чем подразумевает единый балл бенчмарка. Провайдер моделей может защитить свою инфраструктуру оценки от этого, выделив под неё отдельное оборудование, но сторонним оценщикам это сделать непросто.

Public benchmarks are typically meant to measure pure model capabilities, but in practice they risk conflating them with infrastructure quirks. Sometimes this may be desirable, as it enables end-to-end testing of the entire stack, but more often it's not. For coding evals meant to be shared publicly, running at multiple times and on multiple days would help average out the noise.

Публичные бенчмарки, как правило, призваны измерять чистые возможности модели, но на практике рискуют смешивать их с инфраструктурными артефактами. Иногда это может быть желательно, поскольку позволяет проводить сквозное тестирование всего стека, но чаще — нет. Для бенчмарков программирования, предназначенных для публичного использования, проведение тестов в разное время и в разные дни помогло бы усреднить шум.

What we recommend

Наши рекомендации

The ideal scenario is to run each eval under the exact same hardware conditions—both the scaffold running the eval and the inference stack—as it would ensure perfect reproducibility across the board. However, this may not always be practical.

Идеальный сценарий — запускать каждый бенчмарк в абсолютно одинаковых аппаратных условиях, включая как каркас, исполняющий бенчмарк, так и стек инференса, что обеспечило бы полную воспроизводимость. Однако на практике это не всегда осуществимо.

Given how container runtimes actually enforce resources—via a guaranteed allocation and a separate hard kill threshold—we recommend that evals specify both parameters per task, not a single pinned value. A single exact spec sets the guaranteed allocation equal to the kill threshold, leaving zero margin: the transient memory spikes we documented at 1x are enough to destabilize the eval. Separating the two parameters lets you give containers enough breathing room to avoid spurious OOM kills, while still enforcing a hard ceiling that prevents score inflation.

Учитывая, как среды выполнения контейнеров реально управляют ресурсами — через гарантированное выделение и отдельный порог принудительного завершения, — мы рекомендуем, чтобы бенчмарки указывали оба параметра для каждой задачи, а не одно фиксированное значение. Единая точная спецификация приравнивает гарантированное выделение к порогу уничтожения, не оставляя запаса: кратковременных всплесков памяти, которые мы задокументировали при 1×, достаточно, чтобы дестабилизировать бенчмарк. Разделение двух параметров позволяет дать контейнерам достаточно пространства для манёвра, чтобы избежать ложных OOM-kill, сохраняя при этом жёсткий потолок, предотвращающий завышение баллов.

The band between them should be calibrated so that scores at the floor and ceiling fall within noise of each other. For instance, in Terminal-Bench 2.0, a 3x ceiling over the per-task specs cut infra error rates by roughly two-thirds (5.8% to 2.1%, p < 0.001) while keeping the score lift modest and well within noise (p = 0.40). That's a reasonable tradeoff: the infrastructure confounder is largely neutralized without removing meaningful resource pressure. The exact multiplier will vary by benchmark and task distribution, and should thus be reported, but the empirical calibration principle is general.

Зазор между ними следует калибровать так, чтобы баллы при нижнем и верхнем пороге укладывались в пределы шума. Например, в Terminal-Bench 2.0 потолок в 3× от спецификаций для каждой задачи снизил долю инфраструктурных ошибок примерно на две трети (с 5,8 % до 2,1 %, p < 0.001), при этом прирост баллов оставался скромным и вполне в пределах шума (p = 0.40). Это разумный компромисс: инфраструктурный вмешивающийся фактор в значительной мере нейтрализован, а осмысленная ресурсная нагрузка сохранена. Конкретный множитель будет различаться в зависимости от бенчмарка и распределения задач и поэтому должен указываться, но сам принцип эмпирической калибровки универсален.

Why we care

Почему нам это важно

These findings have practical consequences beyond eval infrastructure. Benchmark scores are increasingly used as decision-making inputs, but this increased attention (and reliance) hasn’t always come with corresponding rigor in how they’re run or reported. As things stand today, a 2-point lead on a leaderboard might reflect a genuine capability difference, or it might reflect that one eval ran on beefier hardware, or even at a luckier time of day, or both. Without published (or standardized) setup configurations, it’s hard to tell from the outside unless interested parties go the extra mile to reproduce objective results under identical conditions.

Эти результаты имеют практические последствия за пределами инфраструктуры оценки. Баллы бенчмарков всё чаще используются как входные данные для принятия решений, однако это возросшее внимание (и зависимость) не всегда сопровождается соответствующей строгостью в проведении и документировании тестов. На сегодняшний день преимущество в 2 пункта на таблице лидеров может отражать реальное различие в возможностях — а может означать, что один бенчмарк запускался на более мощном оборудовании, или даже в более удачное время суток, или и то и другое. Без публикации (или стандартизации) конфигураций сетапа извне это трудно определить, если только заинтересованные стороны не приложат дополнительные усилия для воспроизведения объективных результатов в идентичных условиях.

For labs like Anthropic, the implication is that resource configuration for agentic evals should be treated as a first-class experimental variable, documented and controlled with the same rigor as prompt format or sampling temperature. For benchmark maintainers, publishing recommended resource specs (as Terminal-Bench 2.0 does) can go a long way, while specifying enforcement methodology would close the gap we identified. And for anyone consuming benchmark results, the core takeaway is that small score differences on agentic evals carry more uncertainty than the precision of the reported numbers suggests—especially as some confounders are simply too hard to control for.

Для лабораторий вроде Anthropic это означает, что конфигурация ресурсов для агентных бенчмарков должна рассматриваться как полноценная экспериментальная переменная — документироваться и контролироваться с той же строгостью, что формат промпта или температура семплирования. Для разработчиков бенчмарков публикация рекомендуемых спецификаций ресурсов (как это делает Terminal-Bench 2.0) — важный шаг вперёд, а указание методологии применения ограничений закрыло бы выявленный нами пробел. А для всех, кто использует результаты бенчмарков, ключевой вывод таков: небольшие различия в баллах агентных бенчмарков несут в себе больше неопределённости, чем подразумевает точность представленных чисел — особенно с учётом того, что некоторые вмешивающиеся факторы просто слишком сложно контролировать.

Until resource methodology is standardized, our data suggests that leaderboard differences below 3 percentage points deserve skepticism until the eval configuration is documented and matched. The observed spread across the moderate range of resource configurations in Terminal-Bench is just below 2 percentage points. Naive binomial confidence intervals already span 1-2 percentage points; the infrastructure confounders we document here stack on top of that, not within it. At the extremes of the allocation range, the spread reaches 6.

Пока методология ресурсного обеспечения не стандартизирована, наши данные свидетельствуют, что различия на таблицах лидеров менее 3 процентных пунктов заслуживают скептицизма до тех пор, пока конфигурация бенчмарка не задокументирована и не выровнена. Наблюдаемый разброс в умеренном диапазоне конфигураций ресурсов на Terminal-Bench составляет чуть менее 2 процентных пунктов. Наивные биномиальные доверительные интервалы уже охватывают 1–2 процентных пункта; инфраструктурные вмешивающиеся факторы, которые мы здесь документируем, накладываются поверх этого, а не внутри него. На крайних точках диапазона выделения ресурсов разброс достигает 6 пунктов.

A few-point lead might signal a real capability gap—or it might just be a bigger VM.

Преимущество в несколько пунктов может сигнализировать о реальном разрыве в возможностях — а может быть просто результатом более мощной виртуальной машины.

Acknowledgements

Благодарности

Written by Gian Segato. Special thanks to Nicholas Carlini, Jeremy Hadfield, Mike Merrill, and Alex Shaw for their contributions. This work reflects the collective efforts of several teams working on evaluations for coding agents. Interested candidates who would like to contribute are welcome to apply at anthropic.com/careers.

Автор — Gian Segato. Особая благодарность Nicholas Carlini, Jeremy Hadfield, Mike Merrill и Alex Shaw за их вклад. Эта работа отражает совместные усилия нескольких команд, занимающихся оценкой агентов для программирования. Заинтересованных кандидатов, желающих внести свой вклад, приглашаем подавать заявки на anthropic.com/careers.