Anthropic mostra que a configuração de infraestrutura desloca a pontuação do Terminal-Bench em 6 p.p.

A infraestrutura pode deslocar o resultado de um benchmark agêntico de programação em vários pontos percentuais, às vezes mais do que a distância que separa os líderes da tabela. Essa é a conclusão de engenheiros da Anthropic, que rodaram o Terminal-Bench 2.0 em seis configurações de recursos. Entre a configuração mais rígida e a mais generosa, a diferença foi de 6 p.p., com p < 0,01. O modelo, o harness e o conjunto de tarefas permaneceram os mesmos.

Como o problema foi descoberto

A Anthropic executa o Terminal-Bench 2.0 em um cluster do Google Kubernetes Engine. Durante a calibração, a equipe notou que as pontuações não batiam com o leaderboard oficial e que a taxa de erros de infraestrutura era inesperadamente alta: até 6% das tarefas falhavam por problemas nos pods, sem nenhuma relação com a capacidade do modelo.

A causa estava na forma de aplicar os limites. A implementação em Kubernetes tratava os recursos recomendados para a tarefa ao mesmo tempo como mínimo garantido e como teto rígido. O contêiner recebia exatamente a quantidade de memória especificada e era encerrado ao menor excesso. Um pico momentâneo de consumo causava um OOM-kill, embora a tarefa pudesse ter sido concluída com sucesso. O provedor de sandboxes usado pelo leaderboard do Terminal-Bench é mais tolerante: admite excessos temporários e não mata o contêiner.

O que os experimentos mostraram

Os autores rodaram o benchmark desde o cumprimento estrito das especificações (1x) até a ausência total de limites. Os principais números:

• a taxa de erros de infraestrutura cai de forma monotônica: de 5,8% com 1x para 0,5% sem restrições;
• a passagem de 1x para 3x reduz os erros de 5,8% para 2,1% (p < 0,001);
• na faixa de 1x a 3x, a taxa de sucesso oscila dentro do ruído (p = 0,40);
• acima de 3x, o sucesso cresce mais rápido do que os erros diminuem: mais −1,6 p.p. de erros rendem quase +4 p.p. de sucesso;
• o ganho total sem limites em relação a 1x é de +6 p.p. (p < 0,01);
• no SWE-bench (227 tarefas, 10 amostras cada, RAM até 5x), o ganho é de apenas 1,54 p.p.

Até a marca de 3x, os recursos extras corrigem a instabilidade: o benchmark fica mais confiável, mas não mais fácil. Acima disso, o agente passa a resolver o que antes não conseguia: puxa dependências pesadas, lança subprocessos caros e executa testes que consomem muitos recursos. As tarefas que mais cresceram foram rstan-to-pystan e compile-compcert.

O que o benchmark realmente mede

Limites apertados premiam estratégias econômicas; limites folgados favorecem abordagens de força bruta. Um exemplo é a tarefa bn-fit-modify, de ajuste de uma rede bayesiana. Alguns modelos instalam de imediato pandas, networkx e scikit-learn. Com limites generosos, isso funciona; com limites rígidos, o pod cai por falta de memória já na instalação. Existe também um caminho leve: implementar a matemática com a biblioteca padrão, e alguns modelos escolhem justamente esse. A configuração de recursos decide qual hábito sai vencedor.

O efeito se repetiu em diferentes modelos da Anthropic, embora a magnitude tenha variado. Em outras famílias de modelos, a tendência aparentemente se mantém, mas isso não foi verificado de forma rigorosa. Há ainda fatores menos estudados: a Anthropic observou, de modo anedótico, oscilações na taxa de aprovação conforme o horário do dia, provavelmente por causa de latências de API.

Conclusões práticas

Os autores recomendam definir dois parâmetros para cada tarefa, o volume garantido e o limite para matar o contêiner, em vez de um único valor. A folga deve ser calibrada de modo que as pontuações nos limites inferior e superior difiram apenas dentro do ruído. No Terminal-Bench 2.0, um teto de 3x cortou os erros de infraestrutura em cerca de dois terços e quase não inflou o resultado. O multiplicador deve ser publicado junto com os resultados.

Para quem lê leaderboards, a conclusão é direta: uma vantagem de menos de 3 p.p. sem configuração documentada merece ceticismo. A variação na faixa moderada de recursos é de pouco menos de 2 p.p. e se soma aos intervalos de confiança binomiais usuais, de 1–2 p.p.; nos extremos da faixa, chega a 6. Os laboratórios devem tratar os recursos como uma variável experimental de pleno direito, no mesmo nível do formato do prompt e da temperatura. Os mantenedores de benchmarks devem publicar não só as especificações recomendadas, mas também a metodologia para aplicá-las. Caso contrário, uma liderança de dois pontos pode significar apenas uma máquina virtual mais potente.