Résultat 76x de l'agent navigateur de GPT-6.1 Sol : ce qu'Asana a réellement mesuré.

Asana a publié une étude sur les coûts des agents de navigateur le 8 octobre 2026, et le développeur de GPT-6.1 Sol en a rédigé un compte rendu le lendemain sous le titre « Asana réduit les coûts de modèle par 76x lors de tests de navigateur avec GPT-6.1 Sol ». Le 76x est réel au sens où quelqu'un l'a mesuré, mais ce n'est pas un fait sur le prix de GPT-6.1 Sol. C'est un fait sur ce qui se produit lorsqu'on corrige un cache de prompt défectueux sur un agent de navigateur, puis qu'on remplace le modèle qui se trouve derrière. La même optimisation, exécutée sur le modèle qu'Asana avait déjà en production — un modèle qu'elle appelle Model B — a réduit les coûts de 29x à elle seule. GPT-6.1 Sol a fourni les 2,6x restants. Les expériences ont été menées par GPT-6 Astra travaillant dans Codex, et le modèle derrière la référence est le modèle d'un concurrent qu'Asana appelle Model B, donc deux gammes d'un même fournisseur et un rival non nommé apparaissent tous dans l'histoire. Ce qui suit sépare la partie du résultat que vous pouvez copier dès lundi de la partie qui appartient à la stack particulière d'Asana.

La comparaison, énoncée avec exactitude

La stack d'Asana pour cela est StackAI, la plateforme d'automatisation de workflows qu'elle a acquise, qui exécute un agent navigateur qui parcourt des sites web, remplit des formulaires et collecte des informations sans code. La tâche de test était restreinte et concrète : collecter six champs pour chacun des 32 livres d'un catalogue de démonstration public. Cela est représentatif de ce que certains clients exécutent, et c'est aussi suffisamment petit pour qu'une étude de 144 exécutions tienne en une semaine.

Le plan expérimental comportait six politiques de mise en cache et de capture d'écran pour deux budgets d'historique, trois exécutions par condition, sur quatre modèles — 144 exécutions, plus un suivi de 12 exécutions. Les coûts ont été calculés à partir des propres compteurs de tokens de chaque fournisseur, et chaque réponse a été évaluée par rapport à une référence préparée de manière indépendante. Les quatre modèles étaient trois modèles de pointe non nommés (modèles A, B et C) et GPT-6.1 Sol. Le modèle A est un modèle plus petit et moins cher d'un autre laboratoire, sorti à l'automne 2025, dont le prix est la moitié de celui de GPT-6.1 Sol. Le modèle B est le modèle qui était en production, du même laboratoire que A, sorti à l'été 2026, au même prix que GPT-6.1 Sol. Le modèle C est une version plus récente du modèle B, sortie à l'automne 2026, également au même prix que GPT-6.1 Sol. Les trois ne sont pas nommés dans les deux articles, de sorte que la comparaison n'est pas reproductible par un lecteur — bon à savoir avant de considérer 29x comme un chiffre concernant le modèle de quelqu'un d'autre. Ce sont les chiffres publiés d'Asana et d'OpenAI, et non des chiffres audités de manière indépendante.

L’échelle des résultats, tous les chiffres propres à Asana :

• Production de référence sur le modèle B — au moins 36,21 $ par exécution, au moins 22,5 minutes par exécution. Certaines exécutions de référence atteignent la limite d’étapes avant de se terminer, de sorte que la moyenne est un plancher plutôt qu’une véritable moyenne.

• Modèle B, agent optimisé — 1,24 $ par exécution, 4 fois plus rapide que la référence, une réduction de coûts de 29 fois.

• GPT-6.1 Sol, même agent optimisé — 0,47 $ par exécution, environ quatre minutes, une réduction des coûts de 76x et 5x plus rapide.

• GPT-6.1 Sol, avant vs après le correctif — de 1,97 $ à 0,47 $ par exécution, une réduction de 4x rien qu’avec les changements de cache et d’élagage.

Parce que la base de référence est une borne inférieure, 76x est lui-même un plancher. L’interprétation honnête est « au moins 76x », et non « 76x ».

Ce qui a réellement changé, et pourquoi ce n'est pas une fonctionnalité du modèle

Le mécanisme en jeu est celui du cache de prompt, et il vaut la peine d’être compris, car il s’applique à n’importe quel agent que vous exécutez sur n’importe quel modèle. Un agent de navigateur renvoie ses outils, son prompt système et son historique croissant de texte de page et de captures d’écran à chaque appel au modèle. La mise en cache des prompts applique une réduction à la partie répétée, mais uniquement au plus long préfixe inchangé — dès que quelque chose change au milieu de la requête, la réutilisation se rompt à partir de ce point.

