LEASH confie les étapes difficiles à l'agent le plus puissant et économise 19,2 % sur Opus 5

Les auteurs de LEASH proposent un moyen d'éviter de faire tourner un modèle coûteux à chaque étape d'un agent computer-use. Un modèle open-weight plus faible agit par défaut. Le modèle puissant n'entre en jeu que lorsque le premier « doute », et il reste sous surveillance après la passation de contrôle. Sur OSWorld, l'association avec Qwen3.5-35B-A3B atteint 73,66 % de tâches réussies pour 0,4117 $ par tâche. Claude Opus 5, utilisé en continu, obtient 72,90 %. Autrement dit, LEASH ne lui cède rien en qualité et revient 19,2 % moins cher.

Le problème : tâches longues et inférence coûteuse

Les agents qui pilotent un ordinateur résolvent des tâches de plusieurs dizaines d'étapes : ouvrir une application, retrouver un fichier, modifier des réglages, vérifier le résultat. Un modèle de pointe appelé à chaque étape fait vite grimper la facture. Un petit modèle open-weight, seul, n'arrive souvent pas au bout. L'escalade du faible vers le fort promet un compromis, mais elle butte sur une question : à quel moment faut-il appeler le modèle puissant ? Pour y répondre, il faut un signal vérifiable à chaque étape pour un coût quasi nul.

Un second problème se pose. L'agent puissant est généralement accessible via une API fermée, si bien qu'on ne peut pas inspecter ses états internes. Même après la passation de contrôle, il peut s'égarer, sans que rien permette de le contrôler.

Comment fonctionnent les trois couches de LEASH

Le framework ne nécessite aucun entraînement et repose sur les états cachés du modèle faible. Les auteurs les comparent à ceux de trajectoires passées, réussies ou ratées. Plus l'état courant ressemble à des états d'échec, plus le score d'incertitude est élevé. L'estimateur réutilise les activations que le modèle calcule de toute façon lorsqu'il génère une action. Il n'a besoin ni d'un forward pass supplémentaire ni d'un moniteur entraîné à part.

Ce signal alimente trois couches :

• l'incertitude initiale sur la tâche : un routage précoce qui détermine si le modèle puissant est nécessaire dès la première étape ;
• l'incertitude à chaque étape : une escalade en cours d'exécution, lorsque l'agent faible commence à « dériver » ;
• l'observateur fantôme : il continue de surveiller l'agent puissant, de type boîte noire, après la passation de contrôle.

Le nom LEASH (« laisse ») résume assez bien l'idée : on lâche l'agent puissant au besoin, mais sans jamais le laisser totalement libre ensuite.

Ce qu'a montré OSWorld

Les expériences ont été menées sur OSWorld avec quatre backbones récents. Voici les résultats, d'après le texte de l'étude :

• LEASH fait systématiquement mieux que les agents faibles utilisés seuls ;
• à proportion égale d'escalades, il devance l'escalade aléatoire de 6,55 à 11,94 points ;
• Qwen3.5-35B-A3B + LEASH : 73,66 % de réussite et 0,4117 $ par tâche ;
• Claude Opus 5 en mode always-on : 72,90 % ;
• économie d'inférence par rapport au mode always-on : 19,2 %.

De ce dernier chiffre, on peut déduire qu'un passage complet sur Opus 5 coûte environ 0,51 $ par tâche. Il s'agit de notre calcul : l'étude ne donne pas ce chiffre dans son résumé. Mieux vaut ne pas surinterpréter un écart de précision de 0,76 point sur un seul benchmark. Mais la tendance est claire : un routage intelligent rattrape le modèle phare en qualité et l'emporte sur le prix.

À quoi cela peut servir, et où est le piège

Pour les équipes qui construisent des agents au-dessus d'API de modèles de pointe, le schéma paraît pragmatique. Un modèle open-weight local ou peu coûteux assure l'essentiel du travail, et l'appel onéreux est réservé aux passages difficiles. Plus les scénarios sont longs, plus l'effet est marqué : la facture augmente avec le nombre d'étapes, alors que l'escalade se déclenche rarement.

La méthode a aussi ses limites. Elle exige un accès aux états cachés du modèle faible : seule une variante auto-hébergée ou open-weight convient. Il faut en outre une base de trajectoires passées annotées en réussite ou en échec, même si rien n'est à entraîner. La validation reste limitée à OSWorld, et l'on ignore comment le signal se comportera sur d'autres interfaces et dans des applications atypiques. Avant d'intégrer LEASH en production, mieux vaut constituer son propre jeu de trajectoires et vérifier dans quelle mesure le signal d'incertitude coïncide avec les échecs réels sur vos tâches.