Claude-Code-Spend-Tracker im Vergleich

Was ein Claude-Code-Spend-Tracker tatsächlich liest

Jeder Claude-Code-Spend-Tracker liest eine von drei Datenquellen. Die Quelle bestimmt, welche Frage er beantworten kann. Ein Log-Parser liest die Sitzungsprotokolldateien auf Ihrem eigenen Datenträger. Ein Dashboard liest die Nutzungsdatensätze, die Anthropic für Ihr Konto oder Ihre Organisation speichert. Ein Metrik-Backend liest den OpenTelemetry-(OTel-)Datenstrom, den Claude Code ausgibt, sobald Sie ihn aktivieren. Alle drei können gleichzeitig korrekt sein und trotzdem unterschiedliche Ergebnisse liefern, weil sie verschiedene Dinge zählen.

In diesem Leitfaden werden Tokens nicht erneut erklärt. wie Claude Code die Token-Nutzung zählt behandelt Eingabe, Ausgabe, Cache-Schreibvorgänge und Cache-Lesevorgänge. Kein Dashboard ist aussagekräftig, solange dieser Teil nicht geklärt ist. Die Frage hier ist enger gefasst: Was kann jede Art von Tool sehen, und was kann sie niemals sehen?

Warum an einem Tag drei Ausgaben-Tracker für Claude Code erschienen

Am selben Tag wurden drei separate Ausgaben-Tracker für Claude Code veröffentlicht. Es handelte sich nicht um drei Versionen desselben Tools. Genau das ist der wichtige Punkt. Einer analysierte die lokalen Sitzungsdateien. Einer kapselte die Bildschirme zur Kontonutzung. Einer war ein gehostetes Tracing-Backend, das Sie selbst betreiben.

Sie erschienen gemeinsam, weil die Kosten einer Agent-Sitzung nicht mehr offensichtlich waren. Bei einem Chat entsprechen die Kosten ungefähr dem, was Sie auf dem Bildschirm sehen. Ein Agent liest zwanzig Dateien, führt die Testsuite aus und sendet bei jeder Runde die gesamte Unterhaltung erneut. Dadurch werden die Kosten durch Kontext bestimmt, den Sie nie eingegeben haben. Bei einem Abonnement gibt es überhaupt keinen Dollarbetrag. Stattdessen sehen Sie nur einen Nutzungsbalken, der sich an manchen Tagen schneller leert als an anderen. Jedes der drei Tools schließt eine andere Lücke.

Form 1: Ein lokaler Log-Parser zeigt, was heute gekostet hat

Claude Code speichert jede Unterhaltung als JSON Lines (JSONL) unter ~/.claude/projects/<project>/<session-id>.jsonl. Dabei ist <project> Ihr Pfad zum Arbeitsverzeichnis, in dem nicht alphanumerische Zeichen durch - ersetzt wurden. Jeder Antwortschritt des Assistenten in dieser Datei enthält die Tokenanzahl für seine Anfrage. Ein Log-Parser addiert diese Werte und berechnet daraus die Kosten.

ccusage ist die naheliegendste Wahl. Es muss nichts installiert werden:

npx ccusage@latest daily
npx ccusage@latest daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session --json

daily summiert nach Datum. --breakdown teilt jede Zeile nach Modell auf. So sehen Sie, ob ein Nachmittag mit Opus den größten Teil der Woche ausmacht. blocks gruppiert nach dem Fünfstundenfenster, in dem ein Abonnement zurückgesetzt wird. session summiert pro Unterhaltung, und --instances gruppiert nach Projekt. So sehen Sie, welches Repository teuer ist. Mit --since und --until begrenzen Sie den Zeitraum. Führen Sie npx ccusage@latest daily --help aus, um das von Ihrer Version erwartete Datumsformat anzuzeigen. Seit August 2026 liest das Tool auch andere Agent-CLIs ein, darunter Codex und OpenCode. Das ist beim Vergleich dieser Tools relevant.