L'agent de production d'Asana présentait deux défauts qui se cumulaient. Il mettait en cache ses instructions fixes et ses définitions d'outils, mais pas son historique de navigation. Et il modifiait cet historique à presque chaque étape : il supprimait la capture d'écran précédente à chaque fois et rognait le texte plus ancien pour respecter un budget d'historique. Chaque modification invalidait le préfixe, de sorte que la mise en cache aurait été quasi inutile même si elle avait été activée. Le compte rendu d'Asana note que, sur les modèles testés, les lectures de cache coûtent 0,05x à 0,1x le prix d'entrée standard — le gain était donc important, et l'agent le refusait systématiquement.

Le correctif comporte deux volets. Premièrement, mettre aussi l’historique en cache, avec un marqueur de cache sur le dernier résultat d’outil. Deuxièmement, arrêter de le modifier à chaque appel : conserver les captures d’écran et les élaguer par lots selon un ratio de 20 pour 1, de sorte que l’agent en garde jusqu’à 20, puis revienne à la plus récente. Environ 19 appels consécutifs réutilisent alors un préfixe inchangé. Relever le budget d’historique de 120 000 à 480 000 caractères afin que l’ancien texte ne soit plus tronqué, et le calcul tombe juste : sur GPT-6.1 Sol, chaque appel a coûté environ 3 fois moins cher, car 89 % de l’entrée provenait du cache.

Le constat le plus important ici est négatif. Mettre en cache l'historique sans élagage par lots, avec le budget le plus élevé, a coûté plusque de ne pas mettre en cache du tout sur trois des quatre modèles — le cache était continuellement réécrit et rarement lu. Une infrastructure de cache activée sans discipline d'historique en ajout seul, c'est payer une prime d'écriture pour rien. Ce mode de défaillance est indépendant du modèle, et c'est la raison pour laquelle le même correctif a amélioré le modèle B d'un facteur 29.

Là où le choix du modèle a réellement payé

Retirez la correction du flux de travail et comparez ce qui est comparable : pour un même agent optimisé, GPT-6.1 Sol a coûté 2,6 fois moins cher que Model B, au même prix affiché. Le facteur supplémentaire tient au comportement des hits de cache, pas à la grille tarifaire. Sol a lu 89 % de son entrée depuis le cache ; Asana ne publie pas la part équivalente pour Model B, donc le facteur 2,6 est un résultat mesuré sans décomposition publiée. Considérez-le comme « ce modèle, sur cette charge de travail, a mieux utilisé son cache », et non comme un avantage général de 2,6 fois sur un modèle que nous ne pouvons pas nommer.

Le côté exécution est sans ambiguïté : 5 fois plus rapide que la référence, avec le workflow Sol optimisé à environ quatre minutes contre une référence d’au moins 22,5 minutes. La vitesse compte pour le coût dans les agents facturés au token, car un modèle lent qui boucle paie pour ses boucles.

Pour quiconque veut en calculer le coût : les tarifs API standard de GPT-6.1 Sol sont de 2,00 $ par million de tokens d’entrée, 0,10 $ par million de tokens d’entrée mis en cache et 10,00 $ par million de tokens de sortie, et sa remise sur lecture du cache est de 0,05 fois le tarif d’entrée — la plus importante de la grille tarifaire actuelle d’OpenAI. GPT-6 Astra, le modèle qui a fait le travail d’ingénierie dans Codex, coûte 10,00 $ en entrée et 50,00 $ en sortie, soit l’écart de cinq fois sur lequel l’argumentaire de lancement d’OpenAI s’est appuyé. La raison pour laquelle l’étude a produit des exécutions à 0,47 $ plutôt qu’à 2 $ n’est pas la grille tarifaire ; c’est que 89 % d’une requête très répétitive a été facturé au vingtième du tarif d’entrée. Sur un agent à forte utilisation du cache, la ligne de remise pèse plus lourd que le prix affiché, et dans notre propre catalogue, les prix catalogue des fournisseurs sont répercutés avec 0 % de marge, donc lorsqu’un fournisseur modifie un compteur d’entrée mise en cache, cela se répercute sur votre facture le jour même.

L'autre chiffre de l'étude : le budget d'historique déterminait si l'agent répondait tout court

Le coût par exécution est le chiffre que tout le monde cite, mais le résultat le plus utile de l'étude concerne la fiabilité, et c'est celui qu'un opérateur devrait lire en premier.

