GPT-6.1 Sol's 76x Browser-Agent-resultaat: wat Asana daadwerkelijk heeft gemeten

Asana publiceerde op 8 oktober 2026 een kostenstudie over browser-agents, en de ontwikkelaar van GPT-6.1 Sol schreef er de volgende dag een stuk over onder de kop "Asana verlaagt modelkosten 76x in browsertests met GPT-6.1 Sol." De 76x is echt in de zin dat iemand die heeft gemeten, maar het is geen feit over de prijs van GPT-6.1 Sol. Het is een feit over wat er gebeurt als je een kapotte promptcache op een browser-agent repareert en vervolgens het model dat erachter zit verwisselt. Dezelfde optimalisatie, uitgevoerd op het model dat Asana al in productie had — een model dat het Model B noemt — verlaagde de kosten op zichzelf met 29x. GPT-6.1 Sol leverde de resterende 2,6x. De experimenten werden uitgevoerd door GPT-6 Astra werkend in Codex, en het model achter de baseline is het model van een concurrent dat Asana Model B noemt, dus twee tiers van dezelfde leverancier en één naamloze rivaal komen allemaal in het verhaal voor. Wat volgt scheidt het deel van het resultaat dat je maandag kunt kopiëren van het deel dat bij Asana's specifieke stack hoort.

De vergelijking, exact weergegeven

Asana's stack hiervoor is StackAI, het workflowautomatiseringsplatform dat het heeft overgenomen, waarop een browseragent draait die websites navigeert, formulieren invult en informatie verzamelt zonder code. De testtaak was beperkt en concreet: verzamel zes velden voor elk van de 32 boeken uit een openbare demo-catalogus. Dat is representatief voor wat sommige klanten uitvoeren, en het is ook klein genoeg dat een studie van 144 runs in een week past.

De opzet bestond uit zes beleidsregels voor caching en screenshots bij twee geschiedenisbudgetten, drie runs per conditie, over vier modellen — 144 runs, plus een follow-up van 12 runs. Kosten werden berekend op basis van de eigen token-tellers van elke provider, en elk antwoord werd beoordeeld aan de hand van een onafhankelijk opgestelde referentie. De vier modellen waren drie naamloze frontier-modellen (Modellen A, B en C) en GPT-6.1 Sol. Model A is een kleiner, goedkoper model van een ander lab, uitgebracht in het najaar van 2025, voor de helft van de prijs van GPT-6.1 Sol. Model B is het model dat in productie was, hetzelfde lab als A, uitgebracht in de zomer van 2026, voor dezelfde prijs als GPT-6.1 Sol. Model C is een nieuwere versie van Model B, uitgebracht in het najaar van 2026, ook voor dezelfde prijs als GPT-6.1 Sol. De drie zijn in beide verslagen niet bij naam genoemd, dus de vergelijking kan door een lezer niet worden gereproduceerd — goed om te weten voordat je 29x als een getal over andermans model beschouwt. Dit zijn de gepubliceerde cijfers van Asana en OpenAI, geen onafhankelijk gecontroleerde cijfers.

De ladder van resultaten, allemaal Asana's eigen cijfers:

• Baselineproductie op Model B — ten minste $36,21 per run, ten minste 22,5 minuten per run. Sommige baselineruns bereikten de stappenlimiet voordat ze klaar waren, dus het gemiddelde is een ondergrens in plaats van een werkelijk gemiddelde.

• Model B, geoptimaliseerde agent — $1,24 per run, 4x sneller dan de baseline, een 29x kostenreductie.

• GPT-6.1 Sol, dezelfde geoptimaliseerde agent — $ 0,47 per run, ongeveer vier minuten, een 76x kostenreductie en 5x sneller.

• GPT-6.1 Sol, voor vs. na de fix — $1,97 naar $0,47 per run, een 4x verlaging alleen al door cache- en pruningwijzigingen.

Omdat de baseline een ondergrens is, is 76x zelf een ondergrens. De eerlijke lezing is "ten minste 76x", niet "76x".

Wat er werkelijk is veranderd, en waarom het geen modelfunctie is

Het mechanisme is prompt-cache-mechanica, en het is de moeite waard om te begrijpen omdat het overdraagbaar is naar elke agent die je op welk model dan ook draait. Een browseragent stuurt bij elke modelaanroep zijn tools, zijn systeemprompt en zijn groeiende geschiedenis van paginatekst en screenshots opnieuw mee. Promptcaching geeft korting op het herhaalde deel, maar alleen op de langste ongewijzigde prefix — op het moment dat iets in het midden van het verzoek verandert, breekt hergebruik vanaf dat punt af.

