Asanas browsertests: 76× lavere modeludgifter med GPT‑6.1 Sol
Med GPT‑6 Astra i Codex gjorde Asana sin browseragent 76 gange billigere og 5 gange hurtigere i tests for at tilbyde kunderne mere kompetente modeller.
76×
Lavere estimerede modelomkostninger med den optimerede GPT-6.1 Sol-arbejdsgang
5×
Hurtigere browserkørsler med den optimerede GPT-6.1 Sol-arbejdsgang
0,47 USD
Gennemsnitlige estimerede modelomkostninger med den optimerede GPT-6.1 Sol-arbejdsgang
Med GPT‑6 Astra i Codex til at udføre eksperimenter optimerede Asana sin browseragents arbejdsgang på GPT‑6.1 Sol, så den blev 76 gange billigere og 5 gange hurtigere at køre.
Asana hjælper kunder med at automatisere arbejde på tværs af forretningsapplikationer via StackAI(åbner i et nyt vindue), en platform, virksomheden har opkøbt(åbner i et nyt vindue). Med StackAI kan kunder oprette arbejdsgange, der navigerer på websites, udfylder formularer og indsamler oplysninger, uden at skrive kode. I Asanas størrelsesorden bliver selv små ineffektiviteter i disse arbejdsgange til meget.
Frank Hidalgo, ph.d. og CTO for StackAI hos Asana, satte sig for at gøre browseragenten hurtigere og billigere at køre. Han bad GPT‑6 Astra i Codex om at undersøge agenten, teste forbedringer og sammenligne resultaterne. Arbejdet tog omkring en uge – mod de en til to måneder, han vurderer, det ville have taget manuelt.
I Asanas undersøgelse med 144 kørsler(åbner i et nyt vindue) blev GPT‑6.1 Sol og tre andre banebrydende modeller testet, her kaldet Model A, B og C. Den optimerede arbejdsgang på GPT‑6.1 Sol endte med gennemsnitlige estimerede modelomkostninger på 0,47 USD og en køretid på omkring fire minutter pr. kørsel – 76 gange billigere og 5 gange hurtigere end den oprindelige produktionsopsætning med Model B.
»Sådan ser teams af mennesker og agenter ud i praksis. En udvikler satte retningen, GPT-6 Astra udførte eksperimenterne, og resultaterne gik gennem Command til produktion. Det viser, hvordan Asana gør teams af mennesker og agenter til virkelighed.«
For at komme hurtigt i gang brugte Hidalgo først GPT‑6 Astra i Codex til at kortlægge kodebasen og forklare, hvordan agenten opbyggede hver anmodning til modellen. GPT‑6 Astra opdagede, at agenten cachede sine faste instruktioner og værktøjsdefinitioner, men ikke den voksende historik med sidetekst og skærmbilleder, den indsamlede. Derfor blev historikken sendt igen til fuld pris ved hver anmodning.
Agenten fjernede også ældre skærmbilleder og forkortede tekst ved næsten hvert trin. Hver redigering ændrede historikken, så det ville ikke have hjulpet blot at cache den. Og når oplysningerne gik tabt, kunne agenten blive nødt til at genbesøge sider, den allerede havde læst.
Hidalgo gennemgik GPT‑6 Astras forslag til forbedringer og udvalgte tre til test:
Udvide caching til også at omfatte agentens browsinghistorik
Øge den mængde tekst, agenten kunne gemme
Fjerne skærmbilleder i grupper i stedet for ved hvert trin
GPT‑6 Astra begyndte med hurtige tests for at fastslå, hvilke variabler der havde betydning. Koden var ikke designet til kontrollerede eksperimenter. Derfor omstrukturerede modellen den, så én frontend og én backend kunne understøtte mange parallelle arbejdsgange med hver deres indstillinger.
Astra gennemførte hele undersøgelsen: historikgrænser på 120.000 og 480.000 tegn samt seks politikker for caching og skærmbilleder, som hver blev testet tre gange på hver af de fire modeller (se tabellen nedenfor). Den politik, der gav de bedste resultater, lod antallet af skærmbilleder vokse til 20, før alle undtagen det nyeste blev fjernet. På den måde forblev den tidligere historik uændret i længere perioder mellem fjernelserne. Sammen med den højere historikgrænse blev det den optimerede arbejdsgang. Hver konfiguration udførte den samme opgave: at indsamle seks felter for hver af 32 bøger fra et offentligt demokatalog – en opgave, der er repræsentativ for, hvad nogle Asana-kunder kører i StackAI.
Model | Beskrivelse | Pris |
|---|---|---|
Model A | En mindre, billigere model fra et andet laboratorium for banebrydende AI, lanceret i efteråret 2025 | Halvdelen af prisen på GPT‑6.1 Sol |
Model B | Modellen, der oprindeligt blev brugt i produktion, fra samme laboratorium som Model A, lanceret i sommeren 2026 | Samme pris som GPT‑6.1 Sol |
Model C | En opdateret version af Model B, lanceret i efteråret 2026 | Samme pris som GPT‑6.1 Sol |
GPT‑6.1 Sol | OpenAIs model |
GPT‑6 Astra kørte arbejdsgangene og undersøgte anmodningerne, forbrugsregistreringerne og outputtene, mens separate modelsessioner gennemgik arbejdet. Hver sessions anmodninger, dataspor og resultater blev registreret i Command(åbner i et nyt vindue), Asanas platform til softwareleverancer, så teamet bagefter kunne gennemgå hele undersøgelsen. Fra Command blev resultaterne omsat til opgaver og derefter pull requests, og ændringerne blev sat i produktion.
»Det ville have taget mig en til to måneder manuelt. Med GPT-6 Astra i Codex tog det omkring en uge: Jeg satte et mål med /goal, før jeg gik i seng, og gennemgik resultaterne om morgenen.«
For Model B reducerede optimeringen de estimerede modelomkostninger fra mindst 36,21 USD (nogle oprindelige kørsler nåede grænsen for antal trin, før de var færdige) til 1,24 USD pr. kørsel – en reduktion med en faktor 29. Den optimerede arbejdsgang på GPT‑6.1 Sol var yderligere 2,6 gange billigere med en pris på 0,47 USD. Hver kørsel med den optimerede arbejdsgang fuldførte opgaven og returnerede det korrekte svar.
Gennemsnit af 3 kørsler. ≥: Udgangspunktet omfatter kørsler, der blev stoppet ved grænsen, så gennemsnittet er en nedre grænse.
De to faktorer til højre er beregnet i forhold til den optimerede Model B. Model B blev kørt i fase 1, og Model C og Sol 6.1 i fase 2 af samme undersøgelse (stiplet linje).
For GPT‑6.1 Sol alene, med den højere historikgrænse, reducerede den nye politik for caching og skærmbilleder omkostningerne med en faktor 4, fra 1,97 USD til 0,47 USD pr. kørsel. Hvert kald var omkring 3 gange billigere, fordi 89 % af inputtet kom fra cachen til 5 % af prisen for ikke-cachet input. Kørslerne blev også hurtigere: fra mindst 22,5 minutter med den oprindelige opsætning på Model B til omkring fire minutter med den optimerede arbejdsgang på GPT‑6.1 Sol.
Gennemsnit af 3 kørsler med fejlstænger for standardafvigelsen. ≥: Gennemsnittet omfatter en kørsel, der blev stoppet ved grænsen eller ikke fuldført, så den reelle værdi er mindst så høj.
Søjlerne bruger det blå tema. Vurder effekten af caching i forhold til søjlen med den højere historikgrænse på 480.000.
Kørselsmarkører og fejlstænger for standardafvigelsen er omtrentlige rekonstruktioner fra kildebilledet; de underliggende kørselsværdier og standardafvigelser var ikke tilgængelige.
Gennemsnit af 3 kørsler med fejlstænger for standardafvigelsen. ≥: Gennemsnittet omfatter en kørsel, der blev stoppet ved grænsen eller ikke fuldført, så den reelle værdi er mindst så høj.
Søjlerne bruger det blå tema. Vurder effekten af caching i forhold til søjlen med den højere historikgrænse på 480.000.
Kørselsmarkører og fejlstænger for standardafvigelsen er omtrentlige rekonstruktioner fra kildebilledet; de underliggende kørselsværdier og standardafvigelser var ikke tilgængelige.
Undersøgelsen viste også, hvordan håndteringen af historikken påvirkede, om agenten overhovedet leverede et svar. Da GPT‑6.1 Sol fik mere plads til at gemme sin browsinghistorik, steg antallet af kørsler, der leverede et svar, fra tre ud af 18 med den lave historikgrænse til alle 18 med den høje – alle med det korrekte svar. For Hidalgo ligger den forretningsmæssige værdi i at give kunderne adgang til hurtigere, mere kompetente modeller og samtidig holde driftsomkostningerne på et holdbart niveau.
»Tidligere satte omkostningerne grænser for, hvilke modeller vi kunne tilbyde kunderne til disse opgaver. Ved at gøre agenten mere effektiv kan vi give kunderne en bedre, hurtigere model og samtidig sænke vores driftsomkostninger.«
Asana har udrullet ændringerne til browsernavigation i StackAI og udvikler værktøjer, der gør det lettere at gentage lignende eksperimenter. På sigt vil teamet indarbejde disse tests i platformens evalueringer, så kunder og interne teams kan sammenligne omkostninger, køretid og svarkvalitet, når de konfigurerer deres agenter.
»Flaskehalsen er ikke længere, hvor hurtigt vi kan levere, men hvor meget menneskelig opmærksomhed vi har til rådighed. Vi er tæt på en verden, hvor hver udvikler er en produktchef, der leder en flåde af agenter.«
Asana bruger nu GPT‑6 Astra i Codex til at teste produktfunktioner før lancering: Astra navigerer på platformen, afprøver forskellige input og rapporterer fejl til de medarbejdere, der står for kvalitetssikringen. Hidalgo ser dette som grundlaget for en ny livscyklus for softwareudvikling, hvor mange agentsessioner i skyen tester funktioner parallelt.
Hele undersøgelsen kan læses på Asana(åbner i et nyt vindue) og StackAI(åbner i et nyt vindue)s blogs.
