Asana divise les coûts des modèles par 76 avec GPT‑6.1 Sol
Avec GPT‑6 Astra dans Codex, Asana rend son agent de navigation 76 fois moins cher et 5 fois plus rapide en test, pour offrir aux clients des modèles plus performants.
76×
Coûts estimés du modèle réduits avec le workflow optimisé sur GPT-6.1 Sol
5×
Exécutions de navigation plus rapides avec le workflow optimisé sur GPT-6.1 Sol
0,47 $
Coût moyen estimé du modèle avec le workflow optimisé sur GPT-6.1 Sol
En confiant les expérimentations à GPT‑6 Astra dans Codex, Asana a optimisé le workflow 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 métier grâce à StackAI(ouverture dans une nouvelle fenêtre), une plateforme que l’entreprise a acquise(ouverture dans une nouvelle fenêtre). Avec StackAI, les clients peuvent créer des workflows qui parcourent des sites web, remplissent des formulaires et recueillent des informations sans écrire de code. À l’échelle d’Asana, les petites inefficacités de ces workflows finissent par peser.
Frank Hidalgo, PhD, directeur technique 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, selon lui, aurait pris un à deux mois à la main a été réalisé en une semaine environ.
L’étude d’Asana portant sur 144 exécutions(ouverture 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 workflow optimisé obtenu sur GPT‑6.1 Sol affichait un coût estimé moyen de 0,47 $ pour le modèle 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 concrètement les équipes composées d’humains et d’agents. Un ingénieur a fixé le cap, GPT-6 Astra a mené les expériences, et 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 commencé par utiliser 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 tronquait le texte à presque chaque étape. Chaque modification altérait l’historique : le mettre en cache n’aurait donc pas suffi. De plus, 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 les variables importantes. Le code n’étant pas conçu pour des expériences contrôlées, il l’a ensuite remanié afin qu’un même frontend et un même backend puissent prendre en charge de nombreux workflows en parallèle, chacun avec ses propres paramètres.
Astra a mené l’étude complète : des capacités d’historique de 120 000 et 480 000 caractères et six stratégies de mise en cache et de gestion des captures d’écran, chacune testée trois fois sur chacun des quatre modèles (voir le tableau ci-dessous). La stratégie 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. Associée à la capacité d’historique accrue, cette stratégie a constitué le workflow optimisé. Chaque configuration effectuait la même tâche : recueillir six champs pour chacun des 32 livres d’un catalogue public de démonstration, 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, issu d’un autre laboratoire de pointe, sorti à l’automne 2025 | Deux fois moins cher que GPT‑6.1 Sol |
Modèle B | Le modèle initialement utilisé en production, issu du même laboratoire que le modèle A, sorti à l’été 2026 | Même prix que GPT‑6.1 Sol |
Modèle C | Une version actualisée du modèle B, sortie à 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 workflows et examiné les requêtes, les relevés d’utilisation et les sorties, tandis que des sessions de modèle distinctes vérifiaient le travail. Les requêtes, les traces de données et les résultats de chaque session ont été enregistrés dans Command(ouverture dans une nouvelle fenêtre), la plateforme de livraison logicielle d’Asana, afin que l’équipe puisse ensuite examiner l’étude complète. Depuis Command, les conclusions ont été transformées en tickets, puis en pull requests, 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 ramené le coût estimé du modèle d’au moins 36,21 $ (certaines exécutions initiales atteignaient la limite d’étapes avant d’aboutir) à 1,24 $ par exécution, soit un coût divisé par 29. Le workflow optimisé sur GPT‑6.1 Sol était encore 2,6 fois moins cher, à 0,47 $. Chaque exécution du workflow optimisé a terminé la tâche et fourni la bonne réponse.
Moyennes de 3 exécutions. ≥ : la référence inclut des exécutions plafonnées ; sa moyenne constitue donc une borne inférieure.
Les deux facteurs de gain à droite sont calculés par rapport au modèle B optimisé. Le modèle B a été exécuté lors de la phase 1, et le modèle C et Sol 6.1 lors de la phase 2 de la même étude (ligne pointillée).
Sur GPT‑6.1 Sol seul, avec la capacité d’historique accrue, la nouvelle stratégie de mise en cache et de gestion des captures d’écran a divisé le coût par 4, de 1,97 $ à 0,47 $ par exécution. Chaque appel coû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 workflow optimisé sur GPT‑6.1 Sol.
Moyenne de 3 exécutions, barres d’erreur représentant l’écart-type. ≥ : la moyenne inclut 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. Évaluez les effets de la mise en cache par rapport à la barre de capacité accrue à 480 k.
Les marqueurs d’exécution et les barres d’écart-type sont des reconstitutions approximatives à partir 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 représentant l’écart-type. ≥ : la moyenne inclut 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. Évaluez les effets de la mise en cache par rapport à la barre de capacité accrue à 480 k.
Les marqueurs d’exécution et les barres d’écart-type sont des reconstitutions approximatives à partir de l’image source ; les valeurs d’exécution et les écarts-types sous-jacents n’étaient pas disponibles.
L’analyse a également montré que la gestion de l’historique influait sur la capacité de l’agent à fournir 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 ayant fourni une réponse est passé de trois sur 18 avec la capacité réduite à 18 sur 18 avec la capacité accrue, toutes avec la bonne réponse. Pour Hidalgo, l’intérêt économique est de donner aux clients accès à des modèles plus rapides et plus performants, tout en maintenant des coûts d’exploitation soutenables.
« Le coût limitait les modèles que nous pouvions proposer aux clients pour ces tâches. 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, afin 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.
« Le goulot d’étranglement n’est plus la vitesse de livraison, mais l’attention humaine. Nous approchons d’un monde où chaque ingénieur est un chef de produit à la tête d’une flotte d’agents. »
Asana utilise désormais GPT‑6 Astra dans Codex pour tester les fonctionnalités du produit avant leur sortie : Astra parcourt la plateforme, essaie différentes entrées et signale les bugs aux responsables humains de l’assurance qualité. Hidalgo y voit les fondations d’un nouveau cycle de développement logiciel, où de nombreuses sessions d’agents dans le cloud testent les fonctionnalités en parallèle.
L’étude complète est disponible sur les blogs d’Asana(ouverture dans une nouvelle fenêtre) et de StackAI(ouverture dans une nouvelle fenêtre).