• Avec un budget de 120 000 caractères, Model C n’a répondu dans aucune de ses 18 exécutions et GPT-6.1 Sol a répondu dans 3 des 18 — la plupart des exécutions ont atteint la limite d’étapes sans produire de réponse.

• À 480 000 caractères, chaque exécution sur les deux modèles a répondu, chacune avec la bonne réponse.

• Les modèles plus récents ont épuisé plus rapidement le budget plus restreint : le modèle C a réduit son historique pour la première fois à l'appel 10, le modèle A à l'appel 64.

• Dans le flux de travail optimisé, chaque exécution a accompli la tâche et renvoyé la bonne réponse, et chaque exécution en conditions optimales sur chaque modèle a rencontré l’ensemble des 192 faits qu’elle était censée collecter.

C'est un argument différent de « moins cher ». Un budget d'historique trop petit sur un modèle performant produit un agent qui échoue faute de place, et il échoue en atteignant le plafond d'étapes, ce qui est la façon la plus coûteuse d'échouer — vous payez l'exécution entière et n'obtenez rien. Augmenter le budget a fait grimper le coût par appel et baisser le coût par réponse, qui est le seul chiffre qu'un responsable de production devrait suivre. Si vous évaluez un modèle non éprouvé pour un agent de ce type, le schéma à faible risque consiste à garder votre route de production sur le modèle auquel vous faites confiance et à placer le nouveau derrière un basculement ou une route scindée, afin qu'une défaillance due à la limite d'étapes se présente comme un fait de routage plutôt que comme un incident. Tous les modèles de cette comparaison sont accessibles via une API pour plus de 200 modèles avec la tarification catalogue des fournisseurs transmise sans modification, ce qui rend aussi la remise sur lecture de cache comparable entre fournisseurs sur une même facture plutôt que sur cinq tableaux de bord.

Ce qu'il faut en retenir, dans l'ordre

Si vous exploitez un navigateur ou un agent d’utilisation d’ordinateur, trois leviers de l’étude d’Asana valent la peine d’être actionnés avant de consulter une grille tarifaire :

• Faites en sorte que le préfixe de requête soit en ajout uniquement. Toute modification par appel au milieu de l’historique annule la réutilisation du cache à partir de ce point.

• Élaguer par lots. Le suivi d'Asana a révélé que conserver chaque capture d'écran coûtait 1,2 fois moins par appel que la meilleure condition d'élagage sur le modèle B et GPT-6.1 Sol, et environ 5 % de moins sur le modèle C. L'élagage reste important pour les tâches longues, les petites fenêtres de contexte et les lectures de cache coûteuses — mais l'argument en faveur d'un ratio de lots de 20:1 tient à la stabilité du cache, et non aux captures d'écran elles-mêmes.

• Définissez le budget d’historique par modèle, et vérifiez-le par rapport à votre plafond d’étapes. Un budget qui convient à un modèle peut affamer le suivant.

Deux garde-fous issus de l'étude sont faciles à ignorer, et ils ne devraient pas l'être. Aucune exécution n'a atteint le budget de 480 000 caractères, donc ce budget n'a jamais contraint ces exécutions — mais un agent qui dérive grossit vers sa limite de contexte, et si le cache se casse, chaque appel paie le prix plein. Les plafonds sur les étapes, les jetons et le coût par exécution sont ce qui borne une mauvaise exécution. Par ailleurs, l'étude utilisait trois ou quatre exécutions par condition, avec des nombres d'appels variables, ce dont Asana dit elle-même que c'est suffisant pour révéler de grandes tendances, mais pas assez pour distinguer des conditions distantes de quelques pour cent. Ne tirez pas de ceci un écart de 5 % pour rebâtir votre pipeline autour de lui.

La partie qui est véritablement nouvelle, et celle qui ne l'est pas

Les réserves sur le protocole méritent d’être énoncées clairement : quatre modèles, dont trois non nommés, une tâche étroite de 32 livres, les propres compteurs instrumentés d’Asana, et le compte rendu d’un fournisseur qui héberge le résultat. Rien ici n’a été reproduit en dehors d’Asana. Mais le mécanisme est entièrement spécifié — historique en ajout seul, marqueur de cache sur le dernier résultat d’outil, élagage par lots, budget plus large, mesurer les lectures de cache avec les compteurs du fournisseur — et c’est le genre de constat qui survit au fait d’être attribué au mauvais laboratoire. Le 76x est un chiffre d’Asana sur une charge de travail Asana. La raison pour laquelle il vaut la peine d’être lu est qu’il démontre une règle que vous pouvez tester en un après-midi : un agent qui modifie son propre historique à chaque étape paie le prix fort pour une conversation qu’il a déjà eue.