Asana a rendu un agent de navigation 76 fois moins cher en test sur GPT-6.1 Sol. Dans l'étude de 32 pages, la plus grosse étape est un budget de mémoire plus grand, pas le modèle

Le vendredi 9 octobre, OpenAI a publié un témoignage client sur Asana. Un agent de navigation qu'Asana fait tourner via StackAI, la plateforme d'agents sans code qu'elle a rachetée, a coûté en moyenne 0,47 $ de modèle estimé par exécution sur GPT-6.1 Sol lors de tests, en environ quatre minutes. OpenAI parle de 76 fois moins cher et 5 fois plus rapide que « la configuration de production d'origine sur le Modèle B », un modèle sans nom d'un autre laboratoire de pointe.

La couverture que j'ai lue s'arrêtait au premier découpage : les changements de workflow seuls ont divisé le coût par 29 sur le Modèle B, et le passage à GPT-6.1 Sol a ajouté un facteur 2,6. C'est exact, et ça s'arrête un niveau trop tôt. Le blog d'ingénierie d'Asana renvoie vers l'étude complète, un PDF de 32 pages daté du 30 septembre et écrit par le CTO de StackAI, Frank Hidalgo, qui a fait mener les expériences par GPT-6 Astra dans Codex. Elle contient le registre des exécutions, et ce registre raconte une histoire plus utile que le titre.

Je construis des agents sur Claude tous les jours en tant que CTO d'une LegalTech, et BidForge, mon produit annexe, lit des dossiers de marchés publics français pour des petites entreprises. Les deux sont des machines à renvoyer du contexte. J'ai donc lu le registre.

Ce que faisait l'agent

Un agent de navigation renvoie tout à chaque appel : les définitions d'outils, le prompt système, et un historique croissant de textes de pages et de captures d'écran. Un cache de prompt facture la partie répétée à une fraction du prix, mais il ne réutilise que le plus long préfixe inchangé d'une requête. L'agent d'Asana mettait en cache ses outils et son prompt système, pas son historique. Et il modifiait cet historique presque à chaque étape : il retirait la capture d'écran précédente et rognait les textes plus anciens pour tenir dans un budget de 120 000 caractères. Chaque modification changeait une partie antérieure de la requête, donc la réutilisation du cache sautait presque à chaque appel.

La tâche de test : ouvrir books.toscrape.com, une librairie fictive conçue pour s'entraîner au scraping, visiter 32 pages de livres, collecter six champs par livre (192 faits) et renvoyer un tableau avec le total des prix. Six politiques de cache et d'élagage, deux budgets d'historique, quatre modèles, trois exécutions chacun : 144 exécutions entre le 14 et le 30 septembre, plus un suivi de 12 exécutions le 1er octobre.

Les 76 fois, une étape à la fois

L'étude ajoute un changement à la fois sur le Modèle B. Coût moyen du modèle par exécution :

• Code d'origine, budget de 120 000 caractères : au moins 36,21 $. Une exécution a atteint la limite d'étapes, donc la moyenne est un plancher.
• Même code, budget relevé à 480 000 caractères : 4,87 $.
• Plus mise en cache de l'historique (3,94 $ seule), puis captures d'écran élaguées par lots : 1,24 $.
• Le même agent optimisé sur GPT-6.1 Sol : 0,47 $.

Cela fait environ 7,4 fois, puis 3,9 fois, puis 2,6 fois. Multiplie-les et tu retombes sur environ 76.

La plus grosse étape est la première, et elle n'implique ni cache ni nouveau modèle. À 120 000 caractères, l'agent rognait des faits qu'il avait déjà collectés, et la requête finale d'aucune exécution ne contenait encore les 192. Il retournait donc les chercher. Sur le Modèle B, les revisites de pages sont passées d'au moins 271 par exécution de référence à 2 avec le budget plus grand, un décompte qui, selon l'étude, inclut aussi les retours habituels au catalogue. Entre la configuration d'origine et la meilleure, le Modèle B a fait 9 fois moins d'appels, et chaque exécution a envoyé 2,3 millions de tokens au lieu de 19,7 millions.

