Asana: 76× lagere modelkosten bij browsertests met GPT‑6.1 Sol
Met GPT‑6 Astra in Codex maakte Asana zijn browseragent in tests 76 keer goedkoper en 5 keer sneller, om klanten krachtigere modellen te bieden.
76x
Lagere geschatte modelkosten met de geoptimaliseerde GPT-6.1 Sol-workflow
5x
Snellere browserruns met de geoptimaliseerde GPT-6.1 Sol-workflow
$ 0,47
Gemiddelde geschatte modelkosten met de geoptimaliseerde GPT-6.1 Sol-workflow
Door GPT‑6 Astra in Codex experimenten te laten uitvoeren, optimaliseerde Asana de workflow van zijn browseragent op GPT‑6.1 Sol. Die werd daardoor 76 keer goedkoper en 5 keer sneller.
Asana helpt klanten werk in verschillende bedrijfsapplicaties te automatiseren met StackAI(opent in een nieuw venster), een platform dat het heeft overgenomen(opent in een nieuw venster). Met StackAI kunnen klanten zonder code te schrijven workflows bouwen die door websites navigeren, formulieren invullen en informatie verzamelen. Op de schaal waarop Asana werkt, tellen kleine inefficiënties in deze workflows flink op.
Dr. Frank Hidalgo, CTO van StackAI bij Asana, wilde de browseragent sneller en goedkoper laten werken. Hij gaf GPT‑6 Astra in Codex de opdracht de agent te onderzoeken, verbeteringen te testen en de resultaten te vergelijken. Werk dat hem naar eigen schatting handmatig één tot twee maanden zou hebben gekost, was in ongeveer een week klaar.
In Asana's onderzoek met 144 runs(opent in een nieuw venster) werden GPT‑6.1 Sol en drie andere grensverleggende modellen getest, hier Model A, B en C genoemd. De resulterende geoptimaliseerde workflow op GPT‑6.1 Sol kostte naar schatting gemiddeld $ 0,47 aan modelgebruik en duurde ongeveer vier minuten per run: 76 keer goedkoper en 5 keer sneller dan de oorspronkelijke productieconfiguratie op Model B.
"Zo werken teams van mensen en agents in de praktijk. Een ontwikkelaar bepaalde de richting, GPT-6 Astra voerde de experimenten uit en de resultaten gingen via Command naar productie. Dit laat zien hoe Asana samenwerking tussen mensen en agents werkelijkheid maakt."
Om snel vooruitgang te boeken, liet Hidalgo GPT‑6 Astra in Codex eerst de codebase in kaart brengen en uitleggen hoe de agent elk modelverzoek opbouwde. GPT‑6 Astra ontdekte dat de agent zijn vaste instructies en tooldefinities wel in de cache opsloeg, maar de groeiende geschiedenis van verzamelde paginatekst en screenshots niet. Bij elk verzoek werd die geschiedenis dus opnieuw verstuurd tegen het volledige tarief.
Daarnaast verwijderde de agent bij bijna elke stap oudere screenshots en kortte hij tekst in. Elke bewerking veranderde de geschiedenis, dus alleen caching van de geschiedenis zou niet hebben geholpen. Bovendien kon het verlies van die informatie de agent dwingen eerder gelezen pagina's opnieuw te bezoeken.
Hidalgo beoordeelde de voorgestelde oplossingen van GPT‑6 Astra en koos er drie om te testen:
Ook de browsegeschiedenis van de agent in de cache opslaan
De hoeveelheid tekst vergroten die de agent kon bewaren
Screenshots in batches verwijderen in plaats van bij elke stap
GPT‑6 Astra begon met korte tests om vast te stellen welke variabelen ertoe deden. Omdat de code niet was ontworpen voor gecontroleerde experimenten, herstructureerde het model vervolgens de code zodat één frontend en backend veel workflows parallel konden ondersteunen, elk met eigen instellingen.
Astra voerde het volledige onderzoek uit: geschiedenislimieten van 120.000 en 480.000 tekens en zes strategieën voor caching en screenshots, elk drie keer getest op elk van de vier modellen (zie de tabel hieronder). Bij de best presterende strategie mochten zich 20 screenshots verzamelen, waarna alleen het meest recente screenshot bewaard bleef. Zo bleef de eerdere geschiedenis langer ongewijzigd tussen de verwijdermomenten. Samen met de hogere geschiedenislimiet vormde dit de geoptimaliseerde workflow. Elke configuratie voerde dezelfde taak uit: zes velden verzamelen voor elk van 32 boeken uit een openbare democatalogus. Dit is representatief voor wat sommige Asana-klanten in StackAI uitvoeren.
Model | Beschrijving | Prijs |
|---|---|---|
Model A | Een kleiner, goedkoper model van een ander lab voor grensverleggend AI-onderzoek, uitgebracht in het najaar van 2025 | De helft van de prijs van GPT‑6.1 Sol |
Model B | Het model dat oorspronkelijk in productie werd gebruikt, van hetzelfde lab als Model A, uitgebracht in de zomer van 2026 | Dezelfde prijs als GPT‑6.1 Sol |
Model C | Een bijgewerkte versie van Model B, uitgebracht in het najaar van 2026 | Dezelfde prijs als GPT‑6.1 Sol |
GPT‑6.1 Sol | Het model van OpenAI |
GPT‑6 Astra voerde de workflows uit en onderzocht de verzoeken, gebruiksgegevens en uitvoer. Afzonderlijke modelsessies beoordeelden het werk. De verzoeken, datatraces en resultaten van elke sessie werden vastgelegd in Command(opent in een nieuw venster), Asana's platform voor softwarelevering, zodat het team achteraf het volledige onderzoek kon bekijken. Vanuit Command werden de bevindingen omgezet in tickets en vervolgens in pull requests, waarna de wijzigingen in productie werden genomen.
"Dit zou me handmatig één tot twee maanden hebben gekost. Met GPT-6 Astra in Codex duurde het ongeveer een week: ik stelde voor het slapengaan een /goal in en bekeek de resultaten 's ochtends."
Voor Model B verlaagde de optimalisatie de geschatte modelkosten van minstens $ 36,21 (sommige oorspronkelijke runs bereikten de stappenlimiet voordat ze klaar waren) naar $ 1,24 per run: een daling met een factor 29. De geoptimaliseerde workflow op GPT‑6.1 Sol was met $ 0,47 nog eens 2,6 keer goedkoper. Elke run van de geoptimaliseerde workflow voltooide de taak en leverde het juiste antwoord op.
Gemiddelden van 3 runs. ≥: de referentieconfiguratie bevat runs die een limiet bereikten, dus het gemiddelde is een ondergrens.
De twee factoren rechts geven de vergelijking met het geoptimaliseerde Model B weer. Model B werd getest in fase 1; Model C en Sol 6.1 in fase 2 van hetzelfde onderzoek (stippellijn).
Bij GPT‑6.1 Sol alleen al, met de hogere geschiedenislimiet, verlaagde de nieuwe strategie voor caching en screenshots de kosten met een factor 4, van $ 1,97 naar $ 0,47 per run. Elke aanroep was ongeveer 3 keer goedkoper, doordat 89% van de invoer uit de cache kwam tegen 5% van het tarief voor invoer buiten de cache. De runs werden ook sneller: van minstens 22,5 minuten met de oorspronkelijke configuratie op Model B naar ongeveer vier minuten met de geoptimaliseerde workflow op GPT‑6.1 Sol.
Gemiddelde van 3 runs, foutbalken voor standaardafwijking. ≥: het gemiddelde bevat een run die een limiet bereikte of niet werd voltooid; de werkelijke waarde is dus minstens zo hoog.
De balken zijn weergegeven in blauwtinten. Vergelijk de effecten van caching met de balk voor de hogere geschiedenislimiet van 480k.
De runmarkeringen en foutbalken voor de standaardafwijking zijn benaderingen, gereconstrueerd uit de bronafbeelding; de onderliggende runwaarden en standaardafwijkingen waren niet beschikbaar.
Gemiddelde van 3 runs, foutbalken voor standaardafwijking. ≥: het gemiddelde bevat een run die een limiet bereikte of niet werd voltooid; de werkelijke waarde is dus minstens zo hoog.
De balken zijn weergegeven in blauwtinten. Vergelijk de effecten van caching met de balk voor de hogere geschiedenislimiet van 480k.
De runmarkeringen en foutbalken voor de standaardafwijking zijn benaderingen, gereconstrueerd uit de bronafbeelding; de onderliggende runwaarden en standaardafwijkingen waren niet beschikbaar.
Het onderzoek liet ook zien hoe het beheer van de geschiedenis bepaalde of de agent überhaupt een antwoord produceerde. Door GPT‑6.1 Sol meer ruimte te geven om zijn browsegeschiedenis te bewaren, steeg het aantal runs dat een antwoord opleverde van drie op de 18 bij de lagere geschiedenislimiet naar alle 18 bij de hogere limiet, telkens met het juiste antwoord. Voor Hidalgo ligt de zakelijke waarde in het bieden van toegang tot snellere, krachtigere modellen aan klanten, terwijl de operationele kosten beheersbaar blijven.
"Vroeger beperkten de kosten welke modellen we klanten voor deze taken konden bieden. Door de agent efficiënter te maken, kunnen we klanten een beter, sneller model bieden en tegelijk onze operationele kosten verlagen."
Asana heeft de wijzigingen in de browsernavigatie in StackAI uitgebracht en ontwikkelt tools om soortgelijke experimenten eenvoudiger te herhalen. Op termijn wil het team deze tests opnemen in de evaluaties van het platform, zodat klanten en interne teams bij het configureren van hun agents de kosten, uitvoeringstijd en antwoordkwaliteit kunnen vergelijken.
"De snelheid waarmee we software opleveren is niet langer het knelpunt; menselijke aandacht is dat wel. We staan op de drempel van een wereld waarin elke ontwikkelaar als productmanager een vloot agents aanstuurt."
Asana gebruikt GPT‑6 Astra in Codex nu om productfuncties vóór de release te testen: Astra navigeert door het platform, probeert verschillende invoer uit en meldt bugs aan menselijke QA-beoordelaars. Hidalgo ziet dit als de basis voor een nieuwe levenscyclus voor softwareontwikkeling, waarin veel agentsessies in de cloud parallel functies testen.
Het volledige onderzoek is te vinden op de blogs van Asana(opent in een nieuw venster) en StackAI(opent in een nieuw venster).
