Asana senkt die Kosten seines Browser-Agenten mit GPT-6.1 Sol um das 76-Fache

Asana hat ein eng umrissenes Ingenieurproblem zu einer Fallstudie gemacht, die für jeden nützlich ist, der Agenten im Produktivbetrieb einsetzt. Die Plattform StackAI erlaubt Kunden, ohne Code Workflows zu bauen, die Websites durchsuchen, Formulare ausfüllen und Informationen sammeln. In Asanas Größenordnung vervielfacht sich jede kleine Ineffizienz eines Browser-Agenten über sehr viele Läufe. Frank Hidalgo, CTO von StackAI, wollte den Agenten schneller und günstiger machen. Er beauftragte GPT-6 Astra in Codex, den Agenten zu untersuchen, Verbesserungen zu testen und die Ergebnisse zu vergleichen. Das veröffentlichte Ergebnis ist eindeutig. Der optimierte Workflow auf GPT-6.1 Sol kostet im Schnitt geschätzte 0,47 US-Dollar an Modellkosten und dauert rund vier Minuten pro Lauf. Das ist 76-mal günstiger und 5-mal schneller als das ursprüngliche Produktions-Setup, das auf dem Modell B lief. Hidalgo schätzt, dass die Arbeit von Hand ein bis zwei Monate gedauert hätte. Tatsächlich dauerte sie etwa eine Woche.

Die Ursache lag darin, wie der Agent jede Modellanfrage zusammensetzte. GPT-6 Astra kartierte zunächst den Code und erklärte, wie jede Anfrage entsteht. Dabei zeigte sich: Der Agent legte seine festen Anweisungen und Tool-Definitionen in den Cache, nicht aber den wachsenden Verlauf aus Seitentext und Screenshots. Jede Anfrage sendete diesen Verlauf deshalb erneut zum vollen Preis. Außerdem verwarf der Agent fast bei jedem Schritt ältere Screenshots und kürzte Text. Jede dieser Änderungen veränderte den Verlauf. Prompt-Caching arbeitet mit einem stabilen Präfix: Ändert sich der Anfang des Verlaufs, wird alles danach ungültig. Den Verlauf allein zu cachen, hätte daher nichts gebracht. Das Verwerfen von Informationen hatte zudem versteckte Kosten, denn der Agent musste womöglich bereits gelesene Seiten erneut besuchen. Die Lehre: Caching, Aufbewahrung und Bereinigung sind ein gemeinsames Designproblem, und die Korrektur nur eines Teils kann die Rechnung unverändert lassen.

Hidalgo prüfte die von GPT-6 Astra vorgeschlagenen Korrekturen und wählte drei zum Test aus: das Caching auf den Browserverlauf ausdehnen, die Menge des behaltenen Textes erhöhen und Screenshots gebündelt statt bei jedem Schritt entfernen. Astra begann mit schnellen Tests, um herauszufinden, welche Variablen zählen. Der Code war nicht für kontrollierte Experimente gebaut. Astra baute ihn deshalb so um, dass ein Frontend und ein Backend viele Workflows parallel mit jeweils eigenen Einstellungen ausführen konnten. Dann führte es die gesamte Studie durch: zwei Verlaufsbudgets mit 120.000 und 480.000 Zeichen und sechs Caching- und Screenshot-Strategien, jede dreimal auf jedem der vier Modelle getestet. Das ergibt 144 Läufe. Die beste Strategie ließ Screenshots bis auf 20 anwachsen und schnitt dann auf den jüngsten zurück. Der frühere Verlauf blieb so zwischen den Löschungen länger unverändert, und der Cache blieb gültig. Zusammen mit dem größeren Verlaufsbudget wurde daraus der optimierte Workflow.

Auch das Versuchsdesign verdient Beachtung. Jede Konfiguration löste dieselbe Aufgabe: sechs Felder für jedes von 32 Büchern aus einem öffentlichen Demokatalog erfassen, was dem entspricht, was manche Asana-Kunden in StackAI ausführen. Die vier Modelle waren GPT-6.1 Sol und drei Modelle eines anderen Spitzenlabors. Modell A ist ein kleineres, günstigeres Modell vom Herbst 2025 zum halben Preis von GPT-6.1 Sol. Modell B ist das ursprünglich in der Produktion genutzte Modell vom Sommer 2026 zum gleichen Preis. Modell C ist eine aktualisierte Version von Modell B vom Herbst 2026, ebenfalls zum gleichen Preis. Weil drei der vier Modelle so viel wie GPT-6.1 Sol oder weniger kosten, stammt der Kostenunterschied überwiegend daraus, wie gut jeder Workflow den Cache nutzt. Eine einfache Rechnung mit den veröffentlichten Zahlen, 0,47 Dollar mal 76, ergibt für das Original rund 36 Dollar pro Lauf. Diese Zahl ist unsere eigene Rechnung und keine Angabe von Asana.

Der Prozess um das Experiment ist so wichtig wie das Ergebnis. GPT-6 Astra führte die Workflows aus und prüfte Anfragen, Nutzungsdaten und Ausgaben. Getrennte Modellsitzungen prüften seine Arbeit gegen. Anfragen, Datenspuren und Ergebnisse jeder Sitzung wurden in Command erfasst, Asanas Plattform für Softwarebereitstellung, sodass das Team die gesamte Studie später nachvollziehen konnte. Aus Command wurden die Erkenntnisse zu Tickets, dann zu Pull Requests, und die Änderungen gingen in Produktion. Hidalgo beschreibt, wie er vor dem Schlafengehen ein /goal setzte und morgens die Ergebnisse prüfte. Arnab Bose, Chief Product Officer bei Asana, fasst es so zusammen: Ein Ingenieur gab die Richtung vor, GPT-6 Astra führte die Experimente durch, und die Ergebnisse gingen über Command in Produktion. Das ist ein konkretes Bild gemischter Teams aus Menschen und Agenten, mit Nachweis an jedem Schritt.

Daraus folgen drei Lehren für die Branche. Erstens bestimmt vor allem das Kontext-Engineering die Kosten eines Agenten, nicht der Listenpreis des Modells. Wenn drei von vier Modellen gleich viel oder weniger kosten, entscheidet, ob das lange, wachsende Präfix jeder Anfrage aus dem Cache bedient wird. Teams, die nur Preise pro Token vergleichen, übersehen womöglich den größeren Hebel. Zweitens funktioniert es, einen Agenten mit einem Agenten zu verbessern, nur bei wiederholbaren Experimenten und nachvollziehbaren Belegen. Asana baute seinen Code für kontrollierte Vergleiche um und hielt jede Spur in einem System fest. Diese Disziplin ist nachahmenswerter als jede einzelne Einstellung. Drittens verlangen die Zahlen eine vorsichtige Lesart: eine Aufgabe, ein öffentlicher Demokatalog, geschätzte Kosten statt Rechnungen. Die Studie zeigt, dass die Methode funktioniert. Sie beweist nicht, dass jeder Browser-Workflow das 76-Fache spart. Für Teams, die Agenten in Produktion bringen, ist ein praktischer erster Schritt, zu prüfen, welche Teile jeder Anfrage gecacht sind und welche sich bei jedem Schritt ändern, und jede Korrektur mit einer kleinen kontrollierten Studie zu bestätigen. Ein bis zwei Monate Handarbeit auf eine Woche zu verkürzen spart Stunden und senkt außerdem die Kosten, Ideen auszuprobieren.