GPT-6.1 Sols 76x Browser-Agent-resultat: Vad Asana faktiskt mätte

Asana publicerade en kostnadsstudie för webbläsaragent den 8 oktober 2026, och utvecklaren bakom GPT-6.1 Sol skrev om den dagen därpå under rubriken "Asana sänker modellkostnader 76x i webbläsartester med GPT-6.1 Sol." 76x är verkligt i den meningen att någon har mätt det, men det är inte ett faktum om GPT-6.1 Sols pris. Det är ett faktum om vad som händer när man åtgärdar en trasig prompt-cache på en webbläsaragent och sedan byter ut modellen som ligger bakom den. Samma optimering, körd på modellen som Asana redan hade i produktion – en modell som företaget kallar Model B – sänkte kostnaden 29x på egen hand. GPT-6.1 Sol stod för de återstående 2,6x. Experimenten kördes av GPT-6 Astra som arbetade i Codex, och modellen bakom baslinjen är en modell från en konkurrent som Asana kallar Model B, så två nivåer från samma leverantör och en namnlös konkurrent figurerar alla i berättelsen. Det som följer skiljer den del av resultatet som du kan kopiera på måndag från den del som hör till Asanas specifika stack.

Jämförelsen, exakt formulerad

Asanas stack för detta är StackAI, plattformen för arbetsflödesautomatisering som företaget förvärvade, som kör en webbläsaragent som navigerar på webbplatser, fyller i formulär och samlar in information utan kod. Testuppgiften var snäv och konkret: samla in sex fält för var och en av 32 böcker från en offentlig demokatalog. Det är representativt för sådant som vissa kunder kör, och det är också tillräckligt litet för att en studie med 144 körningar ska rymmas på en vecka.

Designen var sex policyer för cachning och skärmbilder vid två historikbudgetar, tre körningar per betingelse, över fyra modeller – 144 körningar, plus en uppföljning med 12 körningar. Kostnader beräknades utifrån varje leverantörs egna token-räknare, och varje svar poängsattes mot en oberoende framtagen referens. De fyra modellerna var tre namnlösa frontiermodeller (Modell A, B och C) och GPT-6.1 Sol. Modell A är en mindre, billigare modell från ett annat labb, släppt hösten 2025, prissatt till hälften av GPT-6.1 Sol. Modell B är modellen som var i produktion, samma labb som A, släppt sommaren 2026, prissatt samma som GPT-6.1 Sol. Modell C är en nyare version av Modell B, släppt hösten 2026, även den prissatt samma som GPT-6.1 Sol. De tre är namnlösa i båda texterna, så jämförelsen är inte möjlig att reproducera för en läsare – värt att veta innan du behandlar 29x som en siffra om någon annans modell. Detta är Asanas och OpenAIs publicerade siffror, inte oberoende granskade sådana.

Resultatstegen, alla Asanas egna siffror:

• Baslinjeproduktion på Model B — minst $36,21 per körning, minst 22,5 minuter per körning. Vissa baslinjekörningar nådde steggränsen innan de slutfördes, så medelvärdet är en undre gräns snarare än ett verkligt genomsnitt.

• Model B, optimerad agent – 1,24 $ per körning, 4x snabbare än baslinjen, en 29x kostnadsminskning.

• GPT-6.1 Sol, samma optimerade agent — 0,47 $ per körning, ungefär fyra minuter, 76x lägre kostnad och 5x snabbare.

• GPT-6.1 Sol, före vs. efter fixen — $1.97 till $0.47 per körning, en 4x-minskning enbart från cache- och pruning-ändringar.

Eftersom baslinjen är en undre gräns är 76x i sig självt ett golv. Den ärliga tolkningen är "minst 76x", inte "76x".

Vad förändrades egentligen, och varför det inte är en modellfunktion

Mekanismen är prompt-cache-mekanik, och den är värd att förstå eftersom den överförs till vilken agent som helst som du kör på vilken modell som helst. En webbläsaragent återskickar sina verktyg, sin systemprompt och sin växande historik av sidtext och skärmbilder vid varje modellanrop. Prompt-cachning rabatterar den upprepade delen, men bara det längsta oförändrade prefixet – i samma stund som något i mitten av begäran ändras, bryts återanvändningen från och med den punkten.

