← Alle Beiträge

Beobachtungen zum Token-Verbrauch von KI-Agenten

Auf dieser Seite

Ein neues Paper von Forschern aus Stanford, Michigan, DeepMind, All Hands, Microsoft AI und vom MIT ist die detaillierteste offene empirische Studie, die ich dazu kenne, wie KI-Agenten im großen Maßstab tatsächlich Tokens verbrauchen1. Die Autoren lassen acht Frontier-Modelle über 500 SWE-bench-Verified-Aufgaben laufen, jeweils vier Durchläufe, und erfassen die komplette Trajektorien-Telemetrie, aufgeschlüsselt nach Token-Typ, Phase und Aktion. Den Datensatz veröffentlichen sie zusammen mit dem Paper. Soweit ich weiß, ist das der feinkörnigste öffentliche Korpus agentischer Trajektorien, den es derzeit gibt.

Das Paper ist gründlich, genau bei dem, was es behauptet, und legt harte Zahlen auf Fragen, die bisher nur mit Anekdoten beantwortet wurden. Ich empfehle, es ganz zu lesen.

Was jetzt folgt, ist ein Gang durch vier Beobachtungen des Papers, durchsetzt mit dem, was wir bei Flowstate sehen, wenn genau dieselben Muster in Kundenumgebungen auftauchen. Wir sitzen im Request-Pfad zwischen Nutzer und KI-Anbieter. Wir beobachten also dieselben Trajektorien, die das Paper analysiert, nur in Produktion und über deutlich mehr KI-Tools, als SWE-bench abdeckt.

Die beiden Beobachtungsreihen liegen auffallend nah beieinander. Die Forscher haben es auf einem Benchmark gemessen, wir sehen es auf Kundengeräten. Die Übereinstimmung macht das Paper für alle nützlich, die diese Ausgaben tatsächlich steuern wollen.

Input-Tokens dominieren die agentischen Ausgaben

Die erste Erkenntnis des Papers: Agentisches Coding verbraucht rund 1.000-mal mehr Tokens als vergleichbare Code-Chat- oder Code-Reasoning-Aufgaben, bei einem Verhältnis von Input zu Output von etwa 153:1 (gegenüber 1,33 beim Chat und 0,16 beim Reasoning)2.

Der Grund ist strukturell. Agentische Workflows sammeln über die Runden Kontext an, und derselbe Inhalt wird bei jedem einzelnen Schritt wieder ins Modell gespeist. Token-Caching hilft am Rand, aber das schiere Volumen des angesammelten Kontexts bestimmt die Kosten.

Genau dieses Muster sehen wir auch bei nicht agentischer KI-Nutzung. Chat-artige Nutzung von Claude, ChatGPT und ähnlichen Tools hat dieselbe Form, weil Nutzer Gespräche über Tage weiterführen, statt frische Sessions mit explizitem Kontext zu starten. Ein Kunde hat es uns so beschrieben:

“We think they’re creating PowerPoints, and then they’re like, ‘change this word on slide three’, and then they’re just continuing to generate these really large documents.”

Das ist die Erkenntnis des Papers in menschlicher Form. Eine Chat-Session, die ein frischer Prompt hätte sein sollen, wird zu einem Thread, der bei jedem Schritt seine gesamte Historie neu bezahlt. Der Nutzer denkt, er macht eine kleine Änderung. Das Modell soll das ganze Dokument neu verarbeiten. Der Anbieter berechnet es entsprechend.

Daraus folgt: Ein riesiger Teil der steuerbaren KI-Kosten liegt vor dem Modell. Bessere Prompts. Frische Sessions. Expliziter Kontext, einmal geliefert, statt über einen Nachmittag Stück für Stück aufgebaut. Das Verhalten des Agenten ergibt sich größtenteils daraus, wie er aufgesetzt wurde.

Die Modellwahl macht Kostenunterschiede um Größenordnungen

Bei den 230 SWE-bench-Aufgaben, die jedes getestete Modell erfolgreich gelöst hat, verbrauchten Kimi-K2 und Claude Sonnet 4.5 im Schnitt 1,5 Millionen Tokens mehr als GPT-53. Dieselben Probleme, dieselben richtigen Antworten, ein völlig anderer Token-Appetit.

Das Paper schließt die naheliegende Erklärung sorgfältig aus: Die Kostenlücke bleibt sowohl in der Teilmenge, die alle gelöst haben, als auch in der Teilmenge, an der alle gescheitert sind. Die teureren Modelle haben keine schwereren Probleme angepackt. Sie haben bei denselben Problemen einfach mehr Tokens verbraucht.

