Claude Code: Verbrauch pro Sitzung messen und sehen, welche Sitzung Ihren Tarif auffrisst

Wenn Sie mehrere Sitzungen von Claude Code parallel laufen lassen, schrumpft Ihr Wochenlimit schneller als erwartet. Sie möchten wissen, welche Sitzung es auffrisst, doch /usage verrät es Ihnen nicht.

Die kurze Antwort: Stand September 2026 gibt es keine offizielle Ansicht, die zeigt, welchen Anteil Ihres Verbrauchs jede Sitzung hatte. /usage liefert die Zahlen der aktuellen Sitzung sowie den Verbrauch Ihres gesamten Tarifs, prozentual aufgeteilt nach Skill, Subagent, Plugin und MCP-Server. Wer es pro Sitzung sehen will, muss die Gesprächsprotokolle (Logs) auswerten, die auf dem eigenen Rechner liegen.

Zählt man diese Protokolle naiv, liegt man allerdings daneben. Als ich die Protokolle der letzten 7 Tage auf meinem Rechner gemessen habe, ergab das bloße Addieren der Zeilen eine Summe vom 2,06-Fachen des korrekten Werts. Schlimmer noch: Schon unter den 12 verbrauchsstärksten Sitzungen schwankte dieser Fehler zwischen dem 1,30- und dem 3,02-Fachen, sodass sich sogar die Rangfolge änderte. Dieser Artikel zeigt, was die offiziellen Ansichten tatsächlich anzeigen, wie man richtig zählt, ein Auswertungsskript von rund 50 Zeilen und was ich gemessen habe.

1. Was die offiziellen Ansichten zeigen und was nicht

Das sind die wichtigsten offiziellen Stellen, die Verbrauch anzeigen (Stand September 2026). Keine davon zeigt den Anteil jeder Sitzung. Am nächsten kommt die Tarif-Aufschlüsselung in /usage, doch ihre Achse ist, in welche Funktion der Verbrauch floss, und nicht, welche Sitzung ihn verursacht hat.

Quelle: Claude Code Dokumentation, „Manage costs effectively“ (/usage, /insights, Dashboards für Organisationen), Claude Code Dokumentation, „Desktop“ (Verbrauchsring), Claude Hilfecenter, „Usage limit best practices“ (die Usage-Seite in den Settings), Claude Code Dokumentation, „Monitoring“ (OpenTelemetry)

Zur Tarif-Aufschlüsselung in /usage sagt die Dokumentation noch etwas Wichtiges: „Die Werte sind Näherungen und werden aus dem lokalen Sitzungsverlauf auf diesem Rechner berechnet, daher ist Verbrauch von anderen Geräten oder von claude.ai nicht enthalten.“ Mit anderen Worten: Auch die offizielle Aufschlüsselung stammt letztlich aus Ihren lokalen Protokollen. Wenn Sie dieselben Protokolle selbst lesen, können Sie sie entlang der Achse auswerten, die die offiziellen Ansichten auslassen: der Sitzung. Haben Sie das Limit bereits erreicht und wollen prüfen, was noch übrig ist, lesen Sie Claude Code „usage limit reached“: Limits verstehen und weiterarbeiten.

2. Die Antwort steckt in Ihren lokalen Gesprächsprotokollen

Claude Code speichert den vollständigen Verlauf jedes Gesprächs als JSONL (ein JSON-Objekt pro Zeile), eine Datei pro Sitzung. Wo sie liegen, steht in der Dokumentation.

Quelle: Claude Code Dokumentation, „Explore the .claude directory“

Auf meinem Rechner war der Ordnername <Projekt> der absolute Pfad des Arbeitsordners, in dem die Sonderzeichen durch - ersetzt sind (aus D:\work\site-a wird D--work-site-a). Sitzungen aus dem Code-Tab der Desktop-App wurden an denselben Ort geschrieben, und in jeder Zeile stand "entrypoint":"claude-desktop".

Ausgewertet wird das Feld usage in den Zeilen, die Antworten von Claude festhalten ("type":"assistant"). Hier eine echte Zeile, reduziert auf die Felder, die die Auswertung nutzt (IDs unkenntlich gemacht).

{"type":"assistant","requestId":"req_…","timestamp":"2026-07-25T00:16:37.822Z",
 "message":{"id":"msg_…","model":"claude-opus-5",
  "content":[{"type":"text","text":"…"}],
  "usage":{"input_tokens":2,"output_tokens":255,
           "cache_read_input_tokens":33775,"cache_creation_input_tokens":17265,
           "cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":17265}}}}

