Vier Wochen KI-Nutzung gemessen

Ich nutze Claude Code täglich und auf mehreren Rechnern. Neben der Abrechnung je Anfrage gibt es ein Kontingent pro Woche, und bei meiner Arbeitsweise wäre es nach drei Tagen erschöpft. Den Rest der Woche hätte ich ohne dagestanden, trotz größtem verfügbaren Abo.

Ich wollte wissen, wohin das Kontingent geht. Vier Wochen später hatte ich eine Antwort — an einer Stelle, an der ich nicht gesucht hatte.

94 Prozent der Kosten entstehen weder durch neu Hinzugekommenes noch durch die Antworten. Sie entstehen beim Wiederlesen dessen, was längst im Verlauf steht.

Ausgangslage

Claude Code legt zu jeder Sitzung eine Datei ab, in der jeder Aufruf mit seinen Tokenzahlen steht. Ein Skript, das diese Dateien ausliest, ist schnell geschrieben — ich hatte eins. Drei Probleme hatte es trotzdem:

Die Daten lagen je Rechner. Ich arbeite an zwei Windows-Arbeitsplätzen und einem MacBook. Jedes Skript kannte nur seinen eigenen Rechner. Für eine Gesamtsumme hätte ich drei Ergebnisse abtippen müssen, und für einen Vergleich über die Zeit dreimal an dieselbe Stelle denken.

Es gab keinen gemeinsamen Blick. Fragen wie „welcher Anteil geht auf Subagenten" ließen sich je Rechner beantworten, aber nicht zusammen — und genau das ist die Frage, die zählt.

Gelöschte Sitzungsdateien nehmen die Historie mit. Das ist der Punkt, der wehtut. Als der Dienst im Sommer zum ersten Mal lief, hat er brav alles eingelesen, was noch da war. Für April fand er sieben Tage, für Mai vier, für Juni vier, für Juli fünf. Nicht weil an den übrigen Tagen nicht gearbeitet wurde, sondern weil die Dateien nicht mehr existierten. Wer die Erfassung nachträglich aufsetzt, bekommt keine Historie, sondern Fragmente.

Deshalb ein Dienst, der laufend liest, statt eines Skripts, das gelegentlich läuft.

Aufbau

Auf jedem der drei Rechner läuft ein Dienst, der alle 15 Minuten die neuen Zeilen der Sitzungsdateien liest und an eine Schnittstelle meldet. Unter Windows ist das ein Windows-Dienst unter LocalSystem, auf dem Mac ein LaunchAgent. Der Ablauf ist auf beiden Plattformen derselbe; unterschiedlich ist nur, wie das Betriebssystem den Prozess am Leben hält.

Die Schnittstelle nimmt die Meldungen entgegen und erkennt Doppelmeldungen an der Aufruf-Kennung — ein verpasster oder ein doppelter Durchlauf ist damit folgenlos. Das ist wichtiger, als es klingt: Ein zugeklapptes Notebook verpasst jeden festen Zeitpunkt, und ein Intervall zählt nach dem Aufwachen einfach weiter.

Gespeichert wird in einer Datenbank, ausgewertet über Sichten, die die Tokenzahlen mit den hinterlegten Preisen verrechnen. Ein Grafana-Dashboard zeigt den laufenden Stand.

Die Bauteile sind gewöhnlich. Interessant ist, was dabei herauskommt.

Was die Zahlen zeigen

Alle Angaben für den 1. bis 29. August 2026, alle drei Rechner zusammen. Sämtliche Kostenangaben in diesem Beitrag sind Listenpreise — der Betrag, den dieselbe Nutzung über die API gekostet hätte. Genutzt wurde ein Pauschalabo; es ist keine Rechnungssumme, und es hat auch niemand diesen Betrag bezahlt.

Kennzahl	Wert
Tage mit Nutzung	27
Aufrufe	57.525
Tokens gesamt	15,00 Milliarden
Listenpreis gesamt	10.778,69 USD
Listenpreis je Tag mit Nutzung	399,21 USD
Sitzungen	223

Kurz zu den vier Tokenarten, weil daran alles hängt. Ein Token ist ein Wortstück, grob drei bis vier Zeichen. Das Modell hat kein Gedächtnis: Bei jedem Aufruf geht der gesamte Eingabekontext erneut mit — Systemanweisungen, Projektinformationen, alle früheren Nachrichten und alle bisherigen Werkzeugergebnisse. Die drei Eingabearten sagen nicht, <em>was</em> im Kontext steht, sondern <em>wie</em> es verarbeitet und abgerechnet wird.

Eingabe ist der Teil, der neu hinzukommt und nicht aus dem Zwischenspeicher stammt — der aktuelle Prompt, aber genauso ein frisch eingelesenes Werkzeugergebnis. Alles, was schon einmal da war, wird einmal abgelegt (Cache schreiben, teurer als Eingabe) und danach bei jedem weiteren Aufruf von dort gelesen (Cache lesen, deutlich billiger, aber eben jedes Mal aufs Neue). Ausgabe ist, was das Modell erzeugt, einschließlich der Denkschritte, die in der sichtbaren Antwort gar nicht auftauchen.

