Anthropic montre que la configuration de l'infrastructure fait varier les scores de Terminal-Bench de 6 points de pourcentage

L'infrastructure peut déplacer le résultat d'un benchmark de code agentique de plusieurs points de pourcentage, parfois plus que l'écart qui sépare les leaders d'un classement. C'est la conclusion des ingénieurs d'Anthropic, qui ont exécuté Terminal-Bench 2.0 dans six configurations de ressources. Entre le réglage le plus strict et le plus généreux, l'écart atteint 6 points de pourcentage avec p < 0,01. Le modèle, le harnais et le jeu de tâches sont pourtant restés identiques.

Comment le problème a été repéré

Anthropic exécute Terminal-Bench 2.0 sur un cluster Google Kubernetes Engine. Lors de la calibration, l'équipe a constaté que ses scores ne correspondaient pas au classement officiel et que la part d'erreurs d'infrastructure était étonnamment élevée : jusqu'à 6 % des tâches échouaient à cause de pannes de pods sans aucun lien avec les capacités du modèle.

La cause tenait à la manière d'appliquer les limites. L'implémentation sur Kubernetes traitait les ressources recommandées pour une tâche à la fois comme un minimum garanti et comme un plafond strict. Le conteneur recevait exactement la mémoire indiquée et était tué au moindre dépassement. Un pic de consommation ponctuel déclenchait un OOM-kill, alors que la tâche aurait pu aboutir. Le fournisseur de sandboxes utilisé par le classement Terminal-Bench est plus tolérant : il admet un dépassement temporaire et ne tue pas le conteneur.

Ce que montrent les expériences

Les auteurs ont exécuté le benchmark depuis le strict respect des spécifications (1x) jusqu'à l'absence totale de limites. Les chiffres clés :

• la part d'erreurs d'infrastructure baisse de façon monotone : de 5,8 % à 1x à 0,5 % sans restriction ;
• le passage de 1x à 3x fait chuter les erreurs de 5,8 % à 2,1 % (p < 0,001) ;
• dans la plage 1x–3x, le taux de réussite fluctue dans la marge de bruit (p = 0,40) ;
• au-delà de 3x, le taux de réussite progresse plus vite que les erreurs ne reculent : 1,6 point de pourcentage d'erreurs en moins donne près de +4 points de pourcentage de réussite ;
• le gain total sans limites par rapport à 1x est de +6 points de pourcentage (p < 0,01) ;
• sur SWE-bench (227 tâches, 10 échantillons chacune, RAM jusqu'à 5x), le gain n'est que de 1,54 point de pourcentage.

Jusqu'à 3x, les ressources supplémentaires corrigent l'instabilité : le benchmark devient plus fiable, mais pas plus facile. Au-delà, l'agent se met à résoudre ce qu'il ne pouvait pas résoudre avant : il installe des dépendances lourdes, lance des sous-processus coûteux, exécute des tests gourmands en ressources. Les tâches rstan-to-pystan et compile-compcert sont celles qui progressent le plus nettement.

Ce que mesure réellement le benchmark

Des limites serrées récompensent les stratégies économes, des limites généreuses celles qui misent sur la force brute. Exemple : la tâche bn-fit-modify, qui consiste à ajuster un réseau bayésien. Certains modèles installent d'emblée pandas, networkx et scikit-learn. Avec des limites généreuses, cela fonctionne ; avec des limites strictes, le pod tombe faute de mémoire dès l'installation. Il existe aussi une voie légère : implémenter les calculs avec la bibliothèque standard, et certains modèles choisissent justement celle-ci. La configuration des ressources décide quelle habitude sera payante.

L'effet s'est reproduit sur différents modèles d'Anthropic, avec une ampleur variable. Sur d'autres familles de modèles, la tendance semble se maintenir, mais cela n'a pas été vérifié rigoureusement. D'autres facteurs sont moins bien étudiés : Anthropic a aussi constaté, de façon anecdotique, des variations du taux de réussite selon l'heure de la journée, probablement en raison de la latence de l'API.

Conclusions pratiques

Les auteurs recommandent de définir pour chaque tâche deux paramètres, le volume garanti et le seuil d'arrêt du conteneur, plutôt qu'une valeur unique. L'écart doit être calibré de façon que les scores aux bornes basse et haute diffèrent dans la marge de bruit. Pour Terminal-Bench 2.0, un plafond à 3x a réduit les erreurs d'infrastructure d'environ deux tiers sans gonfler sensiblement le résultat. Le multiplicateur doit être publié avec les résultats.

Pour ceux qui lisent les classements, la conclusion est directe : un écart inférieur à 3 points de pourcentage, sans configuration documentée, mérite du scepticisme. La dispersion dans une plage de ressources modérée est légèrement inférieure à 2 points de pourcentage et se superpose aux intervalles de confiance binomiaux habituels de 1 à 2 points de pourcentage ; aux extrémités de la plage, elle atteint 6. Les laboratoires devraient traiter les ressources comme une variable expérimentale à part entière, au même titre que le format du prompt et la température.

Les mainteneurs de benchmarks devraient publier non seulement les spécifications recommandées, mais aussi la méthode pour les appliquer. Sinon, une avance de quelques points peut simplement signifier une machine virtuelle plus puissante.