Asanas produktionsagent hade två fel som förstärkte varandra. Den cachelagrade sina fasta instruktioner och verktygsdefinitioner men inte sin surfhistorik. Och den redigerade historiken vid nästan varje steg: den tog bort den föregående skärmbilden varje gång och trimmade äldre text för att rymmas inom en historikbudget. Varje redigering ogiltigförklarade prefixet, så cachelagring skulle ha varit nästan värdelös även om den hade slagits på. Asanas redogörelse noterar att för de testade modellerna kostade cacheläsningar 0,05x till 0,1x av standardpriset för indata — så vinsten var stor och agenten vägrade systematiskt att ta den.

Åtgärden har två delar. För det första: cachelagra även historiken, med en cachemarkör på det senaste verktygsresultatet. För det andra: sluta redigera den vid varje anrop: behåll skärmbilder och rensa dem i omgångar i förhållandet 20 mot 1, så att agenten håller upp till 20 och sedan skär ned till den senaste. Omkring 19 anrop i följd återanvänder då ett oförändrat prefix. Höj historikbudgeten från 120 000 till 480 000 tecken så att gammal text slutar trimmas, och räkningen går ihop: på GPT-6.1 Sol kostade varje anrop ungefär 3 gånger mindre eftersom 89 % av indata kom från cachen.

Den mest betydelsefulla upptäckten här är en negativ sådan. Att cachelagra historiken utan batchbeskärning, vid den större budgeten, kostade mer än att inte cachelagra alls på tre av de fyra modellerna – cachen skrevs kontinuerligt om och lästes sällan. Cacheinfrastruktur som slås på utan en historikdisciplin med enbart tillägg är ett sätt att betala en extra skrivkostnad helt i onödan. Det felscenariot är modelloberoende, och det är anledningen till att samma åtgärd förbättrade Model B med 29x.

Där modellvalet faktiskt lönade sig

Rensa bort arbetsflödeskorrigeringen och jämför på jämförbara grunder: med samma optimerade agent var GPT-6.1 Sol 2,6x billigare än Model B, till samma listpris. Den extra faktorn är cacheträffbeteendet, inte prislistan. Sol läste 89 % av sin indata från cachen; Asana publicerar inte motsvarande andel för Model B, så 2,6x är ett uppmätt resultat utan en publicerad uppdelning. Betrakta det som ”den här modellen, med den här arbetsbelastningen, använde sin cache bättre”, inte som en generell 2,6x fördel gentemot en modell vi inte kan namnge.

Körtidssidan är entydig: 5 gånger snabbare än baslinjen, med det optimerade Sol-arbetsflödet på ungefär fyra minuter mot en baslinje på minst 22,5 minuter. Hastighet har betydelse för kostnaden i agenter som fakturerar per token, eftersom en långsam modell som loopar betalar för sina loopar.

För den som räknar på detta: GPT-6.1 Sols standard-API-priser är 2,00 USD per miljon indatatoken, 0,10 USD per miljon cachade indatatoken och 10,00 USD per miljon utdatatoken, och cache-läsningsrabatten är 0,05 gånger indatapriset – den djupaste på OpenAI:s nuvarande prislista. GPT-6 Astra, modellen som gjorde ingenjörsarbetet i Codex, kostar 10,00 USD för indata och 50,00 USD för utdata, vilket är den femfaldiga skillnad som OpenAI:s lanseringskommunikation lutade sig mot. Anledningen till att studien gav körningar på 0,47 USD i stället för 2 USD är inte prislistan; det är att 89 % av en mycket repetitiv förfrågan fakturerades till en tjugondel av indatapriset. För en cache-tung agent spelar rabattraden större roll än rubrikpriset, och i vår egen katalog förs leverantörernas listpriser vidare med 0 % påslag, så när en leverantör ändrar en mätare för cachad indata ändras den på din faktura samma dag.

Det andra numret i studien: historikbudgeten avgjorde huruvida agenten överhuvudtaget svarade

Kostnad per körning är siffran som alla citerar, men studiens mer användbara resultat handlar om tillförlitlighet, och det är det en operatör bör läsa först.

