Contexte et objectifs

FrontierHarness est une suite d’évaluations destinée aux agents IA exécutant des tâches de génie logiciel en ligne de commande. La version 1.0 se concentre sur des scénarios de codage, de compilation et de débogage, et ne prétend pas couvrir d’autres formes de travail cognitif. L’objectif principal de l’évaluation présentée est de mesurer l’impact du nombre de passages (passes) sur le coût monétaire d’une tâche, en isolant les variables d’infrastructure grâce à un environnement de restauration identique.

Méthodologie d'évaluation

Les tests sont réalisés sur les runtimes Runta. Avant chaque exécution, l’ensemble du harness et du jeu de tâches est sauvegardé comme golden checkpoint. Chaque passage démarre alors à partir d’une restauration complète, garantissant les mêmes vCPU, mémoire, taille de disque, contenu du disque et état de la mémoire. Cette approche élimine les effets de cache persistant ou de dérive d’état entre les runs.

v0.148.0
v0.1.0-rc.8
v2.1.237
v0.84.2
v17.4.0
v0.37.2
v0.1.0
v1.18.19
v0.20.4

Les versions listées ci‑dessus correspondent aux différents harness testés. Elles sont invoquées successivement pour comparer les coûts associés à chaque configuration logicielle.

Analyse des coûts et des performances

Le rapport indique que, lorsqu’on exclut les échecs, le système ne couvre que 15 passes, ce qui conduit à un coût de 3,24 $ par tâche. En incluant les échecs, le nombre de passes passe à 19, et le coût grimpe à 18,34 $ par tâche, soit une multiplication d’environ 17 fois. Cette hausse provient non seulement du nombre supplémentaire de passes, mais aussi de la façon dont les échecs consomment des ressources : un échec de 300 tours en cache peut coûter davantage qu’une simple absence de cache sur un court passage.

Le taux de hit du cache n’est donc pas un indicateur fiable de coût. Un cache qui retient un échec long entraîne un « burn » de ressources comparable à un nouveau calcul complet, alors qu’un cache de courte durée ne génère qu’une perte marginale. Cette dissociation entre qualité (taux de réussite) et coût (ressources consommées) montre que l’optimisation du cache doit être évaluée au niveau granulaire des tours d’exécution.

Limitations et perspectives

Le cadre d’évaluation repose sur un unique type de tâche (logiciel terminal) et sur une infrastructure fixe. La généralisation à d’autres domaines de connaissance ou à des environnements cloud variables n’est pas démontrée. De plus, le rapport ne fournit pas de métriques de latence ou de consommation énergétique, ce qui empêche une comparaison complète avec d’autres benchmarks. Enfin, l’offre de 100 $ de crédits pour tester son propre harness sur Runta indique une incitation commerciale, mais ne précise pas les conditions de facturation au-delà du crédit initial.