Die Preise stammen aus einer Modellpreistabelle. Das Tool unterstützt drei Kostenmodi. --mode auto verwendet den Wert costUSD, den Claude Code in die Datei geschrieben hat, sofern dieser vorhanden ist. Andernfalls berechnet es die Kosten aus den Tokenanzahlen. --mode calculate berechnet die Kosten immer aus den Tokenanzahlen und ignoriert aufgezeichnete Kosten. --mode display zeigt nur aufgezeichnete Kosten an und gibt $0.00 für Zeilen ohne solche Kosten aus. Wenn eine Summe falsch aussieht, führen Sie denselben Bericht zuerst mit calculate und anschließend mit display aus. Eine große Abweichung bedeutet, dass die meisten Einträge keine aufgezeichneten Kosten enthalten. Alle angezeigten Werte sind dann Schätzungen.

Dieselben Daten können Ihren Prompt versorgen. ccusage statusline gibt eine kompakte Zeile für die Claude-Code-Statusleiste aus. Sie binden sie wie jeden anderen Befehl für eine Statuszeile in ~/.claude/settings.json ein. Unter Claude-Code-Statuszeile erstellen finden Sie den Einstellungsblock und die Felder, die der Befehl erhält.

Ein Log-Parser kann nichts erkennen, was nicht auf diesem Rechner passiert ist. Ein zweiter Laptop, eine Sitzung auf claude.ai oder die Arbeit eines Teammitglieds: Diese Transkripte liegen auf den jeweiligen Datenträgern. Auch ältere Daten fehlen, weil Transkripte unter der Einstellung cleanupPeriodDays standardmäßig nach 30 Tagen bereinigt werden. Das letzte Quartal ist daher nicht mehr verfügbar, sofern Sie es nicht archiviert haben.

Es gibt noch ein weiteres, strukturelles Risiko. Die Dokumentation von Anthropic weist darauf hin, dass das Eintragsformat intern für Claude Code ist und sich zwischen Versionen ändern kann. Skripte, die diese Dateien direkt parsen, können daher mit jedem Release ausfallen. Das gilt für jedes Tool dieser Art. Deshalb ist auch ein selbst erstellter jq-Einzeiler über die JSONL-Datei riskanter, als er zunächst wirkt: Gepflegte Parser berücksichtigen Formatänderungen für Sie. Ihr Einzeiler meldet dagegen an dem Tag eine scheinbar genaue, aber falsche Zahl, an dem ein Feld umbenannt wird.

Für den Dollarbetrag bei einem Abonnement ist schließlich ein Hinweis erforderlich. Bei Pro oder Max werden Sie nicht pro Token abgerechnet. Der Betrag zeigt daher, was Ihre Token zu den regulären API-Listenpreisen gekostet hätten. Er misst den Umfang Ihrer Nutzung. Er ist nicht Ihre Rechnung. Wenn Sie eigentlich wissen möchten, welcher Tarif geeignet ist, müssen Sie das separat vergleichen: siehe API-Abrechnung im Vergleich zu einem Claude-Abonnement.

Form 2: Die integrierten Nutzungsansichten zeigen, welches Modell das Budget verbraucht hat

Claude Code enthält eigene Berichte, die die meisten Benutzer nie öffnen. Führen Sie /usage innerhalb einer Sitzung aus. Der Block „Session“ oben zeigt die Token nach Modell sowie einen Dollarbetrag für die aktuelle Sitzung. Dieser wird lokal anhand der Tokenanzahl und der regulären Listenpreise berechnet. Der Betrag berücksichtigt keine Rabatte oder Aktionspreise und kann daher von Ihrer Rechnung abweichen. Die Summen werden zurückgesetzt, wenn /clear eine neue Unterhaltung startet.

