Asana divise par 76 le coût de son agent navigateur avec GPT-6.1 Sol

Asana a transformé un problème d'ingénierie très ciblé en cas d'étude utile pour quiconque exploite des agents en production. Sa plateforme StackAI permet aux clients de construire, sans écrire de code, des flux de travail qui parcourent des sites web, remplissent des formulaires et recueillent des informations. À l'échelle d'Asana, chaque petite inefficacité d'un agent navigateur se multiplie sur un nombre d'exécutions très élevé. Frank Hidalgo, directeur technique de StackAI, a voulu rendre l'agent plus rapide et moins coûteux. Il a demandé à GPT-6 Astra, dans Codex, d'examiner l'agent, de tester des améliorations et de comparer les résultats. Le résultat publié est net. Le flux optimisé sur GPT-6.1 Sol coûte en moyenne 0,47 $ de modèle estimé et dure environ quatre minutes par exécution. C'est 76 fois moins cher et 5 fois plus rapide que la configuration de production d'origine, qui tournait sur le modèle B. Hidalgo estime que ce travail aurait pris un à deux mois à la main. Il a pris environ une semaine.

La cause tenait à la façon dont l'agent construisait chaque requête. GPT-6 Astra a d'abord cartographié le code et expliqué l'assemblage des requêtes. Il a constaté que l'agent mettait en cache ses instructions fixes et ses définitions d'outils, mais pas l'historique croissant du texte des pages et des captures d'écran. Chaque requête renvoyait donc cet historique au tarif plein. L'agent supprimait aussi les anciennes captures et tronquait le texte presque à chaque étape. Chacune de ces modifications changeait l'historique. Le cache de prompt repose sur un préfixe stable : si le début de l'historique change, tout ce qui suit est invalidé. Mettre en cache l'historique seul n'aurait donc rien apporté. Perdre des informations avait aussi un coût caché, car l'agent pouvait devoir revisiter des pages déjà lues. La leçon : cache, rétention et nettoyage forment un seul problème de conception, et en corriger un seul peut laisser la facture inchangée.

Hidalgo a examiné les correctifs proposés par GPT-6 Astra et en a retenu trois : étendre le cache à l'historique de navigation, augmenter la quantité de texte conservée, et supprimer les captures par lots plutôt qu'à chaque étape. Astra a d'abord mené des tests rapides pour repérer les variables qui comptaient. Le code n'était pas conçu pour des expériences contrôlées ; il l'a donc remanié afin qu'un seul frontal et un seul serveur exécutent de nombreux flux en parallèle, chacun avec ses réglages. Il a ensuite réalisé l'étude complète : deux budgets d'historique, 120 000 et 480 000 caractères, et six politiques de cache et de captures, chacune testée trois fois sur chacun des quatre modèles, soit 144 exécutions. La meilleure politique laissait les captures s'accumuler jusqu'à 20 avant de revenir à la plus récente. L'historique ancien restait ainsi inchangé plus longtemps entre deux suppressions, ce qui gardait le cache valide. Associée au budget d'historique plus large, elle est devenue le flux optimisé.

Le protocole mérite l'attention. Chaque configuration exécutait la même tâche : recueillir six champs pour chacun de 32 livres d'un catalogue de démonstration public, représentatif de ce que certains clients d'Asana font dans StackAI. Les quatre modèles étaient GPT-6.1 Sol et trois modèles d'un autre laboratoire de pointe. Le modèle A est un modèle plus petit et moins cher, sorti à l'automne 2025, à moitié prix de GPT-6.1 Sol. Le modèle B est celui utilisé à l'origine en production, sorti à l'été 2026, au même prix. Le modèle C est une version mise à jour du modèle B, sortie à l'automne 2026, au même prix également. Comme trois modèles sur quatre coûtent autant que GPT-6.1 Sol ou moins, l'écart de coût vient surtout de la manière dont chaque flux exploite le cache. Un calcul simple à partir des chiffres publiés, 0,47 $ multiplié par 76, situe le coût d'origine autour de 36 $ par exécution. Ce chiffre est notre propre calcul, pas une donnée communiquée par Asana.

Le processus autour de l'expérience compte autant que le résultat. GPT-6 Astra a exécuté les flux et examiné les requêtes, les relevés d'usage et les sorties. Des sessions de modèle distinctes ont relu son travail. Les requêtes, traces de données et résultats de chaque session ont été consignés dans Command, la plateforme de livraison logicielle d'Asana, ce qui a permis à l'équipe de revoir l'étude complète. Depuis Command, les constats sont devenus des tickets, puis des demandes de fusion, et les changements sont partis en production. Hidalgo décrit un /goal posé avant d'aller dormir et des résultats relus le matin. Arnab Bose, directeur produit d'Asana, résume : un ingénieur a donné la direction, GPT-6 Astra a mené les expériences, et les résultats sont passés par Command jusqu'en production. C'est une image concrète d'équipes mêlant humains et agents, avec une trace à chaque étape.

Trois enseignements en découlent pour le secteur. Premièrement, le coût d'un agent dépend surtout de l'ingénierie du contexte, pas du tarif catalogue du modèle. Quand trois modèles sur quatre coûtent autant ou moins, le facteur décisif est de savoir si le long préfixe croissant de chaque requête est servi depuis le cache. Les équipes qui ne comparent que les prix par jeton peuvent manquer le levier principal. Deuxièmement, utiliser un agent pour améliorer un agent ne fonctionne que si les expériences sont reproductibles et les preuves traçables. Asana a remanié son code pour permettre une comparaison contrôlée et gardé chaque trace dans un seul système. Cette discipline mérite d'être copiée plus que n'importe quel réglage. Troisièmement, les chiffres demandent une lecture prudente : une seule tâche, un catalogue de démonstration public, des coûts estimés et non des factures. L'étude montre que la méthode fonctionne. Elle ne prouve pas que tout flux de navigation gagnera un facteur 76. Pour les équipes qui passent des agents en production, un premier pas réaliste consiste à repérer ce qui est mis en cache et ce qui change à chaque étape, puis à valider tout correctif par une petite étude contrôlée. Ramener un à deux mois de recherche manuelle à une semaine économise des heures, et abaisse aussi le coût d'essayer des idées.