Die vier Zahlen in usage (Eingabe, Ausgabe, Cache-Lesen, Cache-Schreiben) sind offizielle Felder in den Antworten der Claude API. Das Format der Protokolldatei selbst, also was in jede Zeile geschrieben wird, ist nicht offiziell dokumentiert. Die Zählweise in diesem Artikel habe ich an meinen eigenen Protokollen von v2.1.197 bis v2.1.260 geprüft; in künftigen Versionen funktioniert sie womöglich nicht mehr.

Eine weitere Warnung steht ausdrücklich in der Dokumentation: „Transkripte und Verlauf werden auf dem Datenträger nicht verschlüsselt. Der einzige Schutz sind die Dateiberechtigungen des Betriebssystems.“ Liest ein Tool eine .env-Datei, landet deren Inhalt ebenfalls im Protokoll. Ausgewertete Ergebnisse mit anderen zu teilen, ist unproblematisch, aber seien Sie vorsichtig, wenn Sie die Protokolle selbst weitergeben oder ein Tool, das Sie nicht gut kennen, sie lesen lassen.

3. Einfach addiert ergibt sich etwa das Doppelte: vier Fallen

Die usage-Zeilen suchen und alles addieren: Das ist der naheliegendste Ansatz, doch in meinen Protokollen kam dabei etwa das Doppelte des korrekten Werts heraus. Dafür gibt es vier Gründe.

Falle 1: Eine Antwort verteilt sich auf mehrere Zeilen

Eine Antwort von Claude (eine API-Anfrage) ist nicht unbedingt eine Zeile im Protokoll. Auf meinem Rechner wurde jeder Inhaltsblock, etwa Denken, Text oder ein Tool-Aufruf, als eigene Zeile geschrieben (mehr als 99,9 % der Zeilen enthielten genau einen Block), und jede dieser Zeilen trug usage. Eine Antwort erkennt man am Paar aus message.id und requestId.

Von den 142.345 Antworten, die sich über zwei oder mehr Zeilen erstreckten, hatten 76 % in jeder Zeile exakt dasselbe usage. Bei den übrigen 24 % unterschied sich die Zahl der Ausgabe-Tokens von Zeile zu Zeile. Behalten Sie deshalb pro Antwort nur die eine Zeile mit der höchsten Zahl an Ausgabe-Tokens. Unabhängig davon tauchten 1.903 Antworten zusätzlich in einer anderen Datei auf (0,95 % aller Tokens). Den Grund habe ich nicht ermittelt, aber wenn Sie alles über denselben Schlüssel zusammenführen, werden auch diese nicht doppelt gezählt.

Falle 2: Subagenten stehen in eigenen Dateien

Wer nur die Haupt-.jsonl-Dateien liest, verliert die Subagenten komplett. In meinen Protokollen entfielen folgende Anteile der korrekten Summen auf Subagenten.

• Eingabe (nicht gecacht): 42,9 %
• Ausgabe: 23,2 %
• Cache-Schreiben: 10,8 %
• Cache-Lesen: 6,9 %

Pro Sitzung ist die Spanne noch größer: In den letzten 7 Tagen reichte sie, nach Preis gewichtet, von Sitzungen mit 0 % bis zu einer Sitzung mit 54 %. Je mehr Arbeit eine Sitzung an Subagenten abgibt, desto kleiner wirkt sie, wenn man nur die Hauptdatei zählt.

Falle 3: Die beiden Fehler heben sich teilweise auf, aber in jeder Sitzung anders

Addiert man die Zeilen der Hauptdateien unverändert, bläht Falle 1 die Zählung auf, während Falle 2 sie schrumpfen lässt. Über die letzten 7 Tage ergab die Summe das 2,06-Fache des korrekten Werts. Läge jede Sitzung um denselben Faktor daneben, wären die Anteile trotzdem richtig. In der Praxis war das nicht so.

Quelle: eigene Messung (die letzten 7 Tage, Stand 15. September 2026. Damit der Vergleich leichter fällt, nutzt nur diese Tabelle ungewichtete Token-Zahlen, auch beim Subagenten-Anteil. Die Buchstaben der Sitzungen entsprechen der Grafik oben)