• Vid teckenbudgeten på 120 000 tecken svarade Model C inte i någon av sina 18 körningar, och GPT-6.1 Sol svarade i 3 av 18 – de flesta körningarna nådde steggränsen utan att producera ett svar.

• Vid 480 000 tecken svarade varje körning på båda modellerna, var och en med rätt svar.

• De nyare modellerna förbrukade den mindre budgeten snabbare: Modell C kortade först sin historik vid anrop 10, Modell A vid anrop 64.

• I det optimerade arbetsflödet slutförde varje körning uppgiften och returnerade rätt svar, och varje körning under bästa förhållanden på varje modell stötte på alla 192 fakta som den skulle samla in.

Det är ett annat argument än ”billigare”. En för liten historikbudget på en kapabel modell ger en agent som misslyckas genom att få slut på utrymme, och den misslyckas genom att nå steggränsen, vilket är det dyraste sättet att misslyckas – du betalar för hela körningen och får ingenting. Att höja budgeten höjde kostnaden per anrop och sänkte kostnaden per svar, vilket är det enda tal en produktionsägare bör följa. Om du utvärderar en obeprövad modell för en agent som denna är det lågriskmönstret att behålla din produktionsväg på modellen du litar på och sätta den nya bakom en failover eller en delad väg, så att ett steggränsmisslyckande visas som ett routingfaktum i stället för en incident. Varje modell i den här jämförelsen nås via ett API för 200+ modeller med leverantörernas listpriser vidarebefordrade oförändrade, vilket också gör cache-läsningsrabatten jämförbar mellan leverantörer på samma faktura i stället för fem instrumentpaneler.

Vad man ska ta med sig av detta, i tur och ordning

Om du kör en webbläsar- eller datoranvändningsagent finns det tre spakar i Asanas studie som är värda att dra i innan du tittar på en prislista:

• Gör förfrågningsprefixet endast tilläggsbart. Varje redigering per anrop i mitten av historiken nollställer återanvändningen av cachen från den punkten och framåt.

• Beskär i batchar. Asanas uppföljning visade att bevarandet av varje skärmdump kostade 1,2x mindre per anrop än det bästa beskärningsvillkoret på Modell B och GPT-6.1 Sol, och cirka 5 % mindre på Modell C. Beskärning är fortfarande viktigt för långa uppgifter, små kontextfönster och dyra cacheläsningar — men argumentet för en batchkvot på 20:1 handlar om cachestabilitet, inte om själva skärmdumparna.

• Ställ in historikbudgeten per modell och kontrollera den mot din steggräns. En budget som räcker för en modell kan svälta nästa.

Två skyddsräcken från studien är lätta att hoppa över och borde inte vara det. Ingen körning nådde budgeten på 480 000 tecken, så budgeten begränsade aldrig dessa körningar – men en driftande agent växer mot sin kontextgräns, och om cachen går sönder betalar varje anrop fullt pris. Tak för steg, tokens och kostnad per körning är det som begränsar en dålig körning. Separat använde studien tre eller fyra körningar per villkor med varierande antal anrop, vilket Asana själva säger är tillräckligt för att visa övergripande mönster men inte tillräckligt för att skilja villkor som ligger några procent från varandra. Läs inte ut en skillnad på 5 % ur detta och bygg inte om din pipeline kring det.

Den del som är genuint ny, och den del som inte är det

Förbehållen kring upplägget är värda att sägas rakt ut: fyra modeller, tre av dem namnlösa, en snäv 32-boksuppgift, Asanas egna instrumenterade räknare och en leverantörs egen redogörelse som presenterar resultatet. Inget här har reproducerats utanför Asana. Men mekanismen är fullständigt specificerad — endast tilläggshistorik, cache-markör på det senaste verktygsresultatet, batch-beskärning, större budget, mät cache-läsningar med leverantörens räknare — och det är den typen av fynd som överlever att tillskrivas fel labb. 76x är ett Asana-tal på en Asana-arbetsbelastning. Anledningen till att den är värd att läsa är att den demonstrerar en regel du kan testa på en eftermiddag: en agent som redigerar sin egen historik vid varje steg betalar fullt pris för en konversation den redan har haft.