StopLoss interrompt les exécutions condamnées des agents de codage et économise jusqu'à 48% des coûts

Les agents de codage s'obstinent à retoucher des solutions qui échoueront de toute façon à la vérification, et chaque étape superflue se paie en tokens. Confier cette surveillance à un modèle frontier se heurte au même problème : le surveillant coûte lui-même cher. Les auteurs de StopLoss proposent un petit moniteur externe qui lit les dernières étapes de l'agent et arrête l'exécution à temps. Sur SWE-bench Verified, il réduit de 4,5% le coût par solution conservée tout en préservant 99% des exécutions réussies. Sur le sous-ensemble SWE-bench Pro, plus coûteux, l'économie atteint 31%, et jusqu'à 48% avec Qwen3-8B comme modèle de base.

Comment fonctionne le moniteur

Le nom vient de l'ordre stop-loss boursier : la position se clôture automatiquement lorsque la perte devient plus probable que le gain. Ici, la « position » est une exécution de l'agent. Le moniteur décide d'avorter l'exécution lorsque l'estimation du risque d'échec dépasse un seuil.

L'entraînement s'appuie sur des trajectoires déjà terminées et sur les verdicts du vérificateur. Le résultat global de l'exécution, succès ou échec, est attribué à des fenêtres locales antérieures : les derniers appels d'outils. On obtient ainsi un jeu d'entraînement sans annotation manuelle. Un modèle de langage affiné évalue une telle fenêtre en une seule passe avant, sans longs raisonnements et sans génération de texte. Le seuil est calibré sur les exécutions réussies, afin de ne pas interrompre celles qui auraient abouti à une solution. L'agent exécuteur reste intact : le moniteur se branche de l'extérieur et n'exige de modifier ni l'agent ni ses prompts.

Le modèle a été entraîné sur des trajectoires de la famille GPT issues de SWE-rebench. Il a été évalué sur SWE-bench Verified et sur un sous-ensemble de SWE-bench Pro, avec des agents exécuteurs GPT comme Claude. La base de comparaison est formée de six LLM-juges généralistes, auxquels on a fourni exactement les mêmes fenêtres.

Ce que montrent les mesures

Chez les juges généralistes, la prédiction d'échec dès la première vérification est proche du hasard. L'entraînement sur les issues des exécutions la transforme en signal utile. De plus, chaque vérification coûte un à deux ordres de grandeur de moins que chez n'importe lequel des juges testés. C'est ce qui rend l'arrêt précoce économiquement pertinent : si la vérification elle-même coûte cher, elle absorbe le gain des exécutions interrompues.

• Coût par solution conservée sur Verified : −4,5% par rapport à l'exécution de toutes les tâches jusqu'au bout, avec 99% des exécutions réussies préservées.
• Sur le sous-ensemble Pro : jusqu'à −31%, et jusqu'à −48% avec Qwen3-8B comme base.
• Coût de la vérification : un à deux ordres de grandeur de moins que chacun des six juges.
• Dans les quatre configurations, le coût par solution conservée de StopLoss est inférieur à celui de toute politique à base de juges.
• L'agent exécuteur ne change pas, et le seuil se règle à partir des exécutions réussies.

L'écart entre les benchmarks est révélateur. Sur Verified, les tâches coûtent moins cher et il y a presque rien à économiser : 4,5% reste un chiffre modeste. Sur Pro, où une exécution ratée coûte nettement plus cher, interrompre les échecs rapporte davantage. L'effet croît avec le prix de l'erreur.

À quoi cela sert en pratique

La métrique « coût par solution conservée » est plus utile que le coût d'une exécution. Elle tient compte à la fois des tokens économisés et des succès perdus à cause de faux arrêts. Les équipes qui font tourner des agents en masse, par exemple pour la correction automatique de bugs en CI, ont intérêt à suivre précisément cette métrique.

L'approche n'exige aucun accès aux entrailles de l'agent exécuteur et s'appuie sur des données que la plupart des équipes possèdent déjà : logs de trajectoires et résultats de tests. Un petit moniteur peut être affiné sur ses propres exécutions, avec un seuil réglé sur la part de succès perdus jugée acceptable. Dans l'étude, elle est de 1% sur Verified.

Il y a aussi des limites. Les résultats proviennent de deux benchmarks d'ingénierie logicielle, et les trajectoires d'entraînement relèvent de la famille GPT. L'article ne montre pas comment le moniteur se comporterait sur une charge de travail d'un autre domaine ni avec d'autres harnais agentiques. Reste que l'idée est limpide : si l'on peut repérer un échec à moindre coût, inutile d'attendre la fin de l'exécution.