Doppelt so viele Token, nur zehn Prozent mehr Commits: Was JetBrains-Daten verraten

Darum geht es

Im Jahr 2026 ist der Token-Verbrauch zur Ersatzwährung für Fleiß geworden. Token sind die Textbausteine, nach denen KI-Anbieter abrechnen. Bei Meta rankte eine interne Liste namens „Claudeonomics“ Zehntausende Mitarbeitende nach ihrem Verbrauch. Salesforce gab laut dem Newsletter The Pragmatic Engineer Mindestbeträge vor. Nvidia-Chef Jensen Huang schlug auf der GTC im März vor, Ingenieuren zusätzlich zum Gehalt Token im Wert von etwa der Hälfte ihres Gehalts zu geben, „damit sie zehnfach verstärkt werden“. Für diese Sitte gibt es inzwischen einen eigenen Begriff: Tokenmaxxing, also möglichst viel KI-Verbrauch, damit man auf Ranglisten gut dasteht.

Bisher gab es dagegen vor allem Blogkritik und Anekdoten. Jetzt liegen erstmals Firmendaten vor. Im Preprint „The AI Era's Lines of Code?“ haben Forschende der Carnegie Mellon University, der UC Irvine und von JetBrains rund 3,1 Millionen Aufrufe von Coding-Agenten mit den Commits von 404 Entwicklern verknüpft. Commits sind gespeicherte Code-Änderungen. Der Titel spielt auf die Codezeilen an, die früher als Leistungsmaß missbraucht wurden. Die Frage dieses Artikels lautet: Was misst die Token-Zahl eigentlich, und was nicht?

Die Daten: fünf Wochen, zwei Agenten, keine Vorgaben

Die Studie umfasst fünf Wochen vom 29. Juni bis 2. August 2026. JetBrains hat rund 2.600 Beschäftigte. Fast alle Token liefen über zwei Agenten, die das Paper nicht nennt: „Agent A“ mit 69 Prozent und „Agent B“ mit 31 Prozent. Das Gateway, also die zentrale Durchgangsstation für alle Anfragen, protokollierte pro Aufruf die Token und die verrechneten internen Credits. Dazu kam eine anonyme Umfrage mit 412 Teilnehmenden, das sind 15,8 Prozent der Belegschaft.

Ein Detail ist für die Debatte wichtig: Die Nutzung war laut Paper freiwillig, es gab „kein Ziel und keine Vorgabe“. JetBrains war also kein Tokenmaxxing-Betrieb. Billig war es trotzdem nicht. Laut InfoQ sind die KI-Entwicklungskosten bei JetBrains binnen sechs Monaten etwa um das Zehnfache gestiegen. Die Firma hat deshalb eine zentrale Abrechnungsschicht eingeführt.

Die Kernzahlen und was sie genau bedeuten

Einige der kursierenden Zahlen werden gerne verkürzt. Die folgende Tabelle zeigt, was jeweils dahintersteckt:

Eine Elastizität gibt an, um wie viel Prozent sich eine Größe ändert, wenn sich eine andere um ein Prozent ändert. Ein Perzentil ist ein Rangplatz: Das 90. Perzentil liegt über 90 Prozent aller Werte.

Der Verbrauch hängt vor allem davon ab, wer die Person ist. Das erklärt laut Paper 79 Prozent der Streuung. Wer viel verbraucht, tut das jede Woche. Commits und geänderte Zeilen erklären nur 38 Prozent der Unterschiede zwischen Personen und nur 13 Prozent der Schwankungen von Woche zu Woche. Rolle, Team und Führungsposition sagten den Verbrauch neuer Personen sogar schlechter voraus als ein simpler Durchschnitt. Wochen mit hohem Verbrauch hatten auch keine größeren Commits.

Ein Ereignis treibt den Verbrauch messbar nach oben: ein neues Modell. In Woche 3 erschien ein neues Frontier-Modell, also ein Spitzenmodell, und machte binnen zwei Wochen 45 Prozent der Ausgaben aus. Wochen mit dem neuen Modell hatten bei gleicher Commit-Zahl etwa 45 Prozent mehr Token.

400 zu 1: Wohin die Token wirklich fließen

Der vielleicht wichtigste Befund steht etwas versteckt im Paper. Ein typischer Agenten-Aufruf (Median) schickt etwa 400-mal so viele Token an das Modell, wie er zurückbekommt. Generierter Text macht in normalen wie in teuren Wochen weniger als ein Prozent aller Token aus, nämlich 0,6 bzw. 0,9 Prozent. Fast alles ist Kontext: Code, Dateien, Logs und der bisherige Gesprächsverlauf, die der Agent bei jedem Schritt erneut mitschickt, ähnlich wie jemand, der vor jeder Rückfrage den ganzen Aktenordner noch einmal vorliest.

Hier kommt caveman ins Spiel, ein Projekt auf GitHub mit inzwischen rund 120.000 Sternen. Der Slogan: „why use many token when few token do trick“. Die bekannten „65 Prozent weniger Token“ sind auf der Projektseite nicht genau definiert. Die dort gemessenen Werte beziehen sich auf die Antworten: Bei zehn Entwicklerfragen sanken die Output-Token mit dem schärfsten Modus um etwa 61 Prozent gegenüber gar keiner Anweisung. Gegenüber einem schlichten „Antworte knapp“ waren es nur 3 bis 35 Prozent. Der Autor räumt selbst ein, dass die Regeln etwa 1.160 Token zusätzlichen Input kosten.

JetBrains hat den Skill im Juli unabhängig getestet. Laut InfoWorld und Botmonster lief der Test über 86 gepaarte Aufgaben in Claude Code. Die Output-Token sanken nur um rund 8,5 Prozent, Qualität und Laufzeit blieben unverändert. Ein erster Durchlauf mit zehn Aufgaben hatte noch etwa 30 Prozent ergeben. Insgesamt war der Benchmark mit caveman sogar teurer, weil eine einzelne Aufgabe die Schwelle für den teureren Langkontext-Tarif überschritt.

Unsere Rechnung mit den aktuellen Listenpreisen für Claude Opus 5.5 (4 Dollar pro Million Input-Token, 20 Dollar Output, 0,20 Dollar für Cache-Treffer, 5 Dollar fürs Schreiben in den Cache) und dem Verhältnis von 400 zu 1:

Die Rechnung ist eine Vereinfachung. Das 400:1-Verhältnis ist ein Medianwert pro Aufruf, kein Gesamtwert. Außerdem gehen Antworten in späteren Runden wieder als Input ein, kurze Antworten wirken also etwas nach. Die Größenordnung ist trotzdem eindeutig: Die Höhlenmenschen-Sprache kürzt den Teil, der kaum ins Gewicht fällt. Fairerweise muss man sagen, dass caveman inzwischen mehr kann. Ein Proxy-Modul namens „Read less“ komprimiert Logs, JSON- und Testausgaben, bevor das Modell sie liest. Nach eigenen Messungen des Projekts spart das in ganzen Sitzungen 33,2 Prozent Input-Token, unabhängig geprüft ist das nicht. Dieser Teil setzt genau dort an, wo das Paper ansetzen würde.

Was die Hersteller selbst raten

Die Kostenanleitung von Anthropic weist in dieselbe Richtung. Zuerst solle man Prompt-Caching einschalten, also die Zwischenspeicherung gleichbleibender Textteile, die beim erneuten Senden nur noch einen Bruchteil kosten. Ohne Caching wachsen die Kosten laut Anthropic ungefähr mit dem Quadrat der Gesprächsrunden. Bei Opus 5.5 kosten Cache-Treffer nur das 0,05-Fache des normalen Input-Preises. Liegt die Trefferquote unter etwa 80 Prozent, mache etwas den Cache kaputt, etwa ein Zeitstempel vor dem festen Textteil oder ein Wechsel der Effort-Stufe mitten in der Sitzung. Modelle solle man nach den Kosten pro erledigter Aufgabe vergleichen, nicht nach dem Preis pro Token. OpenAI berechnet für Cache-Treffer bei GPT-5.6 und neuer das 0,1-Fache, bei den GPT-6.1-Modellen das 0,05-Fache. Google gibt die Ersparnis bei Gemini automatisch weiter, nennt auf der Dokumentationsseite aber keinen Satz.

Der neue Leitfaden für Opus 5.5, über den The Decoder berichtet, räumt mit alten Gewohnheiten auf: „Think hard“ aus den Prompts streichen und mit der mittleren Effort-Stufe beginnen. Effort ist die Einstellung, wie viel das Modell nachdenkt und selbst prüft. Laut Anthropic erreicht Opus 5.5 auf „Medium“ das Niveau von Opus 5 auf „High“. Das sind Herstellerangaben. Auch die Aufgabenbeschreibung spielt eine Rolle: Ein Preprint von Jakub Smékal hat 2.700 Durchläufe mit Kimi K3 ausgewertet. Wurde eine vollständige Spezifikation auf eine knappe User Story gekürzt, stieg der Verbrauch um 29,7 Prozent, je nach Aufgabe um 13 bis 115 Prozent.

Wie Firmen gemessen haben und was davon übrig ist

Das Amazon-Memo enthält einen Satz, der gut zur Studie passt:

„Wenn deine Arbeit nicht von den aktuellen KI-Werkzeugen profitiert, ist das ein Befund, kein Versagen.“

Was die Autoren stattdessen empfehlen

Die Empfehlungen sind konkret. Token-Verbrauch solle höchstens zur Kostenabrechnung dienen. Man solle Leistung nicht daran messen und nicht erwarten, dass Verbrauchsziele den Output nennenswert steigern. Auch „Token pro Commit“ tauge nicht als Effizienzmaß, weil der Quotient automatisch sinkt, je mehr jemand committet. Für die Verbreitung von KI empfehlen die Autoren Zahlen, die nicht mit der Kontextgröße wachsen, etwa Nutzungstage. Budgets solle man über mehrere Wochen summieren, denn Fünf-Wochen-Summen ordnen Personen recht verlässlich ein (Reliabilität 0,87). Nach neuen Modell-Releases müsse man Budgets anpassen. Bevor man Obergrenzen einführt, solle man Kontext verwalten, wiederkehrenden Kontext cachen und Routinearbeit an günstigere Modelle geben. Gemessen werden sollen die abgerechneten Kosten statt der Token. Am Gateway solle man festhalten, welcher Aufgabe jede Sitzung diente.

Die Umfrage zeigt, warum Commits allein nicht reichen. In 89 Prozent der Bewertungen technischer Mitarbeitender nutzten diese die Agenten auch für Arbeit außer Programmieren, etwa für Datenanalyse (52 Prozent), Brainstorming (49) und Recherche (44). Der Median der selbst geschätzten Ersparnis lag bei 10 Stunden pro Woche. Dem stehen Kosten gegenüber: Fast die Hälfte der Nennungen zu Zeitverlusten betraf falsche oder schlechte Ergebnisse. 55 Prozent der Befragten mussten KI-Material von Kolleginnen und Kollegen bearbeiten, im Schnitt 1,6 Stunden pro Woche.

Einordnung

Die Studie ist der bislang beste Beleg dafür, dass Token-Zahlen vor allem Nutzungsintensität messen, und das sehr ungleich verteilt. Sie messen nicht den Wert der Arbeit. Die Grenzen nennen die Autoren selbst: Alle Ergebnisse sind Zusammenhänge, keine Ursachen, denn die Leute haben ihren Verbrauch selbst gewählt. Commits sind ein grobes Maß, Pull-Request-Daten fehlten. Die Daten decken nur fünf Wochen ab. JetBrains baut selbst KI-Werkzeuge, ein Teil des Verbrauchs könnte also Testarbeit sein. Und die Umfragewerte sind Selbstauskünfte. Ob sich die Ergebnisse auf Firmen mit Verbrauchszielen übertragen lassen, ist offen. Dort dürfte zusätzlicher Verbrauch eher noch weniger bringen, weil gezielt Leerlauf erzeugt wird. Das ist eine Vermutung, die die Studie nicht prüft.

Unsere Einschätzung: Wer gerade KI-Budgets für 2027 plant, sollte aus dem Paper drei Dinge mitnehmen. Erstens auf abgerechnete Kosten pro erledigter Aufgabe schauen statt auf Token-Ranglisten. Zweitens die Cache-Trefferquote prüfen, bevor Obergrenzen eingeführt werden. Drittens Budgets nach jedem großen Modellwechsel neu bewerten. Spar-Tricks an den Antworten der Agenten mögen Spaß machen, die Rechnung entsteht aber beim Kontext.