Asana: Modellkostnad på 1/76 i nettlesertester med GPT‑6.1 Sol
Med GPT‑6 Astra i Codex kuttet Asana nettleseragentens kostnader til 1/76 og økte hastigheten 5 ganger i tester, for å tilby kundene mer kapable modeller.
76×
Lavere estimerte modellkostnader med den optimaliserte GPT-6.1 Sol-arbeidsflyten
5×
Raskere nettleserkjøringer med den optimaliserte GPT-6.1 Sol-arbeidsflyten
0,47 USD
Gjennomsnittlig estimert modellkostnad med den optimaliserte GPT-6.1 Sol-arbeidsflyten
Ved å la GPT‑6 Astra i Codex utføre eksperimenter optimaliserte Asana nettleseragentens arbeidsflyt med GPT‑6.1 Sol, slik at kostnadene ble redusert til 1/76 og kjøringene gikk 5 ganger raskere.
Asana hjelper kunder med å automatisere arbeid på tvers av bedriftsapplikasjoner gjennom StackAI(åpnes i et nytt vindu), en plattform selskapet har kjøpt opp(åpnes i et nytt vindu). Med StackAI kan kunder bygge arbeidsflyter som navigerer på nettsteder, fyller ut skjemaer og henter informasjon uten å skrive kode. I Asanas målestokk får selv små ineffektiviteter i disse arbeidsflytene store utslag.
Frank Hidalgo, PhD, teknologidirektør for StackAI hos Asana, satte seg fore å gjøre nettleseragenten raskere og rimeligere i drift. Han ba GPT‑6 Astra i Codex undersøke agenten, teste forbedringer og sammenligne resultatene. Arbeid han anslår ville tatt én til to måneder manuelt, tok omtrent én uke.
Asanas studie med 144 kjøringer(åpnes i et nytt vindu) testet GPT‑6.1 Sol og tre andre banebrytende modeller, her kalt modell A, B og C. Den resulterende optimaliserte arbeidsflyten med GPT‑6.1 Sol hadde i gjennomsnitt estimerte modellkostnader på 0,47 USD og en kjøretid på omtrent fire minutter – 1/76 av kostnaden og 5 ganger raskere enn det opprinnelige produksjonsoppsettet med modell B.
«Slik ser team av mennesker og agenter ut i praksis. En utvikler satte retningen, GPT-6 Astra utførte eksperimentene, og resultatene gikk gjennom Command og ut i produksjon. Dette viser hvordan Asana gjør team av mennesker og agenter til virkelighet.»
For å komme raskt i gang brukte Hidalgo først GPT‑6 Astra i Codex til å kartlegge kodebasen og forklare hvordan agenten bygde hver forespørsel til modellen. GPT‑6 Astra oppdaget at agenten hurtiglagret sine faste instruksjoner og verktøydefinisjoner, men ikke den voksende historikken av sidetekst og skjermbilder den samlet inn. Derfor ble historikken sendt på nytt til full pris ved hver forespørsel.
Agenten fjernet også eldre skjermbilder og kortet ned tekst ved nesten hvert trinn. Hver redigering endret historikken, så hurtiglagring alene ville ikke ha hjulpet. Tapet av disse opplysningene kunne dessuten tvinge agenten til å besøke sider den allerede hadde lest, på nytt.
Hidalgo gjennomgikk forbedringene GPT‑6 Astra foreslo, og valgte tre å teste:
Utvide hurtiglagringen til også å omfatte agentens nettleserhistorikk
Øke mengden tekst den kunne beholde
Fjerne skjermbilder i grupper i stedet for ved hvert trinn
GPT‑6 Astra begynte med raske tester for å finne ut hvilke variabler som hadde betydning. Siden koden ikke var laget for kontrollerte eksperimenter, refaktorerte modellen den deretter slik at én frontend og én backend kunne støtte mange arbeidsflyter parallelt, hver med egne innstillinger.
Astra gjennomførte hele studien: historikkrammer på 120 000 og 480 000 tegn og seks strategier for hurtiglagring og skjermbilder, hver testet tre ganger på hver av de fire modellene (se tabellen nedenfor). Strategien som ga best resultat, lot antallet skjermbilder øke til 20 før alle unntatt det nyeste ble fjernet. Dette holdt den tidligere historikken uendret i lengre perioder mellom fjerningene. Sammen med den større historikkrammen utgjorde dette den optimaliserte arbeidsflyten. Hver konfigurasjon utførte samme oppgave: å samle inn seks felt for hver av 32 bøker fra en offentlig demokatalog, representativt for det noen av Asanas kunder kjører i StackAI.
Modell | Beskrivelse | Pris |
|---|---|---|
Modell A | En mindre og rimeligere modell fra et annet forskningsmiljø for banebrytende KI, lansert høsten 2025 | Halve prisen av GPT‑6.1 Sol |
Modell B | Modellen som opprinnelig ble brukt i produksjon, fra samme forskningsmiljø som modell A, lansert sommeren 2026 | Samme pris som GPT‑6.1 Sol |
Modell C | En oppdatert versjon av modell B, lansert høsten 2026 | Samme pris som GPT‑6.1 Sol |
GPT‑6.1 Sol | OpenAIs modell |
GPT‑6 Astra kjørte arbeidsflytene og undersøkte forespørsler, brukslogger og resultater. Separate modelløkter gjennomgikk arbeidet. Forespørsler, dataspor og resultater fra hver økt ble registrert i Command(åpnes i et nytt vindu), Asanas plattform for programvareleveranser, slik at teamet kunne gjennomgå hele studien i etterkant. I Command ble funnene omgjort til saker, deretter til pull requests, og endringene ble satt i produksjon.
«Dette ville tatt meg én til to måneder manuelt. Med GPT-6 Astra i Codex tok det omtrent én uke: Jeg satte et mål med /goal før jeg la meg, og gjennomgikk resultatene om morgenen.»
For modell B reduserte optimaliseringen den estimerte modellkostnaden fra minst 36,21 USD (noen opprinnelige kjøringer nådde trinngrensen før de var ferdige) til 1,24 USD per kjøring – en reduksjon med en faktor på 29. Den optimaliserte arbeidsflyten med GPT‑6.1 Sol reduserte kostnaden ytterligere med en faktor på 2,6, til 0,47 USD. Hver kjøring i den optimaliserte arbeidsflyten fullførte oppgaven og returnerte riktig svar.
Gjennomsnitt av 3 kjøringer. ≥: Referanseoppsettet inkluderer kjøringer som ble stoppet ved grensen, så gjennomsnittet er en nedre grense.
De to faktorene til høyre er sammenligninger med optimalisert modell B. Modell B ble kjørt i fase 1, modell C og Sol 6.1 i fase 2 av samme studie (stiplet linje).
For GPT‑6.1 Sol alene, med den større historikkrammen, reduserte den nye strategien for hurtiglagring og skjermbilder kostnaden til en firedel, fra 1,97 til 0,47 USD per kjøring. Hvert kall kostet omtrent en tredel så mye, fordi 89 % av inndataene kom fra hurtigbufferen til 5 % av prisen for data uten hurtiglagring. Kjøringene ble også raskere: fra minst 22,5 minutter med det opprinnelige oppsettet på modell B til rundt fire minutter med den optimaliserte arbeidsflyten på GPT‑6.1 Sol.
Gjennomsnitt av 3 kjøringer, med feilfelt som viser standardavvik. ≥: Gjennomsnittet inkluderer en kjøring som ble stoppet ved grensen eller ikke fullført, så den reelle verdien er minst så stor.
Søylene bruker det blå temaet. Vurder effekten av hurtiglagring opp mot søylen for den større rammen på 480k.
Kjøringsmarkører og feilfelt for standardavvik er omtrentlige rekonstruksjoner fra originalbildet; de underliggende kjøringsverdiene og standardavvikene var ikke tilgjengelige.
Gjennomsnitt av 3 kjøringer, med feilfelt som viser standardavvik. ≥: Gjennomsnittet inkluderer en kjøring som ble stoppet ved grensen eller ikke fullført, så den reelle verdien er minst så stor.
Søylene bruker det blå temaet. Vurder effekten av hurtiglagring opp mot søylen for den større rammen på 480k.
Kjøringsmarkører og feilfelt for standardavvik er omtrentlige rekonstruksjoner fra originalbildet; de underliggende kjøringsverdiene og standardavvikene var ikke tilgjengelige.
Undersøkelsen viste også hvordan håndteringen av historikken påvirket om agenten i det hele tatt ga et svar. Når GPT‑6.1 Sol fikk mer plass til å beholde nettleserhistorikken, økte antallet kjøringer som ga et svar, fra tre av 18 med den mindre historikkrammen til alle 18 med den større rammen. Alle ga riktig svar. For Hidalgo ligger forretningsverdien i å gi kundene tilgang til raskere og mer kapable modeller, samtidig som driftskostnadene holdes på et bærekraftig nivå.
«Tidligere begrenset kostnadene hvilke modeller vi kunne tilby kundene til disse arbeidsoppgavene. Ved å gjøre agenten mer effektiv kan vi gi kundene en bedre og raskere modell samtidig som vi senker driftskostnadene våre.»
Asana har lansert endringene i nettlesernavigasjonen i StackAI og utvikler verktøy som gjør det enklere å gjenta lignende eksperimenter. Over tid planlegger teamet å innlemme denne testingen i plattformens evalueringer, slik at kunder og interne team kan sammenligne kostnad, kjøretid og svarkvalitet når de konfigurerer agentene sine.
«Leveringstakten er ikke lenger flaskehalsen – det er menneskers oppmerksomhet. Vi nærmer oss en verden der hver utvikler er en produktleder som leder en flåte av agenter.»
Asana bruker nå GPT‑6 Astra i Codex til å teste produktfunksjoner før lansering: Astra navigerer på plattformen, prøver ulike inndata og rapporterer feil til menneskelige kvalitetssikrere. Hidalgo ser dette som grunnlaget for en ny livssyklus for programvareutvikling, der mange skybaserte agentøkter tester funksjoner parallelt.
Hele studien er tilgjengelig på bloggene til Asana(åpnes i et nytt vindu) og StackAI(åpnes i et nytt vindu).
