Das 76x-Browser-Agent-Ergebnis von GPT-6.1 Sol: Was Asana tatsächlich gemessen hat

Asana veröffentlichte am 8. Oktober 2026 eine Kostenstudie zu Browser-Agenten, und der Entwickler von GPT-6.1 Sol verfasste am nächsten Tag einen Artikel darüber unter der Schlagzeile „Asana senkt Modellkosten in Browsertests um das 76-Fache mit GPT-6.1 Sol.“ Die Angabe 76x ist insofern real, als jemand sie gemessen hat, aber sie ist keine Tatsache über den Preis von GPT-6.1 Sol. Sie ist eine Tatsache darüber, was passiert, wenn man einen defekten Prompt-Cache auf einem Browser-Agenten repariert und dann das Modell austauscht, das dahinter sitzt. Dieselbe Optimierung, angewendet auf das Modell, das Asana bereits in Produktion hatte — ein Modell, das es Model B nennt —, senkte die Kosten für sich genommen um das 29-Fache. GPT-6.1 Sol lieferte die verbleibenden 2,6x. Die Experimente wurden von GPT-6 Astra durchgeführt, das in Codex arbeitete, und das Modell hinter der Baseline ist das Modell eines Wettbewerbers, das Asana Model B nennt, sodass zwei Modellstufen desselben Anbieters und ein ungenannter Rivale alle in dem Beitrag auftauchen. Was folgt, trennt den Teil des Ergebnisses, den man am Montag kopieren kann, von dem Teil, der zu Asanas speziellem Stack gehört.

Der Vergleich, exakt formuliert

Asanas Stack dafür ist StackAI, die Workflow-Automatisierungsplattform, die das Unternehmen übernommen hat und die einen Browser-Agenten ausführt, der ohne Code Websites navigiert, Formulare ausfüllt und Informationen sammelt. Die Testaufgabe war eng begrenzt und konkret: Aus einem öffentlichen Demo-Katalog sechs Felder für jedes von 32 Büchern erfassen. Das ist repräsentativ für das, was manche Kunden laufen lassen, und zugleich klein genug, dass eine Studie mit 144 Durchläufen in eine Woche passt.

Das Design umfasste sechs Caching- und Screenshot-Richtlinien bei zwei Verlaufs-Budgets, drei Durchläufe pro Bedingung, über vier Modelle hinweg — 144 Durchläufe, plus einen Nachfolgetest mit 12 Durchläufen. Die Kosten wurden anhand der jeweiligen Token-Zähler der Anbieter berechnet, und jede Antwort wurde gegen eine unabhängig erstellte Referenz bewertet. Die vier Modelle waren drei unbenannte Frontier-Modelle (Modelle A, B und C) und GPT-6.1 Sol. Modell A ist ein kleineres, günstigeres Modell von einem anderen Labor, veröffentlicht im Herbst 2025, zum halben Preis von GPT-6.1 Sol. Modell B ist das Modell, das in Produktion war, dasselbe Labor wie A, veröffentlicht im Sommer 2026, zum selben Preis wie GPT-6.1 Sol. Modell C ist eine neuere Version von Modell B, veröffentlicht im Herbst 2026, ebenfalls zum selben Preis wie GPT-6.1 Sol. Die drei sind in beiden Berichten unbenannt, daher ist der Vergleich für Leser nicht reproduzierbar — gut zu wissen, bevor man 29x als eine Zahl über das Modell von jemand anderem auffasst. Dies sind die veröffentlichten Zahlen von Asana und OpenAI, keine unabhängig geprüften.

Die Ergebnisleiter, alle eigenen Zahlen von Asana:

• Baseline-Produktion auf Model B — mindestens 36,21 $ pro Lauf, mindestens 22,5 Minuten pro Lauf. Einige Baseline-Läufe erreichten das Schrittlimit, bevor sie abgeschlossen waren, sodass der Mittelwert eine Untergrenze und kein echter Durchschnitt ist.