De productieagent van Asana had twee fouten die elkaar versterkten. Hij cachete zijn vaste instructies en tooldefinities, maar niet zijn browsegeschiedenis. En hij bewerkte die geschiedenis bij bijna elke stap: hij liet elke keer de vorige schermafbeelding vallen en kortte oudere tekst in om binnen een geschiedenisbudget te passen. Elke bewerking maakte het voorvoegsel ongeldig, dus caching zou bijna nutteloos zijn geweest, zelfs als het was aangezet. In het verslag van Asana staat dat bij de geteste modellen het lezen uit de cache 0,05x tot 0,1x de standaard invoerprijs kostte — dus de winst was groot en de agent weigerde er stelselmatig gebruik van te maken.

De oplossing bestaat uit twee delen. Ten eerste: cache ook de geschiedenis, met een cachemarkering op het nieuwste toolresultaat. Ten tweede: stop met het bij elke aanroep bewerken ervan: bewaar screenshots en snoei ze in batches in een verhouding van 20 op 1, zodat de agent er maximaal 20 aanhoudt en daarna terugbrengt tot de meest recente. Ongeveer 19 opeenvolgende aanroepen hergebruiken dan een ongewijzigde prefix. Verhoog het geschiedenisbudget van 120.000 naar 480.000 tekens zodat oude tekst niet meer wordt bijgesneden, en de rekensom klopt: op GPT-6.1 Sol kostte elke aanroep ongeveer 3x minder omdat 89% van de invoer uit cache kwam.

De bevinding die hier het meest van belang is, is een negatieve. Het cachen van de geschiedenis zonder batch-pruning, bij het grotere budget, kostte meer dan helemaal niet cachen bij drie van de vier modellen — de cache werd voortdurend herschreven en zelden gelezen. Cache-infrastructuur die wordt ingeschakeld zonder een append-only discipline voor de geschiedenis is een manier om voor niets een schrijfpremie te betalen. Die faalmodus is modelonafhankelijk, en het is de reden dat dezelfde oplossing Model B met een factor 29 verbeterde.

Waar de modelkeuze daadwerkelijk loonde

Haal de workflow-fix eruit en vergelijk appels met appels: bij dezelfde geoptimaliseerde agent was GPT-6.1 Sol 2,6x goedkoper dan Model B, tegen dezelfde lijstprijs. De extra factor is cache-hitgedrag, niet de tariefkaart. Sol las 89% van zijn input uit cache; Asana publiceert het equivalente aandeel voor Model B niet, dus de 2,6x is een gemeten uitkomst zonder gepubliceerde decompositie. Behandel het als "dit model gebruikte op deze workload zijn cache beter", niet als een algemeen voordeel van 2,6x ten opzichte van een model dat we niet kunnen noemen.

De runtime-kant is onmiskenbaar: 5x sneller dan de baseline, met de geoptimaliseerde Sol-workflow op ongeveer vier minuten tegenover een baseline van minstens 22,5 minuten. Snelheid is van belang voor de kosten bij agents die per token factureren, omdat een traag model dat lussen maakt, betaalt voor zijn lussen.

Voor iedereen die dit doorrekent: de standaard API-tarieven van GPT-6.1 Sol zijn $2,00 per miljoen inputtokens, $0,10 per miljoen gecachte inputtokens en $10,00 per miljoen outputtokens, en de cache-leeskorting is 0,05x het inputtarief — de diepste op de huidige prijskaart van OpenAI. GPT-6 Astra, het model dat het engineeringwerk in Codex deed, kost $10,00 input en $50,00 output, het vijfvoudige verschil waar de lanceringsframing van OpenAI op leunde. De reden dat de studie runs van $0,47 opleverde in plaats van runs van $2 is niet de tariefkaart; het is dat 89% van een zeer repetitief verzoek werd gefactureerd tegen een twintigste van het inputtarief. Bij een agent met veel caching doet de kortingsregel meer werk dan de koprijs, en in onze eigen catalogus worden listprijzen van providers doorgegeven met 0% opslag, dus als een leverancier een meter voor gecachte input aanpast, past hij die dezelfde dag op je factuur aan.

Het andere getal in de studie: het geschiedenisbudget bepaalde of de agent überhaupt antwoordde

Kosten per run is het getal dat iedereen citeert, maar het nuttigere resultaat van de studie gaat over betrouwbaarheid, en dat is het resultaat dat een operator als eerste zou moeten lezen.

