Asana meldet 76-fach nied­ri­gere Kosten für seinen Browser-Agenten, weil der wachsende Verlauf nicht zwi­schen­ge­spei­chert wurde

Asana hat die Modellkosten seines Browser-Agenten nach eigener Messung um das 76-Fache gesenkt. Der Agent gehört zu StackAI, einer Plattform, die Asana gekauft hat. Kunden bauen dort ohne Code Abläufe, die Websites ansteuern, Formulare ausfüllen und Informationen sammeln. In einer Studie mit 144 Läufen kam die überarbeitete Fassung auf GPT-6.1 Sol im Schnitt auf geschätzte 0,47 Dollar Modellkosten und rund vier Minuten je Lauf. Gegenüber dem ursprünglichen Produktionsaufbau war das 76-mal günstiger und 5-mal schneller. Veröffentlicht hat den Fall OpenAI am 9. Oktober als Kundenbericht, und die Ursache fand nach dieser Darstellung ein Modell: GPT-6 Astra, das in Codex den Code des Agenten untersuchte und die Experimente fuhr.

Der wachsende Verlauf ging jedes Mal voll hinaus

Frank Hidalgo, technischer Leiter von StackAI, ließ GPT-6 Astra zuerst die Codebasis kartieren und erklären, wie der Agent jede einzelne Anfrage an das Modell zusammensetzt. Dabei zeigte sich eine Lücke: Zwi­schen­ge­spei­chert waren nur die festen Anweisungen und die Definitionen der Werkzeuge. Der Verlauf, den der Agent unterwegs sammelte, also Seitentext und Screenshots, war davon ausgenommen. Jede Anfrage schickte ihn deshalb erneut und zum vollen Preis an das Modell. Weil dieser Verlauf mit jedem Schritt länger wurde, stiegen die Kosten eines Laufs mit seiner Dauer.

Kürzen, das den Zwischenspeicher aushebelt

Die naheliegende Reparatur wäre gewesen, den Zwischenspeicher auf den Verlauf auszudehnen. Für sich allein hätte das wenig gebracht. Der Agent entfernte fast bei jedem Schritt ältere Screenshots und kürzte Text. Jede dieser Änderungen machte aus dem Verlauf einen anderen, und einen Verlauf, der sich bei jedem Schritt ändert, kann ein Zwischenspeicher nicht wiederverwenden. Dazu kam ein zweiter Preis: Was der Agent wegschnitt, wusste er danach nicht mehr, und er musste womöglich Seiten erneut aufrufen, die er schon gelesen hatte.

Für Browser-Agenten galt bisher eine einfache Rechnung: Wer alte Screenshots entfernt und Seitentext beschneidet, hält die Anfrage klein und spart damit. Asanas Fall kehrt die Rechnung an genau dieser Stelle um. Das ständige Kürzen machte die einzelne Anfrage kleiner, verhinderte aber, dass der Verlauf überhaupt zwi­schen­ge­spei­chert werden konnte, und so lief er bei jedem Schritt vollständig neu ein. Wer einen Agenten günstiger machen will, muss deshalb zwei Dinge zusammen ansehen: was im Verlauf steht und ob dieser Verlauf von Schritt zu Schritt gleich bleibt. Hidalgo prüfte die Vorschläge des Modells und wählte drei zum Test aus, der erste dehnte das Zwischenspeichern auf den Browserverlauf aus. Die Untersuchung, die er von Hand auf ein bis zwei Monate schätzt, dauerte etwa eine Woche.

In den 76 steckt auch ein Modellwechsel

Die Zahl misst mehr als den Umbau am Zwischenspeicher. Getestet wurden GPT-6.1 Sol und drei weitere Spitzenmodelle, die der Bericht nur als Model A, B und C führt. Der Vergleich, aus dem die 76 stammt, stellt den alten Aufbau auf Model B dem neuen Ablauf auf GPT-6.1 Sol gegenüber. Damit stecken der Wechsel des Modells und die Änderung am Verlauf in derselben Zahl. Wer die Ersparnis auf den eigenen Agenten übertragen will, kann aus ihr deshalb nicht ablesen, welcher Teil allein vom besseren Umgang mit dem Verlauf kommt.

Auch die Herkunft gehört zur Einordnung. Die Studie hat Asana selbst gefahren, veröffentlicht hat sie der Anbieter des Modells, das am Ende gewann, und die Seite endet mit einem Kontakt zum Vertrieb. Die Beträge sind geschätzte Modellkosten je Lauf, was ein Lauf im Betrieb insgesamt kostet, beziffert der Bericht nicht. Belastbar bleibt der Mechanismus: Ein Verlauf, der bei jedem Schritt umgeschrieben wird, lässt sich nicht zwischenspeichern, und das gilt unabhängig davon, welches Modell ihn liest.