Asana senkt die Kosten seines Browser-Agenten mit GPT-6.1 Sol um das 76-Fache: Eine von Codex getriebene Workflow-Optimierung

Am 9. Oktober 2026 veröffentlichte OpenAI eine Kundengeschichte über Asana. Die Zahlen springen ins Auge. In einer Reihe von Browser-Agenten-Tests senkte Asana die geschätzten Modellkosten auf ein Sechsundsiebzigstel und machte die Läufe fünfmal schneller. Der optimierte Workflow lief auf GPT-6.1 Sol. Er kostete im Schnitt geschätzte 0,47 US-Dollar an Modellkosten und dauerte etwa vier Minuten pro Lauf. Die Vergleichsbasis war das ursprüngliche Produktions-Setup auf Modell B. Eine einfache Rechnung aus diesen beiden Werten ergibt für das alte Setup rund 36 US-Dollar pro Lauf. Zuerst eine Warnung. Dies ist ein vom Anbieter veröffentlichter Fall. Die Kosten sind Schätzungen. Der Vergleich stammt aus einer Studie mit 144 Läufen, die Asana selbst entworfen hat. Es ist ein ernstzunehmendes technisches Signal, aber noch kein Branchenmaßstab, den jedes Team einfach übernehmen kann.

Den Hintergrund bildet StackAI, eine von Asana übernommene Plattform. Kunden bauen damit ohne Programmierung Workflows, in denen ein Agent Websites ansteuert, Formulare ausfüllt und Informationen sammelt. Ein einzelner Lauf wirkt harmlos. Im Maßstab von Asana wird jede kleine Ineffizienz mit einem riesigen Aufrufvolumen multipliziert. Deshalb wollte Frank Hidalgo, PhD, der CTO von StackAI, den Browser-Agenten schneller und günstiger machen. Er führte kein Team durch eine manuelle Prüfung. Er ließ GPT-6 Astra in Codex den Agenten untersuchen, Verbesserungen testen und die Ergebnisse vergleichen. Nach seiner Schätzung hätte diese Arbeit von Hand ein bis zwei Monate gedauert. Sie dauerte etwa eine Woche.

Der lehrreichste Teil ist die Diagnose. Hidalgo bat GPT-6 Astra zuerst, die Codebasis zu kartieren und zu erklären, wie der Agent jede Modellanfrage zusammenbaut. Es zeigte sich: Der Agent cachte seine festen Anweisungen und Tool-Definitionen, nicht aber den wachsenden Verlauf aus Seitentext und Screenshots. Man bedenke, was das heißt. Bei jedem Schritt übergibt ein Browser-Agent dem Modell alles, was er bisher gesehen hat, plus einen neuen Screenshot. Je länger der Verlauf, desto mehr Eingabe muss das Modell in jedem Schritt verarbeiten. Trifft dieser Teil der Anfrage den Cache nicht, wird derselbe Inhalt innerhalb eines Laufs immer wieder zum vollen Preis berechnet. Auch die Zeit bis zum ersten Token verlängert sich jedes Mal. Die Verschwendung summiert sich mit jedem Schritt, und die gesamte Eingabe wächst schneller als die Schrittzahl selbst. Das ist unsere Deutung des Mechanismus, und sie ist plausibel. Der öffentliche Auszug von OpenAI listet nicht jede folgende Änderung auf, und wir sollten fehlende Punkte nicht erfinden.

Nun zum Studiendesign. Asana führte 144 Läufe durch, mit GPT-6.1 Sol und drei weiteren Spitzenmodellen, im Text Modell A, B und C genannt. Die Stärke dieses Designs liegt darin, dass Modellwahl und Workflow-Umbau im selben Vergleich stehen. Es schafft aber auch ein Deutungsproblem, das klar benannt werden muss. Der Faktor 76 vergleicht den optimierten Sol-Workflow mit dem ursprünglichen Produktions-Setup auf Modell B. Zwei Variablen haben sich gleichzeitig geändert. Schriebe man alle 76 dem Modell zu, überschätzte man dessen Rolle. Schriebe man sie ganz dem Workflow zu, übersähe man echte Unterschiede bei Preis und Tempo der Modelle. Der Auszug zeigt keine Kontrolle, die beides trennt, und genau dort sollte ein aufmerksamer Leser nachhaken. Die Kosten sind zudem Schätzungen, die sich bei Preisänderungen der Anbieter verschieben. Und 144 Läufe sind eine bescheidene Stichprobe, deren Stabilität weitere Wiederholungen prüfen müssen.

Die zweite Ebene betrifft die Arbeitsweise. Arnab Bose, Asanas Chief Product Officer, beschrieb es als das, was Teams aus Menschen und Agenten in der Praxis ausmacht: Ein Ingenieur gab die Richtung vor, GPT-6 Astra führte die Experimente durch, und die Ergebnisse gingen über Command in die Produktion. In diesem Satz verläuft eine klare Arbeitsteilung. Richtung, Abwägungen und die Entscheidung zum Ausrollen blieben bei Menschen. Die zeitraubendsten Teile, nämlich Code lesen, Hypothesen bilden, Vergleiche laufen lassen und Daten ordnen, gingen an den Agenten. Sinken die Grenzkosten eines Experiments, muss Optimierung nicht mehr auf eine freie Woche warten. Sie kann zur Routine werden. Dann verlagert sich der Kern des Werts jedoch auf die Bewertung. Gibt es wiederholbare Aufgaben? Vergleichbare Kennzahlen? Liest jemand die Ergebnisse sorgfältig? Ohne das erzeugen schnellere Experimente nur mehr Rauschen.

Für die Branche sendet der Fall drei Signale. Erstens verschiebt sich der Wettbewerb unter Browser-Agenten von der Frage, ob die Aufgabe gelingt, zu der Frage, was ein Lauf in Dollar und Minuten kostet. Der Sprung von Dutzenden Dollar auf unter einen Dollar macht Tausende Unternehmensläufe pro Tag erst plausibel. Zweitens sollte die Cache-Trefferstruktur ein fester Punkt in Architektur-Reviews von Agenten sein, vor allem bei Kontext, der mit jedem Schritt wächst. Drittens war ein erklärtes Ziel, dass Asana seinen Kunden leistungsfähigere Modelle anbieten kann. Niedrigere Kosten kaufen Spielraum für Fähigkeiten. Für Leser ist es klug, die Methode zu übernehmen und nicht die Zahl. Prüfen Sie, welcher Teil Ihrer eigenen Anfragen nicht gecacht wird. Vergleichen Sie kontrolliert auf einem festen Aufgabensatz. Testen Sie Modellwechsel und Workflow-Änderung getrennt. Berichten Sie die Kosten neben der Erfolgsquote. Eine 76-fache Ersparnis beeindruckt, doch sie zählt nur, wenn der Agent seine Aufgabe weiterhin richtig erledigt.