Das passt zu einem Verhalten, das wir durchgehend beobachten. Nutzer greifen zu dem Modell, das in der Oberfläche am prominentesten ist, und “am prominentesten” heißt meistens “am teuersten”. Opus, wo Sonnet gereicht hätte. Anbieter haben keinen kommerziellen Anreiz, Nutzer zu günstigeren Modellen zu lenken. Aus einem anderen Kundengespräch:

“We definitely know that people are using just all Opus. The people that are using up their tokens, they’ll continue to do that unless there’s a way to control it. We did not know there was a way to control that in Claude. I know there isn’t.”

Es gibt einen Weg, das zu steuern, nur steckt er nicht im Produkt des Anbieters. Der natürliche Ort dafür ist die Schicht, die die Aufgabenkategorie sieht und auf Request-Ebene routet: Boilerplate ans schlankere Modell, langes Planen ans schwerere. Dass Token-Effizienz eine Eigenschaft des Modells ist und nicht der Aufgabe, wie die Stanford-Erkenntnis zeigt, macht Routing überhaupt erst tragfähig. Würden schwerere Modelle nur bei schwereren Problemen mehr Tokens verbrennen, wäre Routing nutzlos. Tun sie nicht, also ist es nützlich.

Der Token-Verbrauch schwankt stark und lässt sich schwer vorhersagen

Die dritte Beobachtung des Papers: Vier Durchläufe desselben Modells bei derselben Aufgabe können bis zu 30-fach unterschiedliche Gesamtkosten in Tokens erzeugen4. Der teuerste Durchlauf bei einem Problem kostet im Schnitt etwa das Doppelte des günstigsten. Je höher die Kosten, desto geringer die Vorhersagbarkeit.

Noch deutlicher: Die Autoren testen, ob Agenten ihren eigenen Token-Verbrauch vor der Ausführung einer Aufgabe vorhersagen können. Die Korrelationen liegen bestenfalls bei 0,39. Alle acht Modelle schätzen systematisch zu niedrig5. Nicht einmal der Agent weiß, was eine Aufgabe kosten wird.

Auf der Kundenseite sehen wir Führungskräfte, die ihre Ausgaben mit den einzigen Daten steuern wollen, die sie haben. Meist ist das eine Chat-Zahl aus dem Admin-Dashboard eines Anbieters:

“What are these five people doing? They’re always saying they don’t have enough tokens.”

Eine Chat-Zahl beantwortet das nicht. Eine Token-Zahl sagt, wie viel ausgegeben wurde, aber nicht warum. Das Warum ist aus der Rechnung strukturell nicht zu erkennen. Du siehst es nur auf der Request-Ebene, wo die eigentliche Arbeit sichtbar ist. Keine Prognose im Voraus schließt diese Lücke, weil die Arbeit selbst stochastisch ist.

Höhere Kosten bringen keine höhere Genauigkeit

Das Paper teilt die Durchläufe in Kosten-Quartile ein und stellt fest, dass die Genauigkeit im zweitgünstigsten Quartil ihren Höhepunkt erreicht und danach auf diesem Niveau bleibt. Die teuersten Durchläufe liefern keine besseren Ergebnisse als die moderat bepreisten6.

Die Autoren führen das auf ein bestimmtes Verhaltensmuster zurück: Im Quartil mit den höchsten Kosten sind wiederholte Dateiänderungen etwa 4-mal so häufig wie im günstigsten Quartil, wiederholte Dateiansichten 2-mal so häufig7. Die teuren Durchläufe leisten nicht mehr Arbeit. Sie machen dieselbe Arbeit nochmal, an denselben Dateien.

Das Paper nennt das höflich “unproductive exploration rather than deeper reasoning”. Dieselbe Form sehen wir bei KI-Nutzung außerhalb des Codings. Immer wieder dasselbe Artefakt mit minimalen Änderungen neu generieren. Lang laufende Sessions, aus denen der Nutzer vor Stunden ausgestiegen ist. Identische Prompts, die nach einer Tippfehler-Korrektur nochmal abgeschickt werden. Nichts davon sind Fehler des Agenten, es sind Muster der Nutzer, die der Agent erbt.

Die Messlücke

Keines der Muster oben lässt sich im großen Maßstab angehen, ohne auf der Request-Ebene zu messen. Dashboards der Anbieter aggregieren nach Tool und Mandant. AI Gateways (ein Proxy zwischen dir und deinem KI-Anbieter) decken das serverseitige Produktions-Routing ab. Tools für Engineering Effectiveness decken schmale Coding-Assistenten ab und hören dort auf.

Wir haben Flowstate gebaut, weil die Messschicht, die man braucht, um bei diesen Mustern tatsächlich etwas zu tun, nirgendwo im Stack existierte.

