Asana sänker modellkostnaden till 1/76 i test med GPT‑6.1 Sol
Med GPT‑6 Astra i Codex sänkte Asana webbläsaragentens kostnad till 1/76 och gjorde den 5 gånger snabbare i tester för att erbjuda kunderna mer kapabla modeller.
76×
Lägre uppskattade modellkostnader med det optimerade arbetsflödet för GPT-6.1 Sol
5×
Snabbare webbläsarkörningar med det optimerade arbetsflödet för GPT-6.1 Sol
0,47 USD
Genomsnittlig uppskattad modellkostnad med det optimerade arbetsflödet för GPT-6.1 Sol
Genom att låta GPT‑6 Astra i Codex utföra experiment optimerade Asana arbetsflödet för sin webbläsaragent på GPT‑6.1 Sol. Kostnaden sjönk till en sjuttiosjättedel och körningarna blev fem gånger snabbare.
Asana hjälper kunder att automatisera arbete i olika verksamhetsapplikationer genom StackAI(öppnas i ett nytt fönster), en plattform som företaget har förvärvat(öppnas i ett nytt fönster). Med StackAI kan kunder skapa arbetsflöden som navigerar på webbplatser, fyller i formulär och samlar in information utan att skriva kod. I Asanas skala blir även små ineffektiviteter i dessa arbetsflöden betydande.
Frank Hidalgo, PhD och teknikchef för StackAI på Asana, ville göra webbläsaragenten snabbare och billigare att köra. Han gav GPT‑6 Astra i Codex i uppdrag att undersöka agenten, testa förbättringar och jämföra resultaten. Ett arbete som han uppskattar skulle ha tagit en till två månader manuellt tog ungefär en vecka.
I Asanas studie med 144 körningar(öppnas i ett nytt fönster) testades GPT‑6.1 Sol och tre andra banbrytande modeller, här kallade Modell A, B och C. Det optimerade arbetsflödet på GPT‑6.1 Sol gav en uppskattad modellkostnad på i genomsnitt 0,47 USD och en körtid på cirka fyra minuter per körning. Det var en sjuttiosjättedel av kostnaden och fem gånger snabbare än den ursprungliga produktionskonfigurationen med Modell B.
”Så här ser team av människor och agenter ut i praktiken. En ingenjör stakade ut riktningen, GPT-6 Astra genomförde experimenten och resultaten gick via Command till produktion. Det visar hur Asana gör team av människor och agenter till verklighet.”
För att snabbt komma framåt började Hidalgo med att använda GPT‑6 Astra i Codex för att kartlägga kodbasen och förklara hur agenten byggde upp varje modellanrop. GPT‑6 Astra upptäckte att agenten cachelagrade sina fasta instruktioner och verktygsdefinitioner, men inte den växande historiken av sidtext och skärmbilder som den samlade in. Därför skickades hela historiken på nytt till fullt pris vid varje anrop.
Agenten tog också bort äldre skärmbilder och kortade ned text vid nästan varje steg. Varje ändring påverkade historiken, så det hade inte räckt att bara cachelagra den. När informationen försvann kunde agenten dessutom behöva återvända till sidor som den redan hade läst.
Hidalgo granskade GPT‑6 Astras förbättringsförslag och valde ut tre att testa:
Utöka cachelagringen till att omfatta agentens webbhistorik
Öka mängden text som agenten kunde behålla
Ta bort skärmbilder i omgångar i stället för vid varje steg
GPT‑6 Astra började med snabba tester för att fastställa vilka variabler som hade betydelse. Eftersom koden inte var utformad för kontrollerade experiment omstrukturerade Astra den sedan så att samma frontend och backend kunde stödja många parallella arbetsflöden, vart och ett med egna inställningar.
Astra genomförde hela studien: historikutrymmen på 120 000 respektive 480 000 tecken och sex strategier för cachelagring och skärmbilder, var och en testad tre gånger på var och en av de fyra modellerna (se tabellen nedan). Den strategi som fungerade bäst lät antalet skärmbilder växa till 20 innan alla utom den senaste togs bort. Det innebar att tidigare historik förblev oförändrad under längre perioder mellan rensningarna. Tillsammans med det större historikutrymmet blev detta det optimerade arbetsflödet. Varje konfiguration utförde samma uppgift: att samla in sex fält för var och en av 32 böcker från en offentlig demokatalog. Uppgiften var representativ för vad vissa Asana-kunder kör i StackAI.
Modell | Beskrivning | Pris |
|---|---|---|
Modell A | En mindre, billigare modell från ett annat labb för banbrytande AI, lanserad hösten 2025 | Halva priset jämfört med GPT‑6.1 Sol |
Modell B | Modellen som ursprungligen användes i produktion, från samma labb som Modell A, lanserad sommaren 2026 | Samma pris som GPT‑6.1 Sol |
Modell C | En uppdaterad version av Modell B, lanserad hösten 2026 | Samma pris som GPT‑6.1 Sol |
GPT‑6.1 Sol | OpenAI:s modell |
GPT‑6 Astra körde arbetsflödena och undersökte anropen, användningsloggarna och utdata. Arbetet granskades sedan i separata modellsessioner. Anrop, dataspår och resultat från varje session registrerades i Command(öppnas i ett nytt fönster), Asanas plattform för mjukvaruleverans, så att teamet kunde granska hela studien i efterhand. Utifrån resultaten i Command skapades ärenden och sedan pull requests, varefter ändringarna sattes i produktion.
”Det här skulle ha tagit mig en till två månader att göra manuellt. Med GPT-6 Astra i Codex tog det ungefär en vecka: jag angav ett /goal innan jag gick och lade mig och granskade resultaten på morgonen.”
För Modell B sänkte optimeringen den uppskattade modellkostnaden från minst 36,21 USD (vissa ursprungliga körningar nådde steggränsen innan de slutfördes) till 1,24 USD per körning, alltså till en tjugoniondel. Med det optimerade arbetsflödet på GPT‑6.1 Sol blev kostnaden ytterligare 2,6 gånger lägre: 0,47 USD. Varje körning med det optimerade arbetsflödet slutförde uppgiften och gav rätt svar.
Medelvärden för 3 körningar. ≥: baslinjen omfattar körningar som nått gränsen, så medelvärdet är en undre gräns.
De två faktorerna till höger visar jämförelsen med optimerad Modell B. Modell B kördes i fas 1, Modell C och Sol 6.1 i fas 2 av samma studie (prickad linje).
Enbart på GPT‑6.1 Sol, med det större historikutrymmet, sänkte den nya strategin för cachelagring och skärmbilder kostnaden till en fjärdedel, från 1,97 till 0,47 USD per körning. Varje anrop kostade ungefär en tredjedel så mycket, eftersom 89 % av indata hämtades från cachen till 5 % av priset för icke-cachelagrade data. Körningarna blev också snabbare: minst 22,5 minuter med den ursprungliga konfigurationen på Modell B, jämfört med ungefär fyra minuter med det optimerade arbetsflödet på GPT‑6.1 Sol.
Medelvärde för 3 körningar, felstaplar visar standardavvikelsen. ≥: medelvärdet omfattar en körning som nått gränsen eller inte slutförts, så det verkliga värdet är minst så stort.
Staplarna använder det blå temat. Bedöm effekten av cachelagring genom att jämföra med stapeln för det större historikutrymmet på 480 000 tecken.
Körningsmarkörer och felstaplar för standardavvikelse är ungefärliga rekonstruktioner från källbilden. Underliggande körningsvärden och standardavvikelser fanns inte tillgängliga.
Medelvärde för 3 körningar, felstaplar visar standardavvikelsen. ≥: medelvärdet omfattar en körning som nått gränsen eller inte slutförts, så det verkliga värdet är minst så stort.
Staplarna använder det blå temat. Bedöm effekten av cachelagring genom att jämföra med stapeln för det större historikutrymmet på 480 000 tecken.
Körningsmarkörer och felstaplar för standardavvikelse är ungefärliga rekonstruktioner från källbilden. Underliggande körningsvärden och standardavvikelser fanns inte tillgängliga.
Undersökningen visade också hur hanteringen av historiken påverkade om agenten alls gav något svar. När GPT‑6.1 Sol fick mer utrymme att behålla sin webbhistorik ökade antalet körningar som gav ett svar från tre av 18 med det mindre historikutrymmet till alla 18 med det större. Samtliga gav rätt svar. För Hidalgo ligger affärsvärdet i att ge kunderna tillgång till snabbare och mer kapabla modeller, samtidigt som driftskostnaderna hålls på en hållbar nivå.
”Tidigare begränsade kostnaden vilka modeller vi kunde erbjuda kunderna för de här arbetsuppgifterna. Genom att göra agenten effektivare kan vi ge kunderna en bättre och snabbare modell och samtidigt sänka våra driftskostnader.”
Asana har lanserat ändringarna för webbläsarnavigering i StackAI och utvecklar verktyg som gör liknande experiment enklare att upprepa. På sikt planerar teamet att integrera dessa tester i plattformens utvärderingar, så att kunder och interna team kan jämföra kostnad, körtid och svarskvalitet när de konfigurerar sina agenter.
”Det är inte längre leveranstakten som är flaskhalsen, utan människors uppmärksamhet. Vi närmar oss en värld där varje ingenjör är en produktchef som leder en hel grupp agenter.”
Asana använder nu GPT‑6 Astra i Codex för att testa produktfunktioner före lansering: Astra navigerar på plattformen, provar olika indata och rapporterar buggar till mänskliga kvalitetssäkrare. Hidalgo ser detta som grunden för en ny livscykel för mjukvaruutveckling, där många agentsessioner i molnet testar funktioner parallellt.
Hela studien finns på bloggarna hos Asana(öppnas i ett nytt fönster) och StackAI(öppnas i ett nytt fönster).
