Asana senkt Kosten in Browsertests mit GPT‑6.1 Sol um Faktor 76
Mit GPT‑6 Astra in Codex senkte Asana die Kosten seines Browser-Agenten in Tests um Faktor 76 und machte ihn fünfmal schneller, um Unternehmen leistungsfähigere Modelle anzubieten.
76×
Niedrigere geschätzte Modellkosten mit dem optimierten Workflow auf GPT-6.1 Sol
5×
Schnellere Browserdurchläufe mit dem optimierten Workflow auf GPT-6.1 Sol
0,47 USD
Durchschnittliche geschätzte Modellkosten mit dem optimierten Workflow auf GPT-6.1 Sol
Asana ließ GPT‑6 Astra in Codex Experimente durchführen und optimierte damit den Workflow seines Browser-Agenten auf GPT‑6.1 Sol: Er läuft nun fünfmal schneller und kostet nur noch ein Sechsundsiebzigstel.
Asana hilft Unternehmen, mit StackAI(wird in einem neuen Fenster geöffnet) Aufgaben über verschiedene Geschäftsanwendungen hinweg zu automatisieren. Die Plattform hat Asana übernommen(wird in einem neuen Fenster geöffnet). Mit StackAI können Unternehmen ohne Programmierkenntnisse Workflows erstellen, die Websites aufrufen, Formulare ausfüllen und Informationen sammeln. Bei der Größenordnung von Asana summieren sich selbst kleine Ineffizienzen in diesen Workflows.
Frank Hidalgo, PhD, StackAI CTO bei Asana, wollte den Browser-Agenten schneller und kostengünstiger machen. Er wies GPT‑6 Astra in Codex an, den Agenten zu untersuchen, Verbesserungen zu testen und die Ergebnisse zu vergleichen. Arbeit, die ihn von Hand schätzungsweise ein bis zwei Monate gekostet hätte, war in etwa einer Woche erledigt.
In Asanas Studie mit 144 Durchläufen(wird in einem neuen Fenster geöffnet) wurden GPT‑6.1 Sol und drei weitere Frontier-Modelle getestet, hier als Modelle A, B und C bezeichnet. Der daraus entstandene optimierte Workflow auf GPT‑6.1 Sol verursachte im Schnitt geschätzte Modellkosten von 0,47 USD und benötigte etwa vier Minuten pro Durchlauf. Damit kostete er nur ein Sechsundsiebzigstel der ursprünglichen Produktivkonfiguration mit Modell B und war fünfmal schneller.
„So sieht die Zusammenarbeit von Menschen und Agenten in der Praxis aus. Ein Entwickler gab die Richtung vor, GPT-6 Astra führte die Experimente durch, und die Ergebnisse gelangten über Command in den Produktivbetrieb. Das zeigt, wie Asana Teams aus Menschen und Agenten Wirklichkeit werden lässt.“
Um schnell voranzukommen, ließ Hidalgo GPT‑6 Astra in Codex zunächst die Codebasis analysieren und erklären, wie der Agent jede Modellanfrage zusammenstellte. GPT‑6 Astra stellte fest, dass der Agent seine festen Anweisungen und Tool-Definitionen zwischenspeicherte, nicht aber den wachsenden Verlauf der gesammelten Seitentexte und Screenshots. So wurde dieser Verlauf bei jeder Anfrage erneut zum vollen Preis übermittelt.
Außerdem entfernte der Agent bei fast jedem Schritt ältere Screenshots und kürzte Texte. Jede Bearbeitung veränderte den Verlauf. Ihn lediglich zwischenspeichern zu lassen, hätte daher nicht geholfen. Durch den Informationsverlust musste der Agent möglicherweise bereits gelesene Seiten erneut aufrufen.
Hidalgo prüfte die von GPT‑6 Astra vorgeschlagenen Lösungen und wählte drei zum Testen aus:
Das Caching auf den Browserverlauf des Agenten ausweiten
Die Textmenge erhöhen, die er behalten konnte
Screenshots stapelweise statt bei jedem Schritt entfernen
GPT‑6 Astra begann mit kurzen Tests, um die entscheidenden Variablen zu ermitteln. Da der Code nicht für kontrollierte Experimente ausgelegt war, überarbeitete das Modell anschließend dessen Struktur. So konnten ein Frontend und ein Backend viele Workflows parallel unterstützen, jeweils mit eigenen Einstellungen.
Astra führte die vollständige Studie durch: Verlaufsbudgets von 120.000 und 480.000 Zeichen sowie sechs Caching- und Screenshot-Strategien, jeweils dreimal auf jedem der vier Modelle getestet (siehe Tabelle unten). Die erfolgreichste Strategie sammelte zunächst 20 Screenshots und entfernte dann alle bis auf den neuesten. So blieb der frühere Verlauf zwischen den Löschvorgängen länger unverändert. Zusammen mit dem größeren Verlaufsbudget ergab dies den optimierten Workflow. Jede Konfiguration bearbeitete dieselbe Aufgabe: für jedes von 32 Büchern sechs Datenfelder aus einem öffentlichen Demokatalog erfassen. Das entspricht typischen Aufgaben, die einige Unternehmen mit StackAI ausführen.
Modell | Beschreibung | Preis |
|---|---|---|
Modell A | Ein kleineres, günstigeres Modell eines anderen Frontier-Labors, veröffentlicht im Herbst 2025 | Halb so teuer wie GPT‑6.1 Sol |
Modell B | Das ursprünglich im Produktivbetrieb eingesetzte Modell aus demselben Labor wie Modell A, veröffentlicht im Sommer 2026 | Gleicher Preis wie GPT‑6.1 Sol |
Modell C | Eine aktualisierte Version von Modell B, veröffentlicht im Herbst 2026 | Gleicher Preis wie GPT‑6.1 Sol |
GPT‑6.1 Sol | Das Modell von OpenAI |
GPT‑6 Astra führte die Workflows aus und untersuchte die Anfragen, Nutzungsprotokolle und Modellergebnisse. In separaten Modellsitzungen wurde die Arbeit überprüft. Die Anfragen, Datenprotokolle und Ergebnisse jeder Sitzung wurden in Command(wird in einem neuen Fenster geöffnet), Asanas Plattform zur Softwarebereitstellung, aufgezeichnet. So konnte das Team die gesamte Studie im Nachhinein prüfen. Aus den Erkenntnissen in Command entstanden Tickets und anschließend Pull Requests. Die Änderungen wurden in den Produktivbetrieb übernommen.
„Von Hand hätte ich dafür ein bis zwei Monate gebraucht. Mit GPT-6 Astra in Codex dauerte es etwa eine Woche: Ich legte vor dem Schlafengehen ein /goal fest und prüfte morgens die Ergebnisse.“
Bei Modell B senkte die Optimierung die geschätzten Modellkosten von mindestens 36,21 USD auf 1,24 USD pro Durchlauf, also um Faktor 29. Einige ursprüngliche Durchläufe hatten das Schrittlimit erreicht, bevor sie fertig waren. Der optimierte Workflow auf GPT‑6.1 Sol war mit 0,47 USD nochmals um Faktor 2,6 günstiger. Jeder Durchlauf des optimierten Workflows schloss die Aufgabe ab und lieferte die richtige Antwort.
Mittelwerte aus 3 Durchläufen. ≥: Die Ausgangskonfiguration enthält durch ein Limit beendete Durchläufe. Ihr Mittelwert ist daher eine Untergrenze.
Die beiden Faktoren rechts beziehen sich auf das optimierte Modell B. Modell B lief in Phase 1, Modell C und Sol 6.1 in Phase 2 derselben Studie (gepunktete Linie).
Allein bei GPT‑6.1 Sol senkte die neue Caching- und Screenshot-Strategie mit dem größeren Verlaufsbudget die Kosten um Faktor 4: von 1,97 USD auf 0,47 USD pro Durchlauf. Jeder Aufruf kostete etwa ein Drittel, weil 89 % der Eingaben aus dem Cache kamen und nur 5 % des Preises für nicht zwischengespeicherte Eingaben kosteten. Auch die Durchläufe wurden schneller: Statt mindestens 22,5 Minuten mit der ursprünglichen Konfiguration auf Modell B dauerte der optimierte Workflow auf GPT‑6.1 Sol rund vier Minuten.
Mittelwert aus 3 Durchläufen, Fehlerbalken zeigen die Standardabweichung. ≥: Der Mittelwert enthält einen durch ein Limit beendeten oder unvollständigen Durchlauf. Der tatsächliche Wert ist daher mindestens so groß.
Die Balken sind in Blautönen dargestellt. Vergleiche die Caching-Effekte mit dem Balken für das größere Budget von 480.000 Zeichen.
Die Markierungen der Durchläufe und die Fehlerbalken der Standardabweichung wurden näherungsweise aus dem Originalbild rekonstruiert. Die zugrunde liegenden Durchlaufwerte und Standardabweichungen lagen nicht vor.
Mittelwert aus 3 Durchläufen, Fehlerbalken zeigen die Standardabweichung. ≥: Der Mittelwert enthält einen durch ein Limit beendeten oder unvollständigen Durchlauf. Der tatsächliche Wert ist daher mindestens so groß.
Die Balken sind in Blautönen dargestellt. Vergleiche die Caching-Effekte mit dem Balken für das größere Budget von 480.000 Zeichen.
Die Markierungen der Durchläufe und die Fehlerbalken der Standardabweichung wurden näherungsweise aus dem Originalbild rekonstruiert. Die zugrunde liegenden Durchlaufwerte und Standardabweichungen lagen nicht vor.
Die Untersuchung zeigte außerdem, wie die Verwaltung des Verlaufs beeinflusste, ob der Agent überhaupt eine Antwort lieferte. Mit mehr Platz für den Browserverlauf stieg bei GPT‑6.1 Sol die Zahl der Durchläufe mit einer Antwort von drei von 18 beim kleineren Verlaufsbudget auf alle 18 beim größeren Budget. Jede dieser Antworten war richtig. Für Hidalgo liegt der geschäftliche Nutzen darin, Unternehmen Zugang zu schnelleren, leistungsfähigeren Modellen zu geben und zugleich die Betriebskosten wirtschaftlich tragfähig zu halten.
„Früher begrenzten die Kosten, welche Modelle wir Unternehmen für diese Aufgaben anbieten konnten. Weil der Agent jetzt effizienter arbeitet, können wir Unternehmen ein besseres, schnelleres Modell anbieten und gleichzeitig unsere Betriebskosten senken.“
Asana hat die Änderungen an der Browsernavigation in StackAI veröffentlicht und entwickelt Tools, mit denen sich ähnliche Experimente leichter wiederholen lassen. Das Team plant, diese Tests nach und nach in die Evaluationen der Plattform zu integrieren. So können Unternehmen und interne Teams beim Konfigurieren ihrer Agenten Kosten, Laufzeit und Antwortqualität vergleichen.
„Nicht mehr die Geschwindigkeit der Bereitstellung ist der Engpass, sondern die menschliche Aufmerksamkeit. Wir stehen kurz vor einer Welt, in der jede Person in der Softwareentwicklung die Rolle eines PM übernimmt und eine Flotte von Agenten steuert.“
Asana nutzt GPT‑6 Astra in Codex inzwischen, um Produktfunktionen vor der Veröffentlichung zu testen: Astra navigiert durch die Plattform, probiert verschiedene Eingaben aus und meldet Fehler an das menschliche Qualitätssicherungsteam. Hidalgo sieht darin die Grundlage für einen neuen Softwareentwicklungszyklus, bei dem viele Cloud-Agentensitzungen Funktionen parallel testen.
Die vollständige Studie findest du in den Blogs von Asana(wird in einem neuen Fenster geöffnet) und StackAI(wird in einem neuen Fenster geöffnet).