Flowstate beobachtet jeden KI-Aufruf eines Nutzers, ob ChatGPT im Browser, Claude Code im Terminal, Midjourney für Bilder oder Suno für Audio, und ordnet jeden Aufruf einem Nutzer, Projekt, Modell und einer Kostenklasse zu8. Kunden behalten ihre eigenen Verträge und ihre eigenen API-Schlüssel bei jedem Anbieter, den sie nutzen. Wir verkaufen keinen Zugang zu KI und schränken nicht ein, zu welchen Tools Leute greifen.

Diese architektonische Position hat Folgen über die Kostenmessung hinaus. Dieselbe Instrumentierung, die Token-Verschwendung sichtbar macht, zeigt auch Muster, die für die Sicherheit zählen. Prompts mit personenbezogenen Kundendaten, die an ein Consumer-KI-Tool gehen. Quellcode, der in ChatGPT eingefügt wird. Mitarbeiter, die Nebenprojekte auf dem Firmenabo laufen lassen. Wir sehen das im Feld allein deshalb, weil die Request-Ebene der einzige Ort ist, an dem es sichtbar ist.

Das Stanford-Paper liefert aus einem Benchmark ein sauberes ökonomisches Argument. Unsere Beobachtungen liefern exakt dasselbe Argument aus echten Unternehmensumgebungen. Die Muster, die KI-Kosten treiben, sind groß, messbar und konsistent. Du brauchst nur die Verrohrung, um sie zu sehen.

Footnotes

  1. Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., and Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750v2. Die Autoren verweisen auf parallele Arbeiten zur Token-Verteilung in Multi-Agent-Systemen (Salim et al. 2026, Wang et al. 2025) und zur Preisdynamik bei Reasoning-Modellen (Chen et al. 2026). Aber die Kombination aus Umfang, Granularität und offener Datenveröffentlichung macht dieses Paper für mich zum nützlichsten, um zu verstehen, wie agentische Ausgaben wirklich aussehen. Die Autoren veröffentlichen außerdem eine Projektwebsite mit dem Trajektorien-Datensatz, ein Repo mit dem Analysecode, um die Abbildungen nachzubauen, und ein kleines interaktives Spiel, Can You Guess the Token Cost?, das die Kernaussage des Papers in etwa dreißig Sekunden vermittelt. ↩

  2. Bai et al., Abbildung 1. Agentisches Coding liegt im Schnitt bei 4,17 Mio. Tokens pro Aufgabe und 1,86 $ Kosten, gegenüber 3,39k Tokens bei Code-Chat-Aufgaben und 1,19k Tokens bei einstufigem Code-Reasoning. Die 1.000-fach-Zahl ist das Verhältnis zum Reasoning, gegenüber dem Chat sind es etwa 1.200-fach. ↩

  3. Bai et al., Abbildung 6 und Abschnitt 4. Abschnitt 4 geht ausdrücklich auf den Einwand “schwerere Aufgaben kosten natürlich mehr” ein und zeigt, dass die Lücke in der Teilmenge der gemeinsamen Erfolge bleibt (n=230 Aufgaben, die jedes getestete Modell gelöst hat). Die Autoren beschreiben den Unterschied als “model-specific behaviour rather than intrinsic task difficulty.” ↩

  4. Bai et al., Abbildung 2a und 2b. Bis zu 30-fache Varianz zwischen Instanzen. Bei derselben Aufgabe über vier Durchläufe kostet der teuerste Durchlauf im Schnitt etwa das 2-Fache des günstigsten. ↩

  5. Bai et al., Abbildung 10 und Abbildung 11. Die beste Korrelation über alle acht Modelle ist 0,39 (Claude Sonnet 4.5, Output-Tokens). Die Vorhersage der Input-Tokens ist durchgehend schlechter als die der Output-Tokens. Jedes Modell schätzt systematisch zu niedrig. Abbildung 11 zeigt Vorhersagen, die durchweg deutlich unter der Diagonalen liegen. ↩

  6. Bai et al., Abbildung 3b. Die Genauigkeit steigt vom günstigsten zum zweitgünstigsten Quartil deutlich und bleibt dann auf diesem Niveau. Das dritte und vierte Quartil lassen sich statistisch nicht vom zweiten unterscheiden. ↩

  7. Bai et al., Abbildung 4 und Anhang A. Koeffizienten aus Mixed-Effects-Regressionen von etwa 4 für wiederholte Änderungen und 2 für wiederholte Ansichten im Quartil mit den höchsten Kosten, beide signifikant bei p < 0,001 gegenüber der Gruppe mit den niedrigsten Kosten, kontrolliert für die Modellidentität. Die Analyse der Output-Tokens im Anhang zeigt dasselbe Muster. ↩

  8. Flowstate. Ich habe es mitgegründet, es gilt also der naheliegende Hinweis auf einen Interessenkonflikt. ↩