Bei einem Pro-, Max-, Team- oder Enterprise-Tarif zeigt dieselbe Ansicht außerdem, wie viel Ihres Tariflimits Sie verwendet haben. Die aktuelle Nutzung wird dabei den Skills, Subagenten, Plugins und einzelnen MCP-Servern als Prozentsatz der Gesamtnutzung zugeordnet. Die Ansicht markiert Verhaltensweisen, die mindestens 10% der aktuellen Nutzung ausmachen, etwa einen langen Kontext oder Cache-Fehlzugriffe. Drücken Sie d oder w, um zwischen den letzten 24 Stunden und den letzten 7 Tagen zu wechseln. Diese Werte sind Näherungen und werden aus dem lokalen Sitzungsverlauf auf diesem Rechner berechnet. Ein zweites Gerät wird daher nicht berücksichtigt.

Sobald mehr als ein Entwickler beteiligt ist, beziehen sich die Zahlen auf das Konto. Eine API-Organisation erhält die Nutzungsseite der Console, ein Claude-Code-Dashboard mit Ausgaben und akzeptierten Zeilen pro Mitglied sowie eine Claude Code Analytics API, die mit einem Administratorschlüssel dieselben täglichen Metriken pro Benutzer liefert. Team- und Enterprise-Tarife erhalten in der Administrationskonsole einen Ausgabenbericht mit CSV-Export, der täglich aktualisiert wird. Enterprise bietet zusätzlich eine Analytics API. Welche dieser Ansichten Sie sehen, hängt davon ab, wie sich die einzelnen Entwickler angemeldet haben. In einer gemischten Organisation müssen Sie daher zwei Berichte auswerten und die Werte manuell addieren.

Für die Budgetplanung liegt der veröffentlichte Wert in der Kostendokumentation von Anthropic im August 2026 bei durchschnittlich etwa $13 pro Entwickler und aktivem Tag sowie $150 bis $250 pro Entwickler und Monat. 90% der Benutzer bleiben unter $30 pro aktivem Tag. Betrachten Sie dies als veröffentlichten Vergleichswert aus Enterprise-Bereitstellungen, nicht als Prognose für Ihr Team. Führen Sie zunächst mit einer Pilotgruppe einen Test durch und messen Sie die Werte, bevor Sie sie hochrechnen.

Die Dashboards können nichts erkennen, was unterhalb der Ebene eines Tages und einer Person liegt. Sie zeigen Ihnen, dass Opus am Dienstag den größten Anteil hatte. Sie zeigen jedoch nicht, welcher Prompt, welches Repository oder welcher CI-Job dafür verantwortlich war. Außerdem sind die Daten verzögert, da die Organisationsberichte täglich aktualisiert werden. Sie eignen sich daher zur Auswertung, nicht zum Erkennen eines außer Kontrolle geratenen Agents am selben Nachmittag. Dafür benötigen Sie Limits und keine Berichte. Dieses Thema behandelt Agentenkosten auf einem VPS begrenzen.

Form 3: Ihr eigener OpenTelemetry-Stack zeigt, welcher Prompt eine Regression verursacht hat

Claude Code erzeugt OpenTelemetry-Metriken und Ereignisse, sobald Sie eine Umgebungsvariable setzen. Dies ist die einzige Option, die Token- und Kostendaten pro Benutzer nahezu in Echtzeit in ein von Ihnen kontrolliertes System streamt. Die Metriken enthalten claude_code.cost.usage in USD, claude_code.token.usage in Tokens, claude_code.session.count und claude_code.active_time.total.

Die Token-Metrik ist wegen ihrer Attribute besonders interessant. Jeder Datenpunkt enthält type. Dieser Wert ist input, output, cacheRead oder cacheCreation. Außerdem enthält er model und query_source. Dabei handelt es sich um main, subagent oder auxiliary. Zusätzlich werden agent.name, skill.name, mcp_server.name und mcp_tool.name erfasst. Damit lassen sich Fragen beantworten, die kein Dashboard abdeckt: Wie hoch ist der Anteil der Subagents an der Rechnung im Vergleich zu Ihren eigenen Eingaben? Hat ein MCP-Server die Anzahl Ihrer Eingabe-Tokens verdoppelt? Sind die Cache-Lesevorgänge gesunken, nachdem jemand CLAUDE.md bearbeitet hat? Das Cache-Verhalten ist meist die Ursache für unerwartete Ergebnisse. Wann sich Prompt-Caching amortisiert erklärt, welche Daten Sie dabei betrachten.

