Asana: costuri de model de 76 de ori mai mici cu GPT‑6.1 Sol
Cu GPT‑6 Astra în Codex, Asana și-a făcut agentul de browser de 76 de ori mai ieftin și de 5 ori mai rapid în teste, pentru a oferi clienților modele mai capabile.
76x
Costuri estimate ale modelului mai mici cu fluxul de lucru optimizat pe GPT-6.1 Sol
5x
Rulări mai rapide în browser cu fluxul de lucru optimizat pe GPT-6.1 Sol
0,47 USD
Costul mediu estimat al modelului cu fluxul de lucru optimizat pe GPT-6.1 Sol
Cu GPT‑6 Astra în Codex efectuând experimente, Asana a optimizat fluxul de lucru al agentului său de browser pe GPT‑6.1 Sol, obținând rulări de 76 de ori mai ieftine și de 5 ori mai rapide.
Asana ajută clienții să automatizeze activitatea în diverse aplicații de afaceri prin StackAI(se deschide într-o fereastră nouă), o platformă pe care a achiziționat-o(se deschide într-o fereastră nouă). Cu StackAI, clienții pot crea fluxuri de lucru care navighează pe site-uri, completează formulare și colectează informații, fără să scrie cod. La scara la care operează Asana, micile ineficiențe din aceste fluxuri de lucru se acumulează.
Dr. Frank Hidalgo, directorul tehnic al StackAI la Asana, și-a propus să facă agentul de browser mai rapid și mai ieftin de rulat. I-a cerut modelului GPT‑6 Astra din Codex să analizeze agentul, să testeze îmbunătățiri și să compare rezultatele. O muncă despre care estimează că i-ar fi luat una-două luni manual a durat aproximativ o săptămână.
Studiul Asana, cu 144 de rulări(se deschide într-o fereastră nouă), a testat GPT‑6.1 Sol și alte trei modele de vârf, numite aici Modelele A, B și C. Fluxul de lucru optimizat pe GPT‑6.1 Sol a înregistrat, în medie, un cost estimat al modelului de 0,47 USD și o durată de circa patru minute pe rulare: de 76 de ori mai ieftin și de 5 ori mai rapid decât configurația inițială din producție, bazată pe Modelul B.
„Așa arată în practică echipele formate din oameni și agenți. Un inginer a stabilit direcția, GPT-6 Astra a efectuat experimentele, iar rezultatele au ajuns prin Command în producție. Acest lucru arată cum Asana transformă în realitate echipele formate din oameni și agenți.”
Pentru a avansa rapid, Hidalgo a început prin a folosi GPT‑6 Astra în Codex pentru a analiza structura codului și a explica modul în care agentul construia fiecare cerere către model. GPT‑6 Astra a descoperit că agentul stoca în cache instrucțiunile fixe și definițiile instrumentelor, dar nu și istoricul tot mai mare de texte și capturi de ecran colectate de pe pagini. Astfel, fiecare cerere retrimitea acel istoric la preț întreg.
Agentul elimina și capturile de ecran mai vechi și trunchia textul la aproape fiecare pas. Fiecare modificare schimba istoricul, așa că simpla stocare a acestuia în cache nu ar fi fost de ajutor, iar pierderea informațiilor putea obliga agentul să revină pe pagini deja citite.
Hidalgo a analizat soluțiile propuse de GPT‑6 Astra și a ales trei pentru testare:
Extinderea stocării în cache la istoricul de navigare al agentului
Creșterea cantității de text pe care o putea păstra
Eliminarea capturilor de ecran în loturi, nu la fiecare pas
GPT‑6 Astra a început cu teste rapide pentru a stabili ce variabile contau. Deoarece codul nu fusese conceput pentru experimente controlate, modelul l-a refactorizat apoi, astfel încât un singur frontend și un singur backend să poată susține multe fluxuri de lucru în paralel, fiecare cu propriile setări.
Astra a efectuat studiul complet: limite de istoric de 120.000 și 480.000 de caractere și șase politici de stocare în cache și gestionare a capturilor de ecran, fiecare testată de trei ori pe fiecare dintre cele patru modele (vezi tabelul de mai jos). Politica cea mai performantă lăsa capturile de ecran să se acumuleze până la 20, apoi păstra doar cea mai recentă. Astfel, istoricul anterior rămânea neschimbat mai mult timp între eliminări. Împreună cu limita de istoric mai mare, această politică a devenit fluxul de lucru optimizat. Fiecare configurație a efectuat aceeași sarcină: colectarea a șase câmpuri pentru fiecare dintre cele 32 de cărți dintr-un catalog demonstrativ public, o sarcină reprezentativă pentru activitatea unor clienți Asana în StackAI.
Model | Descriere | Preț |
|---|---|---|
Modelul A | Un model mai mic și mai ieftin, de la un alt laborator de IA de vârf, lansat în toamna lui 2025 | Jumătate din prețul GPT‑6.1 Sol |
Modelul B | Modelul folosit inițial în producție, de la același laborator ca Modelul A, lansat în vara lui 2026 | Același preț ca GPT‑6.1 Sol |
Modelul C | O versiune actualizată a Modelului B, lansată în toamna lui 2026 | Același preț ca GPT‑6.1 Sol |
GPT‑6.1 Sol | Modelul OpenAI |
GPT‑6 Astra a rulat fluxurile de lucru și a examinat cererile, înregistrările de utilizare și rezultatele, iar sesiuni separate ale modelului au verificat munca. Cererile, traseele datelor și rezultatele fiecărei sesiuni au fost înregistrate în Command(se deschide într-o fereastră nouă), platforma Asana pentru livrarea de software, astfel încât echipa să poată analiza ulterior întregul studiu. Din Command, constatările au fost transformate în tichete, apoi în cereri de integrare a codului, iar modificările au ajuns în producție.
„Manual, mi-ar fi luat una-două luni. Cu GPT-6 Astra în Codex, a durat cam o săptămână: stabileam un /goal înainte de culcare și analizam rezultatele dimineața.”
Pentru Modelul B, optimizarea a redus costul estimat al modelului de la cel puțin 36,21 USD (unele rulări inițiale au atins limita de pași înainte de finalizare) la 1,24 USD pe rulare, o reducere de 29 de ori. Fluxul de lucru optimizat pe GPT‑6.1 Sol a fost de încă 2,6 ori mai ieftin, la 0,47 USD. Fiecare rulare a fluxului de lucru optimizat a finalizat sarcina și a returnat răspunsul corect.
Medii pentru 3 rulări. ≥: referința include rulări oprite la limită, deci media sa reprezintă o limită inferioară.
Cei doi factori de reducere din dreapta sunt calculați față de Modelul B optimizat. Modelul B a rulat în faza 1, iar Modelul C și Sol 6.1 în faza 2 a aceluiași studiu (linie punctată).
Doar pe GPT‑6.1 Sol, cu limita de istoric mai mare, noua politică de stocare în cache și gestionare a capturilor de ecran a redus costul de 4 ori, de la 1,97 USD la 0,47 USD pe rulare. Fiecare apel a fost de circa 3 ori mai ieftin, deoarece 89% din datele de intrare proveneau din cache, la 5% din prețul datelor nestocate în cache. Rulările au devenit și mai rapide: de la cel puțin 22,5 minute cu configurația inițială pe Modelul B la circa patru minute cu fluxul de lucru optimizat pe GPT‑6.1 Sol.
Media a 3 rulări, cu bare de eroare pentru abaterea standard. ≥: media include o rulare oprită la limită sau nefinalizată, deci valoarea reală este cel puțin egală cu aceasta.
Barele folosesc tema albastră. Evaluați efectele stocării în cache în raport cu bara pentru limita mai mare, de 480.000.
Marcajele rulărilor și barele de eroare pentru abaterea standard sunt reconstituiri aproximative din imaginea-sursă; valorile rulărilor și abaterile standard originale nu au fost disponibile.
Media a 3 rulări, cu bare de eroare pentru abaterea standard. ≥: media include o rulare oprită la limită sau nefinalizată, deci valoarea reală este cel puțin egală cu aceasta.
Barele folosesc tema albastră. Evaluați efectele stocării în cache în raport cu bara pentru limita mai mare, de 480.000.
Marcajele rulărilor și barele de eroare pentru abaterea standard sunt reconstituiri aproximative din imaginea-sursă; valorile rulărilor și abaterile standard originale nu au fost disponibile.
Analiza a arătat și cum gestionarea istoricului influența însăși capacitatea agentului de a produce un răspuns. Oferindu-i modelului GPT‑6.1 Sol mai mult spațiu pentru păstrarea istoricului de navigare, numărul rulărilor care au produs un răspuns a crescut de la trei din 18, cu limita mai mică, la toate cele 18, cu limita mai mare, fiecare cu răspunsul corect. Pentru Hidalgo, valoarea comercială constă în a oferi clienților acces la modele mai rapide și mai capabile, menținând totodată costurile operaționale sustenabile.
„Înainte, costul limita modelele pe care le puteam oferi clienților pentru aceste sarcini. Făcând agentul mai eficient, putem oferi clienților un model mai bun și mai rapid, reducându-ne totodată costurile operaționale.”
Asana a lansat modificările pentru navigarea în browser în StackAI și dezvoltă instrumente care să faciliteze repetarea unor experimente similare. În timp, echipa intenționează să includă aceste teste în evaluările platformei, astfel încât clienții și echipele interne să poată compara costul, durata rulării și calitatea răspunsurilor când își configurează agenții.
„Viteza de livrare nu mai este factorul limitativ; atenția umană este. Ne apropiem de o lume în care fiecare inginer este un manager de produs care conduce o flotă de agenți.”
Asana folosește acum GPT‑6 Astra în Codex pentru a testa funcționalități ale produsului înainte de lansare: Astra navighează pe platformă, încearcă diverse date de intrare și raportează erori specialiștilor umani în asigurarea calității. Hidalgo vede aici baza unui nou ciclu de dezvoltare software, în care numeroase sesiuni de agenți din cloud testează funcționalități în paralel.
Studiul complet este disponibil pe blogurile Asana(se deschide într-o fereastră nouă) și StackAI(se deschide într-o fereastră nouă).
