In Teil 1 habe ich meine SAP-Chats aufgeräumt: zwei getrennte Profile für Entwicklung und Beratung, ein Kickoff-Block pro Chat, und die Erkenntnis, dass sich „erst Sonnet, bei Bedarf Opus“ bis zu einer Eskalationsquote von 60 Prozent rechnet.
Blieb die Frage, ob das überhaupt wirkt. Und dahinter die unangenehmere: irgendwann kommen Abrechnungs- und Nachweissituationen, und dann willst du Zahlen haben. Also haben wir gemessen. Was dabei herauskam, hat die schöne Theorie aus Teil 1 gleich mal einsortiert.
Der Einstieg kostet null Aufwand
Beide Werkzeuge haben das eingebaut. In Claude Code zeigt /usage den Session-Block mit Input, Output, Cache-Read und Cache-Write je Modell:
Total cost: $0.55
Total duration (API): 6m 20s
Usage by model:
claude-sonnet-4-6: 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)Darunter steht auf einem Abo-Plan zusätzlich, welcher Anteil der letzten Nutzung auf Skills, Subagenten, Plugins und einzelne MCP-Server entfiel, plus Warnhinweise wie „langer Kontext“ oder „Cache-Miss“, sobald einer davon zehn Prozent oder mehr ausmacht. Mit d und w schaltest du zwischen 24 Stunden und sieben Tagen um. Wichtig: die Zähler setzen zurück, sobald du den Chat leerst. Eine Session ist also genau das, was zwischen zwei Aufräumaktionen liegt, was praktischerweise exakt zur Regel „ein Thema, ein Chat“ passt.
In Cowork gibt es dasselbe als Skill: /explain-usage erklärt für die laufende Session, wohin die Tokens geflossen sind, mit kleiner Grafik und in normaler Sprache statt in Zählerkolonnen. Für den Berateralltag ist das der Einstieg, weil dort niemand ein Terminal offen hat.
Der unterschätzte Befehl
Interessanter als beide ist aber /insights. Der beantwortet nicht „wie viel“, sondern „warum“. Er wertet die letzten Sessions auf der Maschine aus und schreibt einen HTML-Report:
~/.claude/usage-data/report.html # der aktuelle Lauf
# dazu eine Kopie mit Zeitstempel je Durchlauf, nichts wird überschriebenEin Lauf nimmt bis zu 200 noch nicht ausgewertete Sessions und überspringt die sehr kurzen. Im Kopf des Reports steht dann so etwas wie 200 sessions (412 total), damit du siehst, was fehlt. Inhaltlich geht es um Arbeitsmuster und Reibungspunkte: wo Anfragen missverstanden wurden, wo Code hinterher nicht lief, wo du dich im Kreis gedreht hast. Genau das sind die Stellen, an denen Tokens verbrennen, ohne dass eine Zahl es dir verrät.
Kleiner Haken mit Humorwert: der Lauf selbst verbraucht Tokens. Die Kostenanalyse kostet also Geld. Einmal im Monat statt stündlich, und das Ergebnis wegsichern.
Wenn es genauer sein soll: die Rohdaten
Die liegen lokal, ein JSONL-Transkript pro Session:
ls ~/.claude/projects/
# ein Eintrag je Arbeitsverzeichnis, Slashes werden zu Bindestrichen:
# /home/dev/kunden/kunde-a -> -home-dev-kunden-kunde-aDer Dateiname ohne Endung ist die Session-ID. In jeder Antwortzeile steckt ein Usage-Objekt:
{
"input_tokens": 2,
"cache_read_input_tokens": 0,
"output_tokens": 1417,
"output_tokens_details": { "thinking_tokens": 528 },
"cache_creation": {
"ephemeral_1h_input_tokens": 69202,
"ephemeral_5m_input_tokens": 0
}
}Selber parsen musst du das zum Glück nicht. Es gibt ccusage, ein Open-Source-Werkzeug, das genau diese Verzeichnisse liest und ohne Installation läuft:
npx ccusage session # eine Zeile je Session
npx ccusage session --json # maschinenlesbar, mit Session-ID und Kosten
npx ccusage session --breakdown # nach Modell aufgeschlüsselt
npx ccusage session --since 20260801 --until 20260831
npx ccusage daily # Tages- und Monatssummen gibt es auchDer Kostenmodus ist wählbar: --mode calculate rechnet aus den Tokenzählern, --mode display zeigt nur vorberechnete Werte. Das Werkzeug ist unabhängig von Anthropic, für den unternehmensweiten Einsatz solltest du also selbst draufschauen, bevor du es allen ausrollst.
Uns hat am Ende ein eigenes Python-Skript besser gepasst, weil wir eine Spalte mehr brauchten: das Arbeitsverzeichnis als Mandatszuordnung, damit die CSV direkt zum Projekt passt. Und das war auch der Moment, in dem die Zahlen unbequem wurden.
Der Befund
Eine ganz normale Arbeitssession, großes Modell, 69 Turns, gut zweieinhalb Stunden:
| Tokenart | Menge | Kostenanteil |
|---|---|---|
| Input, ungecacht | 138 | ca. 0 $ |
| Output | 99.367 | 2,48 $ |
| Cache-Read | 5,88 Mio. | 2,94 $ |
| Cache-Write (1 Std.) | 1,19 Mio. | 11,94 $ |
| Summe | 7,18 Mio. | 17,37 $ |
Der klassische Input: 138 Tokens. Einhundertachtunddreißig. Praktisch bedeutungslos. Zwei Drittel der Kosten entstehen beim Cache-Schreiben.
Das ergibt Sinn, wenn man die Multiplikatoren kennt. Ein Cache-Treffer kostet nur 0,1 mal Input, das Schreiben in den Cache dagegen 1,25 mal (fünf Minuten Haltbarkeit) oder 2 mal (eine Stunde). Jeder Cache-Miss nach einer längeren Pause schreibt den kompletten Kontext neu. Und weil der ganze Verlauf bei jedem Turn erneut mitgeht, wachsen die Inputkosten quadratisch mit der Turn-Zahl: ein Chat mit 40 Turns kostet grob das Vierfache von vier Chats mit je zehn.
Damit hat sich unsere Prioritätenliste aus Teil 1 gedreht. Sessionhygiene schlägt Modellwahl. Ein Thema, ein Chat, dazwischen konsequent aufräumen: das ist der Hebel, der nichts kostet außer einer Gewohnheit, und er wirkt stärker als jeder Preisunterschied zwischen den Modellen. Die 60-Prozent-Regel bleibt richtig, sie ist nur nicht Platz eins.
Irrweg: die Dollarzahl ist keine Rechnung
Weil die Abrechnungsfrage der eigentliche Anlass war, haben wir weitergefragt. Und da liegt eine Falle, die man besser vor dem ersten Kundengespräch kennt.
Der Betrag, den die Werkzeuge anzeigen, ist auf einem Abo-Plan eine lokal berechnete Schätzung zu Listenpreisen. Sie kennt weder eure Konditionen noch Rabatte, stammt nur von dieser einen Maschine, und als Rechnungsposten existiert sie schlicht nicht: das Kontingent hängt am Sitzplatz, nicht an der Session. Als Steuerungsgröße taugt sie, als Beleg nicht. Wer echte Belege braucht, muss auf API-Nutzung mit einem eigenen Bereich je Kunde wechseln, und zahlt dann pro Token statt pauschal.
Irrweg: die Daten sind nach 30 Tagen weg
Die Sache, die uns fast durchgerutscht wäre: die Transkripte werden nach 30 Tagen automatisch gelöscht. Standardwert, unspektakulär dokumentiert, brutal in der Wirkung. Wer im Quartalsgespräch nach Belegen sucht, findet ein leeres Verzeichnis. Wenn diese Daten eure Nachweisgrundlage werden sollen, braucht ihr einen monatlichen Export, bevor die Rohdaten verfallen. Ein Cronjob am Monatsanfang reicht.
Zweiter Punkt, im Kundenkontext ernst zu nehmen: die Transkripte sind Klartext und unverschlüsselt. Alles, was durch ein Werkzeug lief, steht darin, inklusive Dateiinhalten und Kommandoausgaben. Das gehört vorher durch Betriebsvereinbarung und Vertraulichkeitsprüfung, nicht hinterher.
Und dann die unbequeme Frage
Am Ende stand die Rechnung, die ich eigentlich zuerst hätten machen sollen. Als Größenordnung werden rund 150 bis 250 Dollar pro Entwickler und Monat genannt. Gegen einen Beratertagessatz ist das der Gegenwert von etwa einer Stunde.
Für einen Betrag in dieser Größe eine sessiongenaue Einzelabrechnung aufzubauen, ist ökonomischer Unfug. Ein Pauschalzuschlag ist billiger in der Erstellung und deutlich weniger angreifbar als eine Schätzung, die sich als Rechnung ausgibt. Die Messung brauche ich trotzdem, aber zum Steuern, nicht zum Abrechnen.
Learnings
- Drei Befehle, drei Fragen.
/usageund/explain-usagesagen dir, wie viel./insightssagt dir, warum. Skripte brauchst du erst, wenn du auf Mandate umlegen willst. - Cache-Write ist der größte Einzelposten. In unserer Messung zwei Drittel der Kosten. Der klassische Input ist Rauschen.
- Sessionhygiene vor Modellwahl. Der Kontext wächst quadratisch, das schlägt jeden Preisunterschied zwischen den Modellen.
- Die angezeigte Zahl ist eine Schätzung, keine Rechnung. Auf einem Abo-Plan gibt es keinen Rechnungsposten pro Session.
- 30 Tage Aufbewahrung. Wer Nachweise braucht, exportiert monatlich, sonst ist die Grundlage weg, bevor jemand danach fragt.
- Erst prüfen, ob sich der Nachweisaufwand lohnt. Manchmal ist die richtige Antwort auf „wie rechnen wir das ab“ schlicht: gar nicht einzeln.