Nyhet

Asana sänkte kostnaden 76 gånger för sin webbläsaragent med OpenAI:s GPT-6.1 Sol

Asana har gjort webbläsaragenten i plattformen StackAI 76 gånger billigare och 5 gånger snabbare i tester, enligt OpenAI. Optimeringen gjordes på modellen GPT-6.1 Sol med hjälp av GPT-6 Astra i Codex och beskrevs den 9 oktober 2026. Den genomsnittliga modellkostnaden landade på 0,47 dollar per körning, och Asana har redan släppt ändringarna i StackAI.

Det viktigaste i korthet

• Asana optimerade webbläsaragenten i StackAI på OpenAI:s modell GPT-6.1 Sol och använde GPT-6 Astra i Codex för att köra experimenten.

• Enligt OpenAI blev den optimerade lösningen 76 gånger billigare och 5 gånger snabbare än den ursprungliga produktionsmiljön på Modell B, en konkurrerande modell.

• Den uppskattade modellkostnaden var i snitt 0,47 dollar per körning, och en körning tog omkring fyra minuter.

• Studien omfattade 144 körningar med GPT-6.1 Sol och tre andra ledande modeller, kallade Modell A, B och C.

• Med större historikbudget gav alla 18 körningar på GPT-6.1 Sol rätt svar, mot tre av 18 med den mindre budgeten.

• Asana har släppt ändringarna i StackAI. Arbetet tog enligt StackAI:s teknikchef ungefär en vecka, mot en uppskattad till två månader för hand.

Vad har hänt

Asana hjälper kunder att automatisera arbete över affärssystem via StackAI, en plattform som bolaget har förvärvat. Där kan kunder bygga arbetsflöden som navigerar webbplatser, fyller i formulär och samlar information utan att skriva kod. I Asanas skala läggs små ineffektiviteter ihop till stora kostnader.

StackAI:s teknikchef Frank Hidalgo ville göra webbläsaragenten snabbare och billigare. Han lät GPT-6 Astra i Codex kartlägga koden och undersöka agenten. Astra fann att agenten cachade sina fasta instruktioner och verktygsdefinitioner, men inte den växande historiken av sidtext och skärmdumpar. Därför skickades historiken om och om igen till fullt pris. Agenten tog dessutom bort äldre skärmdumpar och kortade ned text nästan varje steg. Varje sådan ändring förändrade historiken, så enbart cachning av den hade inte hjälpt. Förlorad information kunde dessutom tvinga agenten att besöka redan lästa sidor igen.

Hidalgo valde tre åtgärder att testa: utökad cachning av webbhistoriken, mer kvarhållen text och borttagning av skärmdumpar i omgångar i stället för varje steg. Eftersom koden inte var gjord för kontrollerade experiment skrev Astra om den så att en frontend och en backend kunde köra många arbetsflöden parallellt med egna inställningar. Studien testade två historikbudgetar, 120 000 och 480 000 tecken, och sex cachnings- och skärmdumpsregler. Varje variant kördes tre gånger på fyra modeller. Uppgiften var att hämta sex fält för 32 böcker från en offentlig demokatalog.

Den bästa regeln lät skärmdumpar samlas upp till 20 innan bara den senaste behölls. Då förblev tidigare historik oförändrad längre och cachen kunde användas. Tillsammans med den större budgeten blev det det optimerade arbetsflödet. Modell A beskrivs som en mindre och billigare modell från en annan labb, till hälften av GPT-6.1 Sols pris. Modell B var den ursprungliga produktionsmodellen, och Modell C en nyare version av den. B och C kostar lika mycket som GPT-6.1 Sol.

För Modell B sjönk den uppskattade kostnaden från minst 36,21 dollar till 1,24 dollar per körning, 29 gånger lägre. Vissa ursprungliga körningar nådde stegbegränsningen innan de blev klara, så siffran är en nedre gräns. På GPT-6.1 Sol blev det ytterligare 2,6 gånger billigare, till 0,47 dollar. På GPT-6.1 Sol enbart sänkte den nya regeln kostnaden fyra gånger, från 1,97 till 0,47 dollar. Varje anrop blev ungefär tre gånger billigare, eftersom 89 procent av indata kom från cachen till 5 procent av okachat pris. Körtiden gick från minst 22,5 minuter till cirka fyra minuter.

Astra körde arbetsflödena och granskade förfrågningar, användningsdata och resultat, medan separata modellsessioner granskade arbetet. Allt loggades i Asanas leveransplattform Command och gick därifrån via ärenden och pull requests till produktion. Asana använder nu även Astra för att testa produktfunktioner före lansering och rapportera buggar till mänskliga QA-granskare. Bolaget vill dessutom bygga in kostnads-, körtids- och kvalitetsjämförelser i plattformens utvärderingar. Hidalgo säger att kostnaden tidigare begränsade vilka modeller kunderna kunde erbjudas.

Vad det betyder för dig i Sverige

Källan säger ingenting om svenska kunder, svenska priser eller tillgänglighet i Sverige. Fallstudien är markerad som ett företagsfall från Nordamerika. Om du använder StackAI eller Asana kan du ändå notera att Asana har släppt de nya ändringarna för webbläsarnavigering i StackAI. Källan anger inte när de når enskilda kunder eller i vilka regioner. Mer allmänt visar fallet att cachning och hantering av historik kan påverka kostnaden för AI-agenter mycket, enligt Asanas egna tester.

Det här vet vi inte än

• Hur resultaten ser ut för andra uppgifter än den testade, där agenten hämtade data om 32 böcker från en offentlig demokatalog. Asana säger att uppgiften är representativ för vad vissa kunder kör.

• Vilka modeller A, B och C är. Källan namnger dem inte.

• Hur mycket kunderna faktiskt sparar. Siffrorna är uppskattade modellkostnader och medelvärden av tre körningar.

• Om och när funktionerna finns tillgängliga för kunder i Sverige, och till vilket pris.

• När Asana lägger in testverktygen för jämförelse av kostnad, körtid och svarskvalitet i plattformen. Bolaget säger bara att det planerar det "över tid".