Platz 2 und 3 tauschten, ebenso 4 und 5, und G, eigentlich auf Platz 9, rückte auf Platz 6 vor. Dass D klein ausfällt, weil die Sitzung stark auf Subagenten setzt, ist genau Falle 2, doch E, mit demselben Subagenten-Anteil von 39 % wie D, lag mit dem 2,60-Fachen in der anderen Richtung daneben. Auch wie viele Zeilen jede Antwort umfasst (wie viel Denken und wie viele Tool-Aufrufe sie enthält), spielt mit, deshalb lässt sich der Faktor nicht vorab abschätzen. „Einfach durch zwei teilen“ funktioniert nicht.

Falle 4: 97 % der Tokens sind Cache-Lesezugriffe

Selbst wenn Sie korrekt zählen, führt der Vergleich roher Token-Zahlen zu einem falschen Bild davon, wie schwer jede Sitzung wiegt. So setzten sich die letzten 7 Tage zusammen.

Die Preise pro Einheit liegen jedoch weit auseinander. Laut der offiziellen Preisseite von Anthropic kostet Cache-Lesen das 0,1-Fache des Basis-Eingabepreises (das 0,025-Fache bei Claude Fable 5.1 und Claude Mythos 5.1), Cache-Schreiben mit 5 Minuten Lebensdauer das 1,25-Fache und mit 1 Stunde das 2-Fache, und Ausgabe kostet bei allen aktuellen Modellen das 5-Fache des Eingabepreises. Sitzung C, auf die 12,7 % der Tokens entfielen, kam nach dieser Preisgewichtung auf 10,4 %.

Schon die Größenordnung der Zahlen sagt etwas aus. Von den 12 größten Sitzungen lasen die 10 außer D und E im Schnitt rund 410.000 bis 480.000 Tokens Kontext pro Antwort (D und E, die stark auf Subagenten setzen, kamen auf etwa 240.000 und 310.000). „Claude Code sendet mit jeder Anfrage das gesamte Gespräch“, daher wird jede Anfrage schwerer, je länger eine Sitzung offen bleibt. Wie das im Detail funktioniert, erklärt Claude Code: Was frisst eigentlich Ihren Kontext?

4. Das Auswertungsskript

Dieses Auswertungsskript berücksichtigt alle vier Fallen. Es kommt allein mit der Standardbibliothek von Python 3 aus (getestet habe ich es mit 3.11). Es liest die Protokolle nur und verändert oder sendet nichts. Wenn Sie Ihr Konfigurationsverzeichnis über die Umgebungsvariable CLAUDE_CONFIG_DIR verlegt haben, liest es stattdessen von dort.

import json, os, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from pathlib import Path

DAYS = float(sys.argv[1]) if len(sys.argv) > 1 else 7
ROOT = Path(os.environ.get("CLAUDE_CONFIG_DIR") or Path.home() / ".claude") / "projects"
SINCE = datetime.now(timezone.utc) - timedelta(days=DAYS)
# USD per 1M input tokens (output = 5x). First match wins.
PRICES = [("sonnet-5", 2), ("sonnet", 3), ("haiku", 1), ("opus-4-1", 15),
          ("opus-4-2025", 15), ("opus", 5), ("fable", 10), ("mythos", 10)]

best = {}  # one API response = one (message.id, requestId)
for path in ROOT.rglob("*.jsonl"):  # also reads <session>/subagents/*.jsonl
    project = path.relative_to(ROOT).parts[0]
    with path.open(encoding="utf-8", errors="replace") as f:
        for line in f:
            if '"usage"' not in line:
                continue
            try:
                row = json.loads(line)
            except ValueError:
                continue
            msg = row.get("message") or {}
            usage = msg.get("usage")
            ts = row.get("timestamp")
            if row.get("type") != "assistant" or not usage or not ts:
                continue
            if datetime.fromisoformat(ts.replace("Z", "+00:00")) < SINCE:
                continue
            key = (msg.get("id"), row.get("requestId"))
            old = best.get(key)
            if old is None or usage.get("output_tokens", 0) >= old[2].get("output_tokens", 0):
                best[key] = (project, msg.get("model") or "", usage)

totals = defaultdict(lambda: [0, 0.0])  # [tokens, weight]
for project, model, u in best.values():
    p = next((v for name, v in PRICES if name in model), 5)
    read_rate = 0.025 if "5-1" in model and ("fable" in model or "mythos" in model) else 0.1
    inp, out = u.get("input_tokens", 0), u.get("output_tokens", 0)
    read, write = u.get("cache_read_input_tokens", 0), u.get("cache_creation_input_tokens", 0)
    write_1h = (u.get("cache_creation") or {}).get("ephemeral_1h_input_tokens", 0)
    totals[project][0] += inp + out + read + write
    totals[project][1] += p * (inp + out * 5 + read * read_rate
                               + (write - write_1h) * 1.25 + write_1h * 2)