Eine Korrektur ist an dieser Stelle wichtig, weil sie in jedem Thread zu diesem Thema aufkommt. Langfuse ist ein gutes selbst gehostetes Tracing-Backend. Der Betrieb auf einem VPS wird unter Langfuse für Agent-Tracing selbst hosten beschrieben. Sein OTLP-Endpunkt akzeptiert jedoch ausschließlich Traces. Claude Code exportiert Metriken und Log-Ereignisse, aber keine Spans. Wenn Sie OTEL_EXPORTER_OTLP_ENDPOINT auf Langfuse verweisen, bleibt das Projekt leer, und Sie erhalten keine verwertbare Fehlermeldung. Langfuse ist das richtige Tool für Agents, die Sie selbst über die API erstellen und bei denen Ihr eigener Code jeden Span mit Prompt, Modell und Kosten erzeugt. Für die Claude-Code-CLI ist ein Metrikenspeicher die passende Lösung.

Claude-Code-Ausgaben auf dem eigenen VPS überwachen

Zwei Dienste reichen aus: ein Collector zum Empfangen der Metriken und Prometheus zum Speichern. Halten Sie beide vom öffentlichen Internet fern, weil ein offener OTLP-Port Schreibzugriffe von jedem zulässt, der ihn findet. Schreiben Sie /opt/ccmetrics/compose.yaml:

services:
  collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel/config.yaml"]
    volumes:
      - ./collector.yaml:/etc/otel/config.yaml:ro
    ports:
      - "10.8.0.1:4318:4318"
    restart: unless-stopped
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

volumes:
  prom-data:

10.8.0.1 ist die Adresse des Servers innerhalb eines WireGuard-Tunnels. Dadurch ist der Collector von Ihren Maschinen aus erreichbar, aber von nirgendwo sonst. Die Adresse vor dem Port ist hier entscheidend, weil veröffentlichte Docker-Ports nicht von ufw gefiltert werden: siehe warum veröffentlichte Docker-Ports ufw umgehen. Die Einrichtung des Tunnels selbst wird unter ein eigenes WireGuard-VPN auf dem eigenen VPS beschrieben.

/opt/ccmetrics/collector.yaml:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

/opt/ccmetrics/prometheus.yml. Port 8889 wird niemals am Host veröffentlicht, weil Prometheus den Collector über das Compose-Netzwerk anhand des Servicenamens erreicht:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: claude-code
    static_configs:
      - targets: ["collector:8889"]

cd /opt/ccmetrics
docker compose up -d
docker compose logs collector

Der Collector-Log sollte mit Everything is ready. Begin running and processing data. enden. Ein Log, das wegen eines Konfigurationsfehlers endet, bedeutet, dass das YAML nicht geparst werden konnte. Der Container wird dann fortlaufend neu gestartet.

Konfigurieren Sie nun Claude Code. Fügen Sie auf jeder Maschine, auf der Claude Code ausgeführt wird, Folgendes zu ~/.claude/settings.json hinzu:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://10.8.0.1:4318",
    "OTEL_METRIC_EXPORT_INTERVAL": "10000"
  }
}

Starten Sie eine Sitzung, senden Sie einen Prompt und warten Sie das Exportintervall ab (hier 10 Sekunden, standardmäßig 60 Sekunden). Fragen Sie anschließend Prometheus ab:

curl -s http://localhost:9090/api/v1/label/__name__/values | grep -o 'claude_code[a-z_]*'

Sie sollten mehrere Namen erhalten, die mit claude_code_ beginnen. Der Exporter ersetzt die Punkte durch Unterstriche und hängt die Einheit an. Die genauen Zeichenfolgen hängen daher von Ihrer Collector-Version ab. Ein leeres Ergebnis bedeutet, dass keine Daten eingegangen sind. Prüfen Sie, ob Protokoll und Port übereinstimmen: http/protobuf verwendet Port 4318, grpc dagegen Port 4317. Eine Abweichung schlägt ohne deutliche Fehlermeldung fehl. Führen Sie claude --debug aus. Das Debug-Log meldet dann OTel-Exportfehler.