Un agent qui oublie paie deux fois.

Le piège de la mise à jour

Les modèles plus récents ont cassé l'ancien budget. Le Modèle C, une version plus récente du Modèle B sortie à l'automne 2026, ajoutait environ 6 300 tokens d'entrée par appel avant son premier élagage, contre 900 pour le Modèle A et 1 800 pour le Modèle B et Sol. Le Modèle C a élagué son historique pour la première fois à l'appel 10, le Modèle A à l'appel 64. À 120 000 caractères, le Modèle C n'a livré une réponse dans aucune de ses 18 exécutions, et GPT-6.1 Sol dans 3. À 480 000, toutes les exécutions des deux ont répondu.

Lis ça du côté de l'acheteur. Tu installes un modèle plus récent avec les anciens réglages, et le modèle plus récent a l'air cassé. Un budget d'historique est réglé pour un modèle, ce qui fait d'une mise à jour de modèle un changement de configuration.

Le cache seul a coûté plus cher

C'est la découverte que je trouve la plus utile. Avec le budget plus grand, mettre l'historique en cache sans changer l'élagage a coûté plus cher que ne pas le mettre en cache sur le Modèle A, le Modèle C et Sol. Les écritures de cache représentaient plus de 90 pour cent du coût de cette condition, alors que les lectures de cache restaient sous un tiers de l'entrée.

L'arithmétique est simple. Dans la grille de prix de l'étude, une écriture de cache coûte 1,25 fois le prix d'entrée. Une lecture coûte 0,1 fois chez l'autre fournisseur et 0,05 fois sur Sol. Sur GPT-6.1 Sol, cela donne 2,00 $ par million de tokens d'entrée hors cache, 2,50 $ pour écrire et 0,10 $ pour lire, les lignes que montre la page de tarifs d'OpenAI. Prends un historique simplifié de 50 000 tokens sur 20 appels. Sans cache : 20 × 50 000 × 2 $ / 1 M = 2,00 $. Écrit une fois, puis lu 19 fois : 0,125 $ + 0,095 $ = 0,22 $. Réécrit à chaque appel parce que quelque chose d'antérieur a changé : 20 × 0,125 $ = 2,50 $, un quart de plus que sans cache du tout.

L'élagage par lots est le remède. À 20:1, l'agent garde jusqu'à 20 captures d'écran, puis revient à une seule, de sorte qu'environ 19 appels consécutifs réutilisent l'historique en cache. Les exécutions médianes de Sol dans l'étude le montrent à l'appel 24 : environ 40 000 tokens d'entrée, 9 pour cent venant du cache, avec l'ancienne politique ; environ 58 000, 93 pour cent venant du cache, avec la nouvelle. D'après mon calcul sur ces chiffres, en ignorant la sortie, la requête 45 pour cent plus grosse a coûté environ 0,016 $ contre 0,073 $.

Ensuite, un suivi a gardé toutes les captures d'écran, sans aucun élagage. Le coût par appel est ressorti 1,2 fois plus bas que la meilleure condition sur le Modèle B et Sol. L'étude est prudente : l'élagage reste important pour les longues tâches, les fenêtres de contexte plus petites et les lectures de cache plus chères, et elle qualifie cette comparaison d'« indicative », puisque le suivi a tourné en un seul lot avec des caches partagés. Sur cette tâche, ajouter sans jamais réécrire a gagné.

Ce que le témoignage client omet

C'est un test de développement, pas une facture de production. Là où la page d'OpenAI et le blog d'Asana disent « configuration de production », l'étude appelle le point de départ une « base de développement ». Elle examine le problème « avant toute affirmation sur des économies en production chez Asana ». Les coûts sont calculés à partir des compteurs de tokens aux prix catalogue, ne sont « pas des factures » et excluent les coûts de sandbox et de serveur.

La meilleure condition a été choisie après les exécutions, la moyenne la plus basse parmi douze, et l'étude nomme elle-même ce biais de sélection. Trois exécutions par condition.

