Anthropic demuestra que la configuración de la infraestructura mueve 6 p. p. las puntuaciones de Terminal-Bench

La infraestructura puede mover varios puntos porcentuales el resultado de un benchmark agéntico de programación, y a veces más de lo que separa a los líderes de la tabla. Es la conclusión de los ingenieros de Anthropic tras ejecutar Terminal-Bench 2.0 en seis configuraciones de recursos. Entre el ajuste más estricto y el más generoso, la diferencia fue de 6 p. p. con p < 0,01. El modelo, el arnés y el conjunto de tareas se mantuvieron sin cambios.

Cómo se detectó el problema

Anthropic ejecuta Terminal-Bench 2.0 en un clúster de Google Kubernetes Engine. Durante la calibración, el equipo observó que las puntuaciones no coincidían con las del leaderboard oficial y que la proporción de errores de infraestructura era inesperadamente alta: hasta el 6% de las tareas fallaba por caídas de pods que no tenían relación alguna con las capacidades del modelo.

La causa estaba en la forma de aplicar los límites. La implementación sobre Kubernetes trataba los recursos recomendados de cada tarea a la vez como mínimo garantizado y como techo rígido. El contenedor recibía exactamente la memoria indicada y moría ante el menor exceso. Un pico breve de consumo provocaba un OOM-kill, aunque la tarea podría haber terminado con éxito. El proveedor de sandboxes que usa el leaderboard de Terminal-Bench es más permisivo: tolera excesos temporales y no mata el contenedor.

Qué mostraron los experimentos

Los autores ejecutaron el benchmark desde el cumplimiento estricto de las especificaciones (1x) hasta la ausencia total de límites. Las cifras clave:

• la proporción de errores de infraestructura baja de forma monótona: del 5,8% con 1x al 0,5% sin restricciones;
• pasar de 1x a 3x reduce los errores del 5,8% al 2,1% (p < 0,001);
• en el rango de 1x a 3x, la tasa de éxito oscila dentro del margen de ruido (p = 0,40);
• por encima de 3x, el éxito crece más rápido de lo que disminuyen los errores: otros −1,6 p. p. de errores se traducen en casi +4 p. p. de éxito;
• la mejora total sin límites respecto a 1x es de +6 p. p. (p < 0,01);
• en SWE-bench (227 tareas, 10 muestras por tarea, RAM hasta 5x) la mejora es de apenas 1,54 p. p.

Hasta la marca de 3x, los recursos adicionales corrigen la inestabilidad: el benchmark se vuelve más fiable, pero no más fácil. Por encima, el agente empieza a resolver lo que antes no podía: instala dependencias pesadas, lanza subprocesos costosos y ejecuta tests que consumen muchos recursos. Las tareas que más mejoraron fueron rstan-to-pystan y compile-compcert.

Qué mide realmente el benchmark

Los límites ajustados premian las estrategias frugales; los generosos, los enfoques de fuerza bruta. Un ejemplo es la tarea bn-fit-modify, que consiste en ajustar una red bayesiana. Algunos modelos instalan de inmediato pandas, networkx y scikit-learn. Con límites generosos funciona; con límites estrictos, el pod cae por falta de memoria ya durante la instalación. Existe también un camino ligero: implementar las matemáticas con la biblioteca estándar, y algunos modelos eligen precisamente ese. La configuración de recursos decide qué hábito resulta ganador.

El efecto se reprodujo en distintos modelos de Anthropic, aunque su magnitud varió. En otras familias la tendencia aparentemente se mantiene, pero no se ha comprobado de forma rigurosa. Hay además factores menos estudiados: Anthropic observó, de manera anecdótica, variaciones en la tasa de aprobación según la hora del día, probablemente por latencias de la API.

Conclusiones prácticas

Los autores recomiendan fijar para cada tarea dos parámetros, el volumen garantizado y el umbral a partir del cual se mata el contenedor, en lugar de un único valor. El margen entre ambos debe calibrarse de modo que las puntuaciones en el límite inferior y en el superior difieran solo dentro del ruido. En Terminal-Bench 2.0, un techo de 3x recortó los errores de infraestructura en aproximadamente dos tercios y apenas infló el resultado. El multiplicador debe publicarse junto con los resultados.

Para quienes leen leaderboards, la conclusión es directa: una ventaja inferior a 3 p. p. sin configuración documentada merece escepticismo. La dispersión en el rango moderado de recursos es algo inferior a 2 p. p. y se solapa con los intervalos de confianza binomiales habituales de 1–2 p. p., mientras que en los extremos del rango alcanza 6. Los laboratorios deberían tratar los recursos como una variable experimental de pleno derecho, igual que el formato del prompt y la temperatura. Los mantenedores de benchmarks, por su parte, deberían publicar no solo las especificaciones recomendadas, sino también la metodología para aplicarlas. De lo contrario, un liderazgo de un par de puntos puede significar simplemente una máquina virtual más potente.