Asana: cost 76 cops menor en tests de navegador amb GPT‑6.1 Sol
Amb GPT‑6 Astra a Codex, Asana va dividir per 76 el cost del seu agent de navegador i el va fer 5 vegades més ràpid en proves per oferir models més capaços als clients.
76x
Costos estimats del model més baixos amb el flux de treball optimitzat de GPT-6.1 Sol
5x
Execucions de navegador més ràpides amb el flux de treball optimitzat de GPT-6.1 Sol
0,47 $
Cost mitjà estimat del model amb el flux de treball optimitzat de GPT-6.1 Sol
Amb GPT‑6 Astra executant experiments a Codex, Asana va optimitzar el flux de treball del seu agent de navegador amb GPT‑6.1 Sol per dividir-ne el cost per 76 i fer-lo 5 vegades més ràpid.
Asana ajuda els clients a automatitzar tasques entre aplicacions empresarials amb StackAI(s'obre en una finestra nova), una plataforma que va adquirir(s'obre en una finestra nova). Amb StackAI, els clients poden crear fluxos de treball que naveguin per llocs web, emplenin formularis i recullin informació sense escriure codi. A l'escala d'Asana, les petites ineficiències d'aquests fluxos de treball s'acumulen.
El Dr. Frank Hidalgo, director tecnològic de StackAI a Asana, es va proposar fer que l'agent de navegador fos més ràpid i econòmic d'executar. Va encarregar a GPT‑6 Astra, a Codex, que investigués l'agent, provés millores i comparés els resultats. Una feina que, segons calcula, li hauria costat entre un i dos mesos fer manualment es va completar en una setmana aproximadament.
L'estudi d'Asana de 144 execucions(s'obre en una finestra nova) va posar a prova GPT‑6.1 Sol i tres altres models d'avantguarda, que aquí anomenem models A, B i C. El flux de treball optimitzat que en va resultar amb GPT‑6.1 Sol va registrar una mitjana de 0,47 $ de cost estimat del model i uns quatre minuts per execució: un cost 76 vegades inferior i una velocitat 5 vegades superior als de la configuració original en producció amb el model B.
"Així funcionen a la pràctica els equips de persones i agents. Un enginyer va marcar la direcció, GPT-6 Astra va executar els experiments i els resultats van passar per Command fins a producció. Això demostra com Asana fa realitat els equips de persones i agents."
Per avançar ràpidament, Hidalgo va començar utilitzant GPT‑6 Astra a Codex per explorar la base de codi i explicar com l'agent construïa cada petició al model. GPT‑6 Astra va descobrir que l'agent desava a la memòria cau les instruccions fixes i les definicions d'eines, però no l'historial creixent de text de pàgines i captures de pantalla que recollia. Així, cada petició tornava a enviar tot l'historial al preu complet.
L'agent també eliminava les captures de pantalla més antigues i retallava text pràcticament a cada pas. Cada modificació alterava l'historial, de manera que desar-lo a la memòria cau no hauria estat suficient. A més, perdre aquestes dades podia obligar l'agent a tornar a visitar pàgines que ja havia llegit.
Hidalgo va revisar les solucions proposades per GPT‑6 Astra i en va seleccionar tres per provar-les:
Desar també a la memòria cau l'historial de navegació de l'agent
Augmentar la quantitat de text que podia conservar
Eliminar captures de pantalla per lots en lloc de fer-ho a cada pas
GPT‑6 Astra va començar amb proves ràpides per determinar quines variables eren rellevants. Com que el codi no estava dissenyat per a experiments controlats, després el va refactoritzar perquè un únic frontal i un únic rerefons poguessin gestionar molts fluxos de treball en paral·lel, cadascun amb la seva configuració.
Astra va dur a terme l'estudi complet: límits d'historial de 120.000 i 480.000 caràcters i sis polítiques de memòria cau i captures de pantalla, cadascuna provada tres vegades amb cada un dels quatre models (vegeu la taula següent). La política amb millors resultats permetia acumular fins a 20 captures de pantalla abans de conservar-ne només la més recent. Això mantenia l'historial anterior intacte durant períodes més llargs entre eliminacions. Combinada amb el límit d'historial més ampli, aquesta política va donar lloc al flux de treball optimitzat. Cada configuració realitzava la mateixa tasca: recollir sis camps per a cadascun de 32 llibres d'un catàleg públic de demostració, una tasca representativa de les que alguns clients d'Asana executen a StackAI.
Model | Descripció | Preu |
|---|---|---|
Model A | Un model més petit i econòmic d'un altre laboratori d'avantguarda, llançat la tardor de 2025 | La meitat del preu de GPT‑6.1 Sol |
Model B | El model utilitzat inicialment en producció, del mateix laboratori que el model A, llançat l'estiu de 2026 | El mateix preu que GPT‑6.1 Sol |
Model C | Una versió actualitzada del model B, llançada la tardor de 2026 | El mateix preu que GPT‑6.1 Sol |
GPT‑6.1 Sol | El model d'OpenAI |
GPT‑6 Astra va executar els fluxos de treball i va examinar les peticions, els registres d'ús i els resultats, mentre que sessions independents del model van revisar la feina. Les peticions, les traces de dades i els resultats de cada sessió es van registrar a Command(s'obre en una finestra nova), la plataforma de lliurament de programari d'Asana, perquè l'equip pogués revisar l'estudi complet després. Des de Command, les conclusions es van convertir en tasques i després en sol·licituds d'incorporació de canvis, i els canvis es van desplegar en producció.
"Fer-ho manualment m'hauria costat entre un i dos mesos. Amb GPT-6 Astra a Codex, vaig trigar aproximadament una setmana: establia un /goal abans d'anar a dormir i revisava els resultats al matí."
En el cas del model B, l'optimització va reduir el cost estimat del model de com a mínim 36,21 $ (algunes execucions originals arribaven al límit de passos abans d'acabar) a 1,24 $ per execució: una reducció per un factor de 29. Amb GPT‑6.1 Sol, el flux de treball optimitzat era encara 2,6 vegades més econòmic, amb un cost de 0,47 $. Totes les execucions del flux de treball optimitzat van completar la tasca i van retornar la resposta correcta.
Mitjanes de 3 execucions. ≥: la configuració de referència inclou execucions aturades pel límit, de manera que la seva mitjana és un límit inferior.
Els dos factors de la dreta mostren la comparació amb el model B optimitzat. El model B es va executar a la fase 1, i el model C i Sol 6.1 a la fase 2 del mateix estudi (línia de punts).
Només amb GPT‑6.1 Sol, amb el límit d'historial més ampli, la nova política de memòria cau i captures de pantalla va dividir el cost per 4, d'1,97 $ a 0,47 $ per execució. Cada crida era unes 3 vegades més econòmica, perquè el 89 % de l'entrada provenia de la memòria cau i costava el 5 % del preu de l'entrada sense memòria cau. Les execucions també es van accelerar: de com a mínim 22,5 minuts amb la configuració original del model B a uns quatre minuts amb el flux de treball optimitzat de GPT‑6.1 Sol.
Mitjana de 3 execucions, amb barres d'error de desviació estàndard. ≥: la mitjana inclou una execució aturada pel límit o inacabada, de manera que el valor real és com a mínim aquest.
Les barres utilitzen una paleta de blaus. Compareu els efectes de la memòria cau amb la barra del límit més ampli de 480k.
Els marcadors d'execució i les barres d'error de desviació estàndard són reconstruccions aproximades de la imatge original; no es disposava dels valors d'execució ni de les desviacions estàndard subjacents.
Mitjana de 3 execucions, amb barres d'error de desviació estàndard. ≥: la mitjana inclou una execució aturada pel límit o inacabada, de manera que el valor real és com a mínim aquest.
Les barres utilitzen una paleta de blaus. Compareu els efectes de la memòria cau amb la barra del límit més ampli de 480k.
Els marcadors d'execució i les barres d'error de desviació estàndard són reconstruccions aproximades de la imatge original; no es disposava dels valors d'execució ni de les desviacions estàndard subjacents.
La investigació també va mostrar com la gestió de l'historial condicionava que l'agent arribés a produir una resposta. Donar a GPT‑6.1 Sol més espai per conservar l'historial de navegació va augmentar el nombre d'execucions que produïen una resposta: de tres de les 18 amb el límit d'historial més reduït a les 18 amb el més ampli, totes amb la resposta correcta. Per a Hidalgo, el valor empresarial rau a donar als clients accés a models més ràpids i capaços, mantenint uns costos operatius sostenibles.
"Abans, el cost limitava els models que podíem oferir als clients per a aquestes càrregues de treball. En fer l'agent més eficient, podem oferir als clients un model millor i més ràpid, alhora que reduïm els nostres costos operatius."
Asana ha incorporat els canvis de navegació web a StackAI i està desenvolupant eines per facilitar la repetició d'experiments similars. Amb el temps, l'equip preveu incorporar aquestes proves a les avaluacions de la plataforma perquè els clients i els equips interns puguin comparar el cost, el temps d'execució i la qualitat de les respostes en configurar els seus agents.
"El coll d'ampolla ja no és la velocitat de lliurament, sinó l'atenció humana. Ens acostem a un món on cada enginyer serà un gestor de producte al capdavant d'un conjunt d'agents."
Ara Asana utilitza GPT‑6 Astra a Codex per provar les funcions del producte abans de llançar-les: Astra navega per la plataforma, prova diferents entrades i informa dels errors als revisors humans de control de qualitat. Hidalgo ho veu com la base d'un nou cicle de vida del desenvolupament de programari, amb moltes sessions d'agents al núvol que proven funcions en paral·lel.
L'estudi complet està disponible als blogs d'Asana(s'obre en una finestra nova) i de StackAI(s'obre en una finestra nova).