Für eine einzelne Maschine ohne Server können Sie alles oben Genannte überspringen. Setzen Sie OTEL_METRICS_EXPORTER=prometheus. Claude Code stellt dann selbst unter http://localhost:9464/metrics einen Scrape-Endpunkt bereit. Wenn prometheus der einzige aufgeführte Exporter ist, lässt Claude Code die Einheiten USD, tokens und s aus den Metriknamen weg. Dadurch bleibt das Scrape-Ergebnis im gültigen Prometheus-Textformat.

Diese Konfiguration bringt eine Datenschutzentscheidung mit sich. Standardmäßig verlassen nur Zähler die Maschine. Prompt-Text und Tool-Ausgaben werden nicht übertragen. OTEL_LOG_USER_PROMPTS=1 und OTEL_LOG_TOOL_CONTENT=1 ändern dieses Verhalten. Dann enthält Ihr Metrikserver Quellcode und alle anderen Inhalte, die sich im Kontext befunden haben. Aktivieren Sie diese Optionen nur bewusst und lesen Sie zuerst Secrets aus dem Agent-Kontext heraushalten.

Kosten für Skript- und CI-Läufe erfassen

Nicht interaktive Läufe überraschen häufig, weil niemand den Bildschirm beobachtet. claude -p mit --output-format json meldet die Kosten dieses Laufs in seiner Ergebnisnutzlast:

claude -p "summarise the failing tests" --output-format json | jq '.total_cost_usd'

Die Nutzlast enthält total_cost_usd sowie eine Aufschlüsselung nach Modell. Dadurch kann ein CI-Job seine eigenen Kosten ohne Dashboard erfassen. Hängen Sie den Wert an eine Datei an oder übertragen Sie ihn als Metrik an den oben genannten Collector. Dies ist die kostengünstigste sinnvolle Möglichkeit zur Kostenerfassung und erfordert pro Lauf einen jq-Aufruf.

Fehlerbilder und ihre sichtbaren Auswirkungen

Der Bericht ist leer. npx ccusage@latest daily gibt keine Zeilen aus. Das bedeutet, dass der Bericht nicht an der Stelle liest, an der Claude Code schreibt. CLAUDE_CONFIG_DIR ändert diesen Speicherort. Der Parser muss darüber informiert werden. Wenn Zeilen vorhanden sind, aber etwa einen Monat zurückreichen, funktioniert cleanupPeriodDays wie vorgesehen: Transkripte werden standardmäßig nach 30 Tagen gelöscht.

Zwei Computer melden unterschiedliche Summen. Das ist zu erwarten und kein Fehler. Sowohl /usage als auch jeder Log-Parser lesen nur den lokalen Sitzungsverlauf. Die Nutzung von einem anderen Gerät oder über claude.ai fehlt daher in beiden Auswertungen.

Die lokale Summe stimmt nicht mit der Rechnung überein. Die lokalen Werte werden anhand der Token-Anzahl und der regulären Listenpreise berechnet. Aktionspreise oder vertraglich vereinbarte Rabatte werden dabei nicht berücksichtigt. Bei einem Abonnement werden Ihre Token überhaupt nicht einzeln abgerechnet. Für die API-Abrechnung ist die Nutzungsseite der Console maßgeblich.

Die Kosten sind gestiegen, obwohl Sie dieselbe Arbeit ausgeführt haben. Prüfen Sie zuerst die Cache-Spalten. Eine lange Sitzung sendet ihren gesamten Verlauf bei jeder Eingabe erneut. Solange der Cache aktiv ist, gilt der Cache-Preis. Nach Ablauf des Caches gilt wieder der vollständige Eingabepreis. Eine längere Unterbrechung verarbeitet daher die gesamte Unterhaltung erneut. Das zeigt sich als große Eingabezahl neben einer kleinen Ausgabezahl. Die Tokenpreise für Eingaben und Ausgaben erklären, warum sich beide Werte unabhängig voneinander ändern.