• Bij het budget van 120.000 tekens gaf Model C in geen van zijn 18 runs een antwoord en GPT-6.1 Sol gaf in 3 van de 18 een antwoord — de meeste runs bereikten de stappenlimiet zonder een antwoord te produceren.

• Bij 480.000 tekens gaf elke run op beide modellen een antwoord, elk met het juiste antwoord.

• De nieuwere modellen verbruikten het kleinere budget sneller: Model C kortte zijn geschiedenis voor het eerst in bij aanroep 10, Model A bij aanroep 64.

• In de geoptimaliseerde workflow voltooide elke run de taak en gaf het juiste antwoord terug, en elke run onder de beste omstandigheden op elk model kwam alle 192 feiten tegen die hij moest verzamelen.

Dat is een ander argument dan "goedkoper". Een te klein geschiedenisbudget op een capabel model levert een agent op die faalt doordat hij ruimte tekortkomt, en hij faalt doordat hij tegen de stappenlimiet aanloopt, wat de duurste manier van falen is — je betaalt voor de hele run en krijgt niets. Het verhogen van het budget verhoogde de kosten per aanroep en verlaagde de kosten per antwoord, wat het enige getal is dat een productie-eigenaar zou moeten volgen. Als je een onbewezen model evalueert voor een agent als deze, is het patroon met laag risico om je productieroute op het model te houden dat je vertrouwt en het nieuwe model achter een failover of een gesplitste route te zetten, zodat een fout door de stappenlimiet zich voordoet als een routeringsfeit in plaats van een incident. Elk model in deze vergelijking is bereikbaar via één API voor 200+ modellen waarbij de lijstprijzen van providers ongewijzigd worden doorgegeven, wat er ook voor zorgt dat de cache-leeskorting op dezelfde factuur vergelijkbaar is tussen leveranciers in plaats van op vijf dashboards.

Wat je hieruit moet meenemen, in volgorde

Als je een browser- of computer-use-agent draait, zijn er drie hefbomen in Asana's onderzoek die het waard zijn om aan te trekken voordat je naar een tariefkaart kijkt:

• Maak het prefix van het verzoek alleen-toevoegend. Elke wijziging per aanroep in het midden van de geschiedenis maakt cachehergebruik vanaf dat punt ongedaan.

• Snoei in batches. Uit het vervolgonderzoek van Asana bleek dat het bewaren van elke screenshot kostte 1,2x minder per call dan de beste snoeivoorwaarde op Model B en GPT-6.1 Sol, en ongeveer 5% minder op Model C. Snoeien blijft belangrijk voor lange taken, kleine contextvensters en dure cache-reads — maar het argument voor een batchratio van 20:1 draait om cachestabiliteit, niet om de screenshots zelf.

• Stel per model het geschiedenisbudget in en toets het aan je stappenlimiet. Een budget dat bij het ene model past, kan het volgende model uithongeren.

Twee vangrails uit de studie zijn makkelijk over te slaan, en dat zou niet moeten. Geen enkele run bereikte het budget van 480.000 tekens, dus dat budget heeft deze runs nooit beperkt — maar een afdrijvende agent groeit richting zijn contextlimiet, en als de cache breekt, betaalt elke aanroep de volle prijs. Limieten op stappen, tokens en kosten per run zijn wat een slechte run begrenst. Los daarvan gebruikte de studie drie of vier runs per conditie met variabele aantallen aanroepen, wat volgens Asana zelf genoeg is om brede patronen te laten zien en niet genoeg om condities die een paar procent van elkaar verschillen te onderscheiden. Lees hier geen delta van 5% uit en bouw je pipeline daar niet omheen.

Het deel dat echt nieuw is, en het deel dat dat niet is

De kanttekeningen bij de opzet zijn het waard om ronduit te noemen: vier modellen, waarvan drie naamloos, één smalle taak met 32 boeken, de eigen geïnstrumenteerde tellers van Asana, en een door de leverancier zelf geschreven verslag dat het resultaat host. Niets hiervan is buiten Asana gereproduceerd. Maar het mechanisme is volledig gespecificeerd — append-only geschiedenis, cachemarkering op het laatste toolresultaat, batch-pruning, een groter budget, cachereads meten met de tellers van de provider — en het is het soort bevinding dat blijft staan, zelfs als het aan het verkeerde lab wordt toegeschreven. De 76x is een Asana-getal op een Asana-workload. De reden dat het de moeite waard is om te lezen, is dat het een regel demonstreert die je in een middag kunt testen: een agent die bij elke stap zijn eigen geschiedenis bewerkt, betaalt de volle prijs voor een gesprek dat hij al heeft gehad.