La comparaison entre modèles est, selon le mot de l'étude, « descriptive ». Le Modèle C et Sol ont tourné dans une seconde phase avec l'effort réglé sur élevé, et Sol a reçu une durée de vie de cache de 30 minutes contre cinq minutes.

Une partie des 2,6 fois de Sol vient d'une ligne de prix. Dans la grille de prix de l'étude, les Modèles B, C et Sol coûtent tous 2 $ en entrée et 10 $ en sortie par million de tokens, mais Sol lit son cache à 0,10 $ contre 0,20 $. Sol a fait 28 appels en moyenne contre 12 pour le Modèle C et reste pourtant sorti moins cher.

Sol a répondu « avec un court résumé du total et des livres les moins chers et les plus chers plutôt qu'avec le tableau complet ». Toutes les réponses de Sol avaient le bon total. Elles étaient aussi plus courtes que ce que demandait la tâche, et la sortie est la ligne la plus chère de la grille de prix. L'étude ne dit pas quelle part de l'écart cela explique.

Même une citation a bougé. Sur la page d'Asana, son CPO, Arnab Bose, dit « un agent a mené les expériences ». Sur la page d'OpenAI, la même phrase devient « GPT-6 Astra a mené les expériences ». Un témoignage client est du marketing. L'étude est la preuve.

Ce que je vérifierais dans mes propres agents

Rien de tout ça n'est propre à OpenAI : l'étude dit que ses leçons ont tenu chez les deux fournisseurs.

Mesure les lectures de cache par appel à partir des compteurs d'usage du fournisseur, pas à partir de ta configuration. L'agent d'origine d'Asana avait un marqueur de cache et lisait environ un dixième de son entrée depuis le cache.

Liste tout ce qui réécrit les messages antérieurs : un rogneur de texte, un suppresseur d'images, un résultat d'outil résumé sur place. L'étude en ajoute un que je n'aurais pas deviné : chez l'autre fournisseur, changer le choix d'outil réinitialisait le cache des messages, et chaque appel qui forçait un outil provoquait un échec de cache.

Recale le budget d'historique à chaque changement de modèle. Journalise l'appel où le premier élagage a lieu, et si l'agent revisite ce qu'il a déjà lu.

Chiffre un élagage avant de le livrer. Sur une exécution de Sol de 35 appels, l'étude estime qu'un élagage ne se rembourse qu'après environ 27 appels de plus au prix de lecture de 0,05 fois de Sol, environ 13 à 0,1 fois.

Garde les garde-fous. Aucune exécution n'a atteint le budget de 480 000 caractères, et l'étude dit quand même de plafonner les étapes, les tokens et le coût par exécution, parce que si le cache casse sur un agent qui dérive, chaque appel paie plein tarif.

En septembre, j'ai écrit que pour les agents, la lecture de cache est la ligne qui change la facture. Cette étude ajoute la condition que j'avais laissée implicite : le cache ne paie qu'une fois que l'agent cesse de réécrire son propre passé. Le modèle n'a été que les derniers 2,6. Les premiers 29 étaient dans la façon dont l'agent gardait sa mémoire, et le même correctif a baissé le coût sur chaque modèle testé.

Sources

• OpenAI, "Asana cuts model costs 76x in browser tests with GPT-6.1 Sol" (9 octobre 2026)
• Asana, "How we cut a browser agent's cost 76x and made it 5x faster by keeping its cache intact" (8 octobre 2026)
• Frank Hidalgo pour Asana, "How Asana used Codex to optimize browser agent costs and runtime" (PDF) (30 septembre 2026)
• StackAI, "How StackAI by Asana used Astra, Codex and Command to Reduce Browser Agent Costs" (8 octobre 2026)
• OpenAI, "API pricing" (consulté le 19 octobre 2026)
• Yellow.com, "GPT-6.1 Sol Helped Cut Asana's Agent Costs 76 Times, But Here's The Catch" (12 octobre 2026)