Ein Tag mit Subagents erscheint unmöglich. Jeder Subagent verwendet ein eigenes Kontextfenster. Der Tokenverbrauch steigt daher mit der Anzahl der gestarteten Subagents und mit ihrer jeweiligen Laufzeit. Nur die OTel-Daten können sie getrennt ausweisen, und zwar über das Attribut query_source auf claude_code.token.usage. Ein Log-Parser zeigt lediglich die Gesamtsumme an. Die einzelnen Anteile müssen Sie daraus ableiten.

FAQ

Zeigt ccusage, was mir in einem Max-Tarif tatsächlich berechnet wird?

Nein. Bei einem Abonnement werden Ihnen keine einzelnen Tokens berechnet. Ein Log-Parser bewertet Ihre Tokens deshalb zu den regulären Listenpreisen der API und zeigt, was dieselbe Arbeit über die API gekostet hätte. Das ist ein guter relativer Maßstab dafür, wie umfangreich ein Tag war. Außerdem lassen sich damit Projekte oder Modelle miteinander vergleichen. Für den tatsächlich fälligen Betrag ist die Nutzungsseite der Console für die API-Abrechnung zuständig. Bei einem Abonnement gilt dafür die Abrechnungsseite des Tarifs.

Wo speichert Claude Code die Sitzungsdateien, die diese Tools lesen?

In ~/.claude/projects/<project>/<session-id>.jsonl. Dabei ist <project> der Pfad des Arbeitsverzeichnisses, in dem nicht alphanumerische Zeichen durch - ersetzt werden. Jede Zeile ist ein JSON-Objekt für eine Nachricht, eine Tool-Nutzung oder einen Metadateneintrag. CLAUDE_CONFIG_DIR verschiebt das gesamte Verzeichnis. cleanupPeriodDays in settings.json steuert die Aufbewahrung über 30 Tage. Anthropic dokumentiert das Format der Einträge als intern und weist darauf hin, dass es sich zwischen Versionen ändern kann. Verwenden Sie daher zum Parsen ein gepflegtes Tool statt eines eigenen Skripts.

Kann ich Telemetriedaten von Claude Code an Langfuse senden?

Nicht direkt. Der Langfuse-OTLP-Endpunkt akzeptiert Traces. Claude Code exportiert jedoch Metriken und Log-Ereignisse statt Spans. Daher können die Daten dort nicht gespeichert werden. Senden Sie die Metriken von Claude Code an einen OpenTelemetry Collector und speichern Sie sie in Prometheus. Verwenden Sie Langfuse für Agents, die Sie selbst auf der API erstellen. Dort kann Ihr eigener Code Spans mit Prompt, Modell und Kosten ausgeben.

Warum stimmen meine lokalen Zahlen nicht mit der Nutzungsseite der Console überein?

Weil sie unterschiedlich berechnet werden. /usage und Log-Parser addieren die Tokenanzahl aus den Sitzungsdateien auf dem verwendeten Rechner und bewerten sie anschließend zu den regulären Listenpreisen. Die Console zeigt, was Ihrer Organisation tatsächlich berechnet wurde. Dabei werden alle Rechner und alle Keys berücksichtigt, einschließlich etwaiger Rabatte. Eine Abweichung ist normal. Eine sehr große Abweichung weist meist auf ein zweites Gerät, einen CI-Runner oder ein weiteres Teammitglied hin, das über dasselbe Konto abrechnet.

Wie erfasse ich die Kosten eines claude -p-Laufs in CI?

Führen Sie ihn mit --output-format json aus und lesen Sie total_cost_usd aus dem Ergebnis aus, beispielsweise mit claude -p "..." --output-format json | jq '.total_cost_usd'. Die gleiche Nutzlast enthält eine Aufschlüsselung nach Modell und die Sitzungs-ID. Speichern Sie diesen Wert für jeden Job. Damit erhalten Sie die Ausgaben pro Pipeline ohne Agent, Dashboard oder zusätzlichen Dienst.