Asana : coûts de modèle divisés par 76 en test avec GPT‑6.1 Sol
Avec GPT‑6 Astra dans Codex, Asana a rendu son agent de navigation 76 fois moins cher et 5 fois plus rapide lors des tests afin d’offrir à ses clients des modèles plus performants.
76×
Coûts de modèle estimés réduits avec le flux de travail optimisé sur GPT-6.1 Sol
5×
Exécutions de navigation plus rapides avec le flux de travail optimisé sur GPT-6.1 Sol
0,47 $
Coût de modèle estimé moyen avec le flux de travail optimisé sur GPT-6.1 Sol
Grâce aux expériences menées par GPT‑6 Astra dans Codex, Asana a optimisé le flux de travail de son agent de navigation sur GPT‑6.1 Sol pour le rendre 76 fois moins cher et 5 fois plus rapide.
Asana aide ses clients à automatiser le travail dans leurs applications d’entreprise grâce à StackAI(s'ouvre dans une nouvelle fenêtre), une plateforme dont elle a fait l’acquisition(s'ouvre dans une nouvelle fenêtre). Avec StackAI, les clients peuvent créer des flux de travail qui parcourent des sites Web, remplissent des formulaires et recueillent de l’information sans écrire de code. À l’échelle d’Asana, les petites inefficacités de ces flux de travail s’additionnent.
Frank Hidalgo, Ph. D., directeur de la technologie de StackAI chez Asana, a entrepris de rendre l’agent de navigation plus rapide et moins coûteux à exécuter. Il a demandé à GPT‑6 Astra dans Codex d’analyser l’agent, de tester des améliorations et de comparer les résultats. Un travail qui aurait pris, selon lui, un à deux mois à la main a été réalisé en une semaine environ.
L’étude d’Asana portant sur 144 exécutions(s'ouvre dans une nouvelle fenêtre) a testé GPT‑6.1 Sol et trois autres modèles de pointe, appelés ici modèles A, B et C. Le flux de travail optimisé obtenu sur GPT‑6.1 Sol affichait un coût de modèle estimé moyen de 0,47 $ et une durée d’environ quatre minutes par exécution, soit 76 fois moins cher et 5 fois plus rapide que la configuration de production initiale sur le modèle B.
« Voilà à quoi ressemblent les équipes d’humains et d’agents en pratique. Un ingénieur a fixé le cap, GPT-6 Astra a mené les expériences, puis les résultats sont passés par Command avant la mise en production. Cela montre comment Asana donne vie aux équipes d’humains et d’agents. »
Pour avancer rapidement, Hidalgo a d’abord utilisé GPT‑6 Astra dans Codex pour cartographier la base de code et expliquer comment l’agent construisait chaque requête au modèle. GPT‑6 Astra a découvert que l’agent mettait en cache ses instructions fixes et ses définitions d’outils, mais pas l’historique croissant des textes de pages et des captures d’écran recueillis. Chaque requête renvoyait donc cet historique au plein tarif.
L’agent supprimait aussi les anciennes captures d’écran et raccourcissait le texte à presque chaque étape. Chaque modification changeait l’historique; sa seule mise en cache n’aurait donc pas aidé, et la perte de ces informations pouvait obliger l’agent à revenir sur des pages déjà lues.
Hidalgo a examiné les correctifs proposés par GPT‑6 Astra et en a retenu trois à tester :
Étendre la mise en cache à l’historique de navigation de l’agent
Augmenter la quantité de texte qu’il pouvait conserver
Supprimer les captures d’écran par lots plutôt qu’à chaque étape
GPT‑6 Astra a commencé par des tests rapides pour déterminer quelles variables avaient une incidence. Comme le code n’était pas conçu pour des expériences contrôlées, il l’a ensuite remanié afin qu’une seule interface et un seul serveur puissent prendre en charge de nombreux flux de travail en parallèle, chacun avec ses propres paramètres.
Astra a mené l’étude complète : des budgets d’historique de 120 000 et 480 000 caractères et six politiques de mise en cache et de captures d’écran, chacune testée trois fois sur chacun des quatre modèles (voir le tableau ci-dessous). La politique la plus performante laissait les captures d’écran s’accumuler jusqu’à 20 avant de ne conserver que la plus récente. L’historique antérieur restait ainsi inchangé plus longtemps entre les suppressions. Combinée au budget d’historique plus élevé, cette politique est devenue le flux de travail optimisé. Chaque configuration effectuait la même tâche : recueillir six champs pour chacun des 32 livres d’un catalogue de démonstration public, une tâche représentative de celles que certains clients d’Asana exécutent dans StackAI.
Modèle | Description | Prix |
|---|---|---|
Modèle A | Un modèle plus petit et moins cher d’un autre laboratoire de pointe, lancé à l’automne 2025 | La moitié du prix de GPT‑6.1 Sol |
Modèle B | Le modèle utilisé initialement en production, du même laboratoire que le modèle A, lancé à l’été 2026 | Même prix que GPT‑6.1 Sol |
Modèle C | Une version mise à jour du modèle B, lancée à l’automne 2026 | Même prix que GPT‑6.1 Sol |
GPT‑6.1 Sol | Le modèle d’OpenAI |
GPT‑6 Astra a exécuté les flux de travail et examiné les requêtes, les relevés d’utilisation et les sorties, puis des sessions distinctes du modèle ont vérifié le travail. Les requêtes, les traces de données et les résultats de chaque session ont été enregistrés dans Command(s'ouvre dans une nouvelle fenêtre), la plateforme de livraison logicielle d’Asana, pour que l’équipe puisse ensuite examiner l’étude complète. À partir de Command, les constats ont été transformés en billets, puis en demandes de fusion, et les modifications ont été mises en production.
« Cela m’aurait pris un à deux mois à la main. Avec GPT-6 Astra dans Codex, il a fallu environ une semaine : je définissais un /goal avant de me coucher et j’examinais les résultats le matin. »
Pour le modèle B, l’optimisation a réduit le coût de modèle estimé d’au moins 36,21 $ (certaines exécutions initiales atteignaient la limite d’étapes avant de se terminer) à 1,24 $ par exécution, soit une division par 29. Le flux de travail optimisé sur GPT‑6.1 Sol était encore 2,6 fois moins cher, à 0,47 $. Chaque exécution du flux de travail optimisé a accompli la tâche et renvoyé la bonne réponse.
Moyennes de 3 exécutions. ≥ : la configuration de référence comprend des exécutions plafonnées; sa moyenne constitue donc une borne inférieure.
Les deux facteurs à droite sont calculés par rapport au modèle B optimisé. Le modèle B a été exécuté en phase 1, et le modèle C et Sol 6.1 en phase 2 de la même étude (ligne pointillée).
Sur GPT‑6.1 Sol seulement, avec le budget d’historique plus élevé, la nouvelle politique de mise en cache et de captures d’écran a divisé le coût par 4, le faisant passer de 1,97 $ à 0,47 $ par exécution. Chaque appel était environ 3 fois moins cher, car 89 % des données d’entrée provenaient du cache, à 5 % du tarif hors cache. Les exécutions sont aussi devenues plus rapides : au moins 22,5 minutes avec la configuration initiale sur le modèle B, contre environ quatre minutes avec le flux de travail optimisé sur GPT‑6.1 Sol.
Moyenne de 3 exécutions, barres d’erreur d’écart-type. ≥ : la moyenne comprend une exécution plafonnée ou inachevée; la valeur réelle est donc au moins aussi élevée.
Les barres utilisent le thème bleu. Comparez les effets de la mise en cache à la barre du budget plus élevé de 480 k.
Les marqueurs d’exécution et les barres d’erreur d’écart-type sont des reconstitutions approximatives de l’image source; les valeurs d’exécution et les écarts-types sous-jacents n’étaient pas disponibles.
Moyenne de 3 exécutions, barres d’erreur d’écart-type. ≥ : la moyenne comprend une exécution plafonnée ou inachevée; la valeur réelle est donc au moins aussi élevée.
Les barres utilisent le thème bleu. Comparez les effets de la mise en cache à la barre du budget plus élevé de 480 k.
Les marqueurs d’exécution et les barres d’erreur d’écart-type sont des reconstitutions approximatives de l’image source; les valeurs d’exécution et les écarts-types sous-jacents n’étaient pas disponibles.
L’analyse a aussi montré comment la gestion de l’historique influait sur la capacité de l’agent à produire une réponse, quelle qu’elle soit. En donnant à GPT‑6.1 Sol plus d’espace pour conserver son historique de navigation, le nombre d’exécutions produisant une réponse est passé de trois sur 18 avec le petit budget d’historique à 18 sur 18 avec le budget plus élevé, chaque réponse étant correcte. Pour Hidalgo, la valeur commerciale consiste à donner aux clients accès à des modèles plus rapides et plus performants tout en maintenant des coûts d’exploitation viables.
« Le coût limitait auparavant les modèles que nous pouvions offrir aux clients pour ces charges de travail. En rendant l’agent plus efficace, nous pouvons offrir aux clients un modèle meilleur et plus rapide tout en réduisant nos coûts d’exploitation. »
Asana a déployé les modifications de navigation Web dans StackAI et développe des outils pour faciliter la répétition d’expériences similaires. À terme, l’équipe prévoit d’intégrer ces tests aux évaluations de la plateforme, pour que les clients et les équipes internes puissent comparer le coût, la durée d’exécution et la qualité des réponses lors de la configuration de leurs agents.
« La vitesse de livraison n’est plus le goulot d’étranglement; c’est l’attention humaine. Nous approchons d’un monde où chaque ingénieur est un gestionnaire de produit à la tête d’une flotte d’agents. »
Asana utilise maintenant GPT‑6 Astra dans Codex pour tester les fonctionnalités du produit avant leur lancement : Astra parcourt la plateforme, essaie différentes entrées et signale les bogues aux responsables humains de l’assurance qualité. Hidalgo y voit les bases d’un nouveau cycle de développement logiciel, où de nombreuses sessions d’agents infonuagiques testent les fonctionnalités en parallèle.
L’étude complète est accessible sur les blogues d’Asana(s'ouvre dans une nouvelle fenêtre) et de StackAI(s'ouvre dans une nouvelle fenêtre).