all_tokens = sum(t for t, _ in totals.values()) or 1
all_weight = sum(w for _, w in totals.values()) or 1
print(f"last {DAYS:g} days: {len(best):,} responses")
print(f"{'weight':>7} {'tokens':>7}  project")
for project, (t, w) in sorted(totals.items(), key=lambda kv: -kv[1][1]):
    print(f"{w / all_weight:7.1%} {t / all_tokens:7.1%}  {project}")

Speichern Sie es etwa als usage_by_session.py und übergeben Sie die Anzahl der Tage als Argument. Ohne Argument erhalten Sie die letzten 7 Tage.

python usage_by_session.py        # letzte 7 Tage
python usage_by_session.py 1      # letzte 24 Stunden
python usage_by_session.py 30     # letzte 30 Tage

Die Ausgabe sieht so aus (Ordnernamen unkenntlich gemacht). weight ist der preisgewichtete Anteil, tokens der Anteil nach roher Token-Zahl.

last 7 days: 19,991 responses
 weight  tokens  project
  32.3%   31.7%  D--work-project-a
  11.1%   11.4%  D--work-project-b
  10.4%   12.7%  D--work-project-c
   7.7%    8.6%  D--work-project-d
   6.4%    5.4%  D--work-project-e

5. Gemessen: Eine von 29 Sitzungen verbrauchte fast ein Drittel

In den letzten 7 Tagen waren auf meinem Rechner 29 Sitzungen aktiv. Wie die Grafik oben zeigt, konzentrierte sich der Verbrauch auf eine Handvoll davon.

Nebeneinandergestellt zeigten die Zahlen drei Dinge.

Erstens: Die Sitzungen an der Spitze sind bei jeder einzelnen Anfrage schwer. Die Top 3 lasen im Schnitt rund 410.000 bis 480.000 Tokens pro Antwort. Sie stellten nicht einfach mehr Anfragen: Sie blieben den ganzen Tag offen, während ihr Kontext immer weiter wuchs. Auch die Dokumentation weist darauf hin, dass in einer lange offenen Sitzung selbst eine einzeilige Frage Verbrauch in Höhe des gesamten Gesprächs verursacht.

Zweitens: Sitzungen, die stark auf Subagenten setzen, wirken vom Hauptgespräch aus klein. Bei D und E entfielen 44 % bzw. 54 % des preisgewichteten Verbrauchs auf Subagenten. Wer sich das Hauptgespräch in der Seitenleiste ansieht, bekommt diesen Teil nie zu Gesicht.

Drittens: Mehr als die Hälfte der Sitzungen verbrauchte fast nichts. Ihr Limit schrumpft nicht deshalb schneller, weil viele Sitzungen offen sind; es sind einige wenige schwere Sitzungen, die es aufzehren. Wenn Sie etwas unternehmen wollen, genügt es, bei diesen wenigen anzufangen. Was Sie zuerst kürzen sollten, behandelt Claude Code Token-Spar-Tipps und die Zusatzkosten am Limit.

6. Wie die Zahlen zu lesen sind und wo sie enden

7. Wer ab jetzt fortlaufend beobachten will: OpenTelemetry

Die Stärke der Protokollauswertung: Sie sehen die vergangenen 30 Tage sofort. Wenn Sie dagegen ab jetzt fortlaufend beobachten wollen, passt OpenTelemetry, die offizielle Monitoring-Funktion, besser.

Ist es aktiviert, exportiert Claude Code eine Token-Metrik, claude_code.token.usage (mit den Typen input, output, cacheRead und cacheCreation), und eine Kostenmetrik, claude_code.cost.usage. Beide tragen standardmäßig session.id (OTEL_METRICS_INCLUDE_SESSION_ID, Standardwert true). Da hier keine Protokolldateien gelesen werden, spielen die doppelten Zeilen aus Falle 1 keine Rolle, und der Verbrauch von Subagenten wird über query_source getrennt erfasst (main, subagent, auxiliary).

Um es zunächst lokal auszuprobieren, starten Sie Claude Code wie in der Dokumentation gezeigt mit einem Exporter, der ins Terminal schreibt.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000
claude