Die Verteilung der Tokens ist so einseitig, dass ein normales Balkendiagramm nur einen Balken zeigen würde:

Tokenart	Tokens	Anteil	Listenpreis	Anteil
Eingabe	383.642	0,003 %	1,89 USD	0,02 %
Ausgabe	25.967.854	0,17 %	649,48 USD	6,03 %
Cache schreiben	388.545.571	2,59 %	2.870,62 USD	26,63 %
Cache lesen	14.586.175.336	97,23 %	7.256,70 USD	67,32 %

Auf ein Eingabe-Token kommen 38.020 aus dem Cache gelesene. Das ist kein Ausreißer, das ist der Normalbetrieb: Bei jedem Aufruf wird der bisherige Gesprächsverlauf erneut gelesen. Neu hinzu kommt daneben so wenig, dass es kaum ins Gewicht fällt — die 383.642 Eingabe-Token des ganzen Monats kosten zusammen 1,89 USD. Darin steckt alles Neue: mein Getipptes ebenso wie jedes frisch eingelesene Werkzeugergebnis.

Der zweite Blick auf dieselbe Tabelle ist der interessantere. Cache-Schreiben ist mit 2,59 Prozent der Tokens für 26,63 Prozent der Kosten verantwortlich, weil es teurer abgerechnet wird als alles andere. Zusammen kommen die beiden Cache-Arten auf 10.127,32 USD von 10.778,69 — knapp 94 Prozent.

Der Cache wird als Sparmaßnahme beschrieben, und das ist er auch: Ohne ihn wäre derselbe Verlauf zu Eingabepreisen abgerechnet worden und die Rechnung um ein Vielfaches höher. Nur bedeutet das eben nicht, dass er nicht ins Gewicht fällt. Er ist der Kostenblock. Wer an dieser Nutzung sparen will, muss an der Länge der Verläufe ansetzen, nicht an der Länge der Prompts.

Beim Verlauf über den Monat gibt es wenig zu deuten: Der teuerste Tag liegt bei 1.428,47 USD, an zwei Tagen wurde gar nicht gearbeitet. Das Bild zeigt Arbeitstage, keine Systematik.

Bei den Quellen wird es wieder deutlich:

Quelle	Aufrufe	Listenpreis
Hauptsitzung	26.221	5.621,63 USD
Subagent	31.299	5.156,40 USD
Agent-Modus	5	0,65 USD

Subagenten stellen 54 Prozent der Aufrufe und 48 Prozent der Kosten. Sie sind keine Randerscheinung, sondern die knappe Mehrheit des Betriebs. Dass sie je Aufruf günstiger sind als die Hauptsitzung, passt zum Bild: Ein Subagent startet mit einem frischen, kurzen Verlauf, die Hauptsitzung schleppt ihren gesamten Kontext mit.

Ein Modell dominiert: 99,2 Prozent der Listenkosten entfallen auf Opus. Die günstigeren Modelle kommen zusammen auf 85 USD. Wer die Modellwahl als Sparhebel betrachtet, sollte wissen, dass hier faktisch keine stattfindet.

Was überrascht hat

Der Dienst meldet neben den Tokenzahlen auch den Stand des Nutzungskontingents — jenen Prozentwert, den Claude Code selbst anzeigt. Ich hatte erwartet, dass jeder Rechner seinen eigenen Stand meldet und die Werte auseinanderlaufen.

Sie laufen nicht auseinander. An den Tagen, an denen alle drei Rechner gemeldet haben, steht überall derselbe Wert: am 6. August 27 Prozent auf allen dreien, am 12. August 13, am 29. August 72. Auseinander laufen die Werte nur an den Tagen, an denen das Wochenkontingent zurückgesetzt wird — dann hat einer davor und die anderen danach gemessen.

Das Kontingent zählt für das Konto, nicht für den Rechner. Im Nachhinein ist das die naheliegende Auslegung, und vermutlich steht es auch irgendwo. Aufgefallen ist es mir erst, als drei Rechner nebeneinander in derselben Tabelle standen — mit einem Skript je Rechner hätte ich es nie gesehen. Praktisch heißt das: Auf einen zweiten Rechner auszuweichen, wenn das Limit näher rückt, bringt nichts.

Der zweite überraschende Wert ist der Abstand zwischen beiden Welten. Im Messzeitraum kam das Wochenkontingent auf höchstens 96 Prozent, das Fünf-Stunden-Fenster auf höchstens 68. Die Nutzung passte also durchweg in das Pauschalabo — und hätte über die API 10.778,69 USD gekostet.

Was ich daraufhin geändert habe

Die Maßnahmen stammen aus der letzten Augustwoche und stecken damit nur im letzten Drittel des Messzeitraums. Ein Vorher-Nachher-Vergleich steht noch aus.