• Model B, optimierter Agent — 1,24 $ pro Lauf, 4x schneller als die Baseline, eine 29-fache Kostensenkung.

• GPT-6.1 Sol, derselbe optimierte Agent — 0,47 $ pro Durchlauf, etwa vier Minuten, eine 76-fache Kostensenkung und 5-mal schneller.

• GPT-6.1 Sol, vor dem Fix vs. danach — von 1,97 $ auf 0,47 $ pro Durchlauf, eine 4-fache Senkung allein durch Cache- und Pruning-Änderungen.

Da die Baseline eine untere Schranke ist, ist 76x selbst eine Untergrenze. Die ehrliche Lesart ist „mindestens 76x“, nicht „76x“.

Was sich tatsächlich geändert hat und warum es kein Modellmerkmal ist

Der Mechanismus ist die Prompt-Cache-Mechanik, und es lohnt sich, ihn zu verstehen, weil er sich auf jeden Agenten überträgt, den du mit irgendeinem Modell betreibst. Ein Browser-Agent sendet seine Tools, seinen System-Prompt und seine wachsende Historie aus Seitentext und Screenshots bei jedem Modellaufruf erneut. Prompt-Caching vergünstigt den wiederholten Teil, aber nur den längsten unveränderten Präfix – sobald sich irgendetwas in der Mitte der Anfrage ändert, bricht die Wiederverwendung von diesem Punkt an ab.

Asanas Produktions-Agent hatte zwei Fehler, die sich gegenseitig verstärkten. Er cachte seine festen Anweisungen und Tool-Definitionen, aber nicht seinen Browserverlauf. Und er bearbeitete diesen Verlauf bei nahezu jedem Schritt: Bei jedem Mal verwarf er den vorherigen Screenshot und kürzte älteren Text, um in ein Verlaufsbudget zu passen. Jede Bearbeitung machte das Präfix ungültig, sodass Caching selbst dann nahezu nutzlos gewesen wäre, wenn es eingeschaltet worden wäre. In Asanas Bericht heißt es, dass bei den getesteten Modellen Cache-Lesevorgänge 0,05x bis 0,1x des Standard-Eingabepreises kosteten – die Belohnung war also groß, und der Agent verweigerte sie systematisch.

Der Fix hat zwei Hälften. Erstens: Cachiere auch den Verlauf, mit einem Cache-Marker am neuesten Tool-Ergebnis. Zweitens: Bearbeite ihn nicht mehr bei jedem Aufruf: Behalte Screenshots und dünne sie batchweise in einem Verhältnis von 20 zu 1 aus, sodass der Agent bis zu 20 behält und dann auf den neuesten zurückschneidet. Etwa 19 aufeinanderfolgende Aufrufe verwenden dann ein unverändertes Präfix wieder. Erhöhe das Verlaufsbudget von 120.000 auf 480.000 Zeichen, damit alter Text nicht mehr gekürzt wird, und die Rechnung geht auf: Bei GPT-6.1 Sol kostete jeder Aufruf etwa dreimal weniger, weil 89 % der Eingabe aus dem Cache stammten.

Die wichtigste Erkenntnis hier ist eine negative. Das Zwischenspeichern der Historie ohne Batch-Pruning kostete beim größeren Budget mehr als gar kein Zwischenspeichern bei drei der vier Modelle — der Cache wurde ständig neu geschrieben und selten gelesen. Cache-Infrastruktur, die ohne eine Append-only-Disziplin für die Historie eingeschaltet wird, ist eine Möglichkeit, einen Schreibaufschlag für nichts zu zahlen. Dieser Fehlermodus ist modellunabhängig, und er ist der Grund, warum dieselbe Korrektur Modell B um den Faktor 29 verbesserte.

Wo sich die Modellwahl tatsächlich ausgezahlt hat

Blende den Workflow-Fix aus und vergleiche Gleiches mit Gleichem: Beim selben optimierten Agenten war GPT-6.1 Sol bei gleichem Listenpreis 2,6-mal günstiger als Model B. Der zusätzliche Faktor ist das Cache-Hit-Verhalten, nicht die Tarifkarte. Sol las 89 % seines Inputs aus dem Cache; Asana veröffentlicht den entsprechenden Anteil für Model B nicht, daher ist der Faktor 2,6 ein gemessenes Ergebnis ohne veröffentlichte Aufschlüsselung. Behandle es als „dieses Modell hat bei dieser Workload seinen Cache besser genutzt“ und nicht als allgemeinen 2,6-fachen Vorteil gegenüber einem Modell, das wir nicht nennen können.

Die Laufzeitseite ist eindeutig: 5-mal schneller als die Baseline, wobei der optimierte Sol-Workflow bei etwa vier Minuten liegt – gegenüber einer Baseline von mindestens 22,5 Minuten. Geschwindigkeit ist entscheidend für die Kosten bei Agenten, die pro Token abrechnen, denn ein langsames Modell, das Schleifen dreht, zahlt für seine Schleifen.

Für alle, die das durchrechnen: Die Standard-API-Tarife von GPT-6.1 Sol betragen 2,00 $ pro Million Input-Tokens, 0,10 $ pro Million gecachter Input-Tokens und 10,00 $ pro Million Output-Tokens, und sein Cache-Lese-Rabatt beträgt das 0,05-Fache des Input-Tarifs — der tiefste auf der aktuellen Preisliste von OpenAI. GPT-6 Astra, das Modell, das die Engineering-Arbeit in Codex erledigt hat, kostet 10,00 $ Input und 50,00 $ Output, was die Fünffach-Lücke ist, auf die sich das Launch-Framing von OpenAI stützte. Der Grund, warum die Studie Durchläufe zu 0,47 $ statt zu 2 $ ergab, ist nicht die Tarifkarte; er liegt darin, dass 89 % einer sehr repetitiven Anfrage zum Zwanzigstel des Input-Tarifs abgerechnet wurden. Bei einem caching-intensiven Agenten hat der Rabattposten mehr Gewicht als der Nennpreis, und in unserem eigenen Katalog werden Anbieter-Listenpreise mit 0 % Aufschlag, sodass ein Anbieter, der einen Zähler für gecachte Inputs verschiebt, ihn noch am selben Tag auf Ihrer Rechnung verschiebt.

Die andere Zahl in der Studie: Das History-Budget entschied, ob der Agent überhaupt antwortete.

Die Kosten pro Durchlauf sind die Zahl, die jeder zitiert, doch das nützlichere Ergebnis der Studie betrifft die Zuverlässigkeit, und ebendies ist es, was ein Betreiber zuerst lesen sollte.

Bei einem Budget von 120.000 Zeichen antwortete Model C in keinem seiner 18 Durchläufe und GPT-6.1 Sol in 3 von 18 — die meisten Durchläufe stießen ans Schrittlimit, ohne eine Antwort zu erzeugen.

• Bei 480.000 Zeichen antwortete jeder Durchlauf auf beiden Modellen, jeder mit der richtigen Antwort.

• Die neueren Modelle verbrauchten das kleinere Budget schneller: Model C kürzte seinen Verlauf erstmals bei Aufruf 10, Model A bei Aufruf 64.

• Im optimierten Workflow schloss jeder Durchlauf die Aufgabe ab und lieferte die richtige Antwort, und jeder Lauf unter besten Bedingungen auf jedem Modell stieß auf alle 192 Fakten, die er sammeln sollte.

Das ist ein anderes Argument als „billiger“. Ein zu kleines Verlaufsbudget bei einem leistungsfähigen Modell erzeugt einen Agenten, der scheitert, weil ihm der Platz ausgeht, und der scheitert, weil er das Schrittlimit erreicht – die teuerste Art des Scheiterns: Man bezahlt den gesamten Lauf und bekommt nichts. Ein höheres Budget erhöhte die Kosten pro Aufruf und senkte die Kosten pro Antwort, der einzigen Zahl, die ein Verantwortlicher für den Produktivbetrieb verfolgen sollte. Wenn Sie ein noch nicht erprobtes Modell für einen Agenten wie diesen evaluieren, besteht das risikoarme Muster darin, Ihre Produktionsroute auf dem Modell zu belassen, dem Sie vertrauen, und das neue hinter ein Failover oder eine geteilte Route zu setzen, sodass ein Schrittlimit-Fehler als Routing-Fakt auftaucht und nicht als Vorfall. Jedes Modell in diesem Vergleich ist erreichbar über eine API für über 200 Modelle mit unverändert durchgereichten Listenpreisen der Anbieter, was außerdem den Cache-Read-Rabatt anbieterübergreifend auf derselben Rechnung vergleichbar macht statt auf fünf Dashboards.

Was man daraus mitnehmen sollte – der Reihenfolge nach

Wenn Sie einen Browser- oder Computer-Use-Agenten betreiben, lohnt es sich, drei Stellschrauben in Asanas Studie zu betätigen, bevor Sie sich eine Preisliste ansehen:

• Das Anfrage-Präfix muss append-only sein. Jede Änderung pro Aufruf in der Mitte des Verlaufs setzt die Cache-Wiederverwendung ab diesem Punkt auf null.

• In Stapeln beschneiden. Asanas Follow-up ergab, dass das Behalten jedes Screenshots 1,2x weniger pro Aufruf kostete als die beste Beschneidungsbedingung auf Model B und GPT-6.1 Sol und etwa 5 % weniger auf Model C. Beschneiden ist weiterhin wichtig für lange Aufgaben, kleine Kontextfenster und teure Cache-Reads – aber das Argument für ein Batch-Verhältnis von 20:1 dreht sich um Cache-Stabilität, nicht um die Screenshots selbst.

• Legen Sie das Verlaufsbudget pro Modell fest und prüfen Sie es gegen Ihre Schritt-Obergrenze. Ein Budget, das für ein Modell passt, kann das nächste aushungern.

Zwei Leitplanken aus der Studie lassen sich leicht überspringen – und sollten sie auch nicht. Kein Lauf erreichte das Budget von 480.000 Zeichen, sodass das Budget diese Läufe nie eingeschränkt hat – aber ein driftender Agent wächst auf sein Kontextlimit zu, und wenn der Cache bricht, zahlt jeder Aufruf den vollen Preis. Obergrenzen für Schritte, Tokens und Kosten pro Lauf sind das, was einen schlechten Lauf begrenzt. Davon abgesehen verwendete die Studie drei oder vier Läufe pro Bedingung mit variablen Aufrufzahlen, was laut Asana selbst ausreicht, um grobe Muster zu erkennen, aber nicht ausreicht, um Bedingungen auseinanderzuhalten, die nur wenige Prozent auseinanderliegen. Lies daraus kein 5%-Delta heraus und baue deine Pipeline nicht darauf auf.

Der Teil, der wirklich neu ist, und der Teil, der es nicht ist.

Die Vorbehalte zum Versuchsaufbau sollte man klar benennen: vier Modelle, drei davon ungenannt, eine eng gefasste Aufgabe mit 32 Büchern, Asanas eigene instrumentierte Zähler und ein vom Anbieter selbst verfasster Bericht, in dem das Ergebnis präsentiert wird. Nichts davon wurde außerhalb von Asana reproduziert. Doch der Mechanismus ist vollständig spezifiziert – reine Append-only-Historie, Cache-Marker am letzten Tool-Ergebnis, Batch-Pruning, größeres Budget, Cache-Lesevorgänge mit den Zählern des Anbieters messen – und es ist die Art von Befund, die auch dann Bestand hat, wenn sie dem falschen Labor zugeschrieben wird. Die 76x ist eine Asana-Zahl für eine Asana-Workload. Der Grund, warum es sich zu lesen lohnt, ist, dass es eine Regel demonstriert, die man an einem Nachmittag testen kann: Ein Agent, der bei jedem Schritt seine eigene Historie bearbeitet, zahlt den vollen Preis für eine Konversation, die er bereits geführt hat.