Für eine fortlaufende Auswertung setzen Sie OTEL_METRICS_EXPORTER=otlp und senden die Daten an ein Ziel, das Sie selbst betreiben (ein Monitoring-Backend, das OTLP annimmt). Dieses Ziel müssen Sie selbst einrichten, und aus der Zeit vor der Aktivierung wird nichts erfasst: Darin liegen die Unterschiede zur Protokollauswertung.

Quelle: Claude Code Dokumentation, „Monitoring“ (Metriknamen, Attribute, Umgebungsvariablen)

FAQ

F1. Reicht die Tarif-Aufschlüsselung in /usage nicht aus?
Sie misst entlang einer anderen Achse. Die Tarif-Aufschlüsselung zeigt prozentual, in welche Skills, Subagenten, Plugins und MCP-Server der Verbrauch floss, und sie zeigt nicht, welche Sitzung ihn verursacht hat. Wenn Sie von der Funktionsseite her aufspüren wollen, was Ihr Limit aufzehrt, nutzen Sie /usage; von der Sitzungsseite her die Auswertung aus diesem Artikel.

F2. Kann ich ein fertiges Auswertungstool verwenden?
Ja. Das inoffizielle Tool ccusage etwa kann aus denselben Protokollen Berichte pro Sitzung erstellen. Prüfen Sie vor dem Einsatz zwei Dinge. Erstens, ob die gesamte Verarbeitung auf Ihrem Rechner bleibt: Die Protokolle enthalten Tool-Ergebnisse, unverschlüsselt. Zweitens, wie es zählt: Um sicherzugehen, dass es doppelte Zeilen und Subagenten genauso behandelt, vergleichen Sie seine Ausgabe einmal mit dem Skript aus diesem Artikel.

F3. Ich möchte auch den Verbrauch anderer Rechner und von claude.ai einbeziehen.
Protokolle werden nur pro Rechner gespeichert, daher werten Sie auf jedem Rechner einzeln aus und addieren die Ergebnisse. Chats auf claude.ai landen nicht in den Protokollen von Claude Code. Wie viel von Ihrem Tarif insgesamt übrig ist, zeigen verlässlich die Fortschrittsbalken unter Settings > Usage auf claude.ai.

F4. Ich möchte meine Protokolle aufbewahren, um auch älteren Verbrauch auswerten zu können.
Bei im Terminal genutzten Sitzungen erhöhen Sie cleanupPeriodDays in settings.json, dann bleiben sie länger erhalten. Sitzungen, die Sie in der Desktop-App (oder in Cowork) begonnen oder zuletzt fortgesetzt haben, bleiben ab v2.1.248 ohnehin unabhängig vom Alter erhalten (für eine Frist nutzen Sie desktopSessionCleanupPeriodDays). Beachten Sie aber, dass die Dokumentation das Senken dieser Werte als Weg nennt, Ihre Protokolle weniger angreifbar zu machen. Je länger Sie sie aufbewahren, desto länger liegen unverschlüsselte Aufzeichnungen auf Ihrem Rechner; behalten Sie das im Hinterkopf.

Quellen

• Claude Code Docs — Manage costs effectively (Bereich „Session“ und Tarif-Aufschlüsselung in /usage, der Hinweis, dass die Werte aus dem Verlauf dieses Rechners berechnet werden, /insights, Dashboards für Organisationen, warum der Verbrauch in langen Sitzungen wächst)
• Claude Code Docs — Explore the .claude directory (Speicherort der Protokolle, subagents/, Standardwert von 30 Tagen für cleanupPeriodDays und Umgang mit Sitzungen der Desktop-App, fehlende Verschlüsselung)
• Claude Code Docs — Desktop (Verbrauchsring)
• Claude Help Center — Usage limit best practices (was Settings > Usage anzeigt)
• Claude Code Docs — Monitoring (Metriknamen von OpenTelemetry, session.id, Umgebungsvariablen)
• Claude Platform Docs — Pricing (Preise pro Modell, Cache-Faktoren)

Verwandte Artikel

• Claude Code: Was frisst eigentlich Ihren Kontext? — warum jede Antwort schwer wird
• Claude Code „usage limit reached“: Limits verstehen und weiterarbeiten — wenn Sie das Limit erreicht haben
• Claude Code Token-Spar-Tipps und die Zusatzkosten am Limit — was Sie zuerst kürzen
• Das Wochenlimit von Claude Code und die frühe Erholung — wie das Wochenlimit funktioniert