Kleinere Modelle für Rollen, die keine Entwurfsentscheidungen treffen. Zuerst liefen alle Agenten auf Sonnet — das war zu weit gegriffen. Product Owner, Entwickler und Reviewer standen nach zwei Tagen wieder auf Opus. Auf Sonnet geblieben sind Übersetzer, Orchestrator und Tester sowie die mechanischen Befehle: Commit-Message aus dem Diff, Push, Tagesdokumentation. Die Modellwahl hilft dort, wo eng vorgegeben ist, was zu tun ist. Sonst kostet sie mehr, als sie spart.

Das große Kontextfenster abgeschaltet. Bis dahin lief Opus 5 mit dem Ein-Millionen-Token-Fenster. Ein größeres Fenster spart nichts — es hebt nur die Grenze, bis zu der ein Verlauf wachsen darf, und jedes Token mehr im Verlauf wird bei jedem weiteren Aufruf erneut gelesen.

Den Kontext kurz halten. SQL-Abfragen mit TOP (n), Dateien ausschnittsweise statt ganz lesen, Build-Ausgaben filtern, Subagenten-Aufträge auf eine Komponente zuschneiden, Ergebnisse als Datei- und Zeilenangabe zurückgeben statt als Rohinhalt. Das zielt direkt auf die 97 Prozent: Jede Werkzeugausgabe, die einmal im Verlauf steht, wird bei jedem weiteren Aufruf mitgelesen und mitgerechnet.

Neue Aufgaben nur in frischer Sitzung. Ein Hook lehnt Befehle, die eine neue Aufgabe starten, in einer bereits gefüllten Sitzung ab und verweist auf /clear. Dieselbe Begründung: Der alte Verlauf hat mit der neuen Aufgabe nichts zu tun, wird aber ab dann bei jedem Aufruf mitgelesen.

Warteschleifen abgestellt. Ein zweiter Hook unterbindet Polling — etwa im Sekundentakt zu prüfen, ob eine Testergebnisdatei schon existiert. Jede dieser Prüfungen ist ein voller Aufruf mit dem gesamten bisherigen Verlauf.

Ein Nebenbefund. Der Reviewer lief eine Zeit lang mit dem Aufwandsgrad xhigh. Den Wert gibt es nicht — in keiner Protokollzeile taucht er auf, belegt sind nur high und max. Wer Stellschrauben dreht, sollte hinterher nachsehen, ob sie mit irgendetwas verbunden sind.

Was ich anders machen würde

Früher anfangen. Der teuerste Fehler steht schon in der Ausgangslage: Für die Monate vor August habe ich Fragmente statt Daten, weil die Sitzungsdateien beim Aufsetzen der Erfassung längst gelöscht waren. Ein Dienst, der laufend liest, kann keine Historie herstellen — er kann nur ab jetzt aufhören, welche zu verlieren. Wer so etwas plant, sollte den einfachsten denkbaren Sammler sofort in Betrieb nehmen und die saubere Lösung danach bauen.

Die Dimension, von der ich mir am meisten versprochen hatte, ist die dünnste. Zu jedem Aufruf wird die Rolle des Subagenten erfasst — Tester, Entwickler, Reviewer. Bei 24.129 der 31.299 Subagenten-Aufrufe steht dort nichts, weil die generischen Subagenten keine benannte Rolle tragen. Die Auswertung, auf die ich am neugierigsten war, lässt sich mit diesen Daten nicht seriös machen. Das ist kein Fehler der Erfassung, sondern eine falsche Erwartung an die Quelle — die hätte ich vorher prüfen sollen, statt eine Spalte dafür anzulegen.

Das Projektfeld ist erfasst und unbenutzbar. Der Projektname entspricht dem Verzeichnisnamen. In der Datenbank stehen 24 davon, und keiner lässt sich hier zeigen, weil er unmittelbar auf Auftraggeber und Vorhaben schließen lässt. Für eine interne Auswertung ist das Feld nützlich, für alles Öffentliche wertlos. Eine stabile Pseudonymisierung schon beim Erfassen hätte beides ermöglicht.

Die Preise stehen in der Datenbank, nicht im Code. Das ist die eine Entwurfsentscheidung, die sich nach vier Wochen uneingeschränkt bewährt hat. Zwischen April und August sind neue Modelle dazugekommen; eingetragen wurden sie in einer Tabelle, ohne den Dienst auf drei Rechnern anzufassen.

Und die Ausgangsfrage, wohin das Kontingent geht? In die Länge der Verläufe. Nicht in die Prompts, nicht in die Modellwahl — und auf einen zweiten Rechner auszuweichen hilft ebenfalls nicht.

Die Diagramme dieses Beitrags sind feste Bilder für einen abgeschlossenen Zeitraum, keine laufenden Abfragen. Diese Website greift auf die Nutzungsdatenbank nicht zu.