Token-Verbrauch in
Claude Code verstehen

Erste Schritte#

Installieren. In Obsidian: Einstellungen → Community-Plugins → Durchsuchen → nach „Token Usage" suchen → Installieren → Aktivieren. Das ist die ganze Einrichtung: kein Konto, kein API-Key, kein externer Dienst. Es funktioniert unter Windows, macOS und Linux gleich, das eine plattformspezifische Detail (wo der Agent-Modus der Claude-Desktop-App seine Sessions ablegt) steht unter Datenquellen & Transparenz.

Öffnen. Klick auf das Diagramm-Symbol in der linken Leiste oder führe „Open Token Usage" aus der Befehlspalette aus (Strg/Cmd+P). Beides öffnet die Ansicht in der rechten Seitenleiste, wo sie wie jeder andere Obsidian-Bereich bleibt.

Für brauchbare Zahlen musst du nichts einstellen. Die Seitenleiste funktioniert sofort: links eine Symbolleiste mit vier Seiten, Übersicht, Kalender, Auswertung und Einstellungen, siehe unten. Seit 2.0 gibt es nur diese eine Darstellung, die alte „Classic"-Ansicht und der Schalter dafür sind entfallen.

Befehle ab dem ersten Tag (Befehlspalette, die Befehlsnamen sind englisch):

Datenquellen & Transparenz#

Dieses Plugin braucht direkten Zugriff auf das Dateisystem, sonst funktioniert es nicht. Die Prüfung der Obsidian-Community-Plugins meldet das als erwarteten Hinweis, nicht als Mangel, denn lokale Session-Dateien zu lesen ist genau der Zweck. Statt dich blind vertrauen zu lassen, steht hier genau, wo diese Dateien liegen, welche Felder das Plugin liest und was es nie anfasst. Jede Aussage lässt sich direkt im Quellcode prüfen: main.js ist nicht minifiziert und öffentlich auf GitHub.

Wo die JSONL-Dateien wirklich liegen. Claude Code schreibt, egal ob im Terminal, in einem Editor wie VS Code oder in Obsidian, eine JSONL-Datei pro Session unter ~/.claude/projects/<workspace-id>/<session-id>.jsonl, ein Unterordner je Arbeitsverzeichnis. Das ist unter Windows (C:\Users\<du>\.claude\projects\...), macOS (/Users/<du>/.claude/projects/...) und Linux (/home/<du>/.claude/projects/...) gleich. Das Plugin findet den Ordner über Nodes os.homedir(), das auf jeder Plattform gleich arbeitet. Eine weitere Datei ist beteiligt, nur lesend, solange du die Aufbewahrung nicht im Plugin änderst: Claude Codes eigene ~/.claude/settings.json, aus der nur der Wert cleanupPeriodDays gelesen wird. Änderst du ihn in den Plugin-Einstellungen, wird vorher automatisch eine Sicherung .bak der ganzen Datei geschrieben. Und nur wenn du den optionalen Feed einrichtest: ~/.claude/ratelimit-log.jsonl, nur lesend, die offiziellen Prozentwerte mit ihren Reset-Zeiten.

Agent-Modus der Claude-Desktop-App: nach heutigem Stand eine reine Windows-Ausnahme. Die Windows-Version der Desktop-App führt ihr eingebettetes Claude Code in einer MSIX-App-Container-Sandbox aus, die das Dateisystem virtualisiert. Sessions aus dem Agent-Modus landen dort deshalb an einem anderen Ort: %APPDATA%\Claude\local-agent-mode-sessions\..., bei der Version aus dem Microsoft Store im Sandbox-Pfad %LOCALAPPDATA%\Packages\<package-id>\LocalCache\Roaming\Claude\local-agent-mode-sessions\.... Das Plugin durchsucht diesen zweiten Ort seit v1.8.0 automatisch, nur unter Windows. macOS und Linux haben keine vergleichbare Sandbox-Schicht, und laut verfügbarer Dokumentation schreibt Claude Code dort in allen Formen, ob Kommandozeile, Editor-Integration oder Desktop-App, in dasselbe ~/.claude/projects/. Sessions aus dem Agent-Modus landen dort also, wo es ihn gibt, voraussichtlich schon im Standardordner, den das Plugin liest. Das ist der beste aktuelle Beleg, keine Primärquelle von Anthropic. Nutzt du den Agent-Modus unter macOS oder Linux und fehlt Verbrauch, eröffne bitte ein Issue auf GitHub.

Das Einzige, was keine Zahl ist. Claude Code schreibt selbst einen kurzen, automatisch erzeugten Titel für jede Session in dieselbe JSONL-Datei (einen Eintrag ai-title). Die Tabelle Top Sessions im Dashboard liest genau diesen kurzen Text und zeigt ihn statt einer nackten Session-UUID, damit die Liste lesbar ist. Es ist das einzige Feld, das aus Gesprächsinhalt abgeleitet ist statt aus reinen Verbrauchszahlen, und es ist Claude Codes eigene Zusammenfassung, nichts, was das Plugin erzeugt oder erweitert.

Was deinen Rechner verlässt: nichts. Keine Netzwerkanfragen, keine Telemetrie, kein externer Server, jede Zahl wird lokal berechnet. Das Plugin schreibt genau zwei Arten neuer Dateien, beide in deinem eigenen Vault, beide nur mit Summen: das tägliche Archiv unter Token Usage Archive/ (siehe Archiv & Langzeit-Daten) und, nur wenn du es auslöst, den Markdown-Report, das HTML-Dashboard, den Vault-Projekt-Export und die CSV-Exporte. Keine davon enthält je einen Prompt oder eine Antwort.

Wenn du den Browser selbst prüfen willst. Die Entwicklerwerkzeuge deines Browsers (F12 → Netzwerk, gefiltert auf XHR/Fetch) zeigen jede Anfrage, während du claude.ai nutzt. Zwei ehrliche Einschränkungen: Das Plugin nimmt dir das nicht ab, es hat keine Browser-Anbindung, keine Erweiterung, keinen Proxy, und das ist eine bewusste Grenze. Und der Web-Client von claude.ai spricht mit internen, nicht dokumentierten Schnittstellen von Anthropic, nicht mit der öffentlichen Claude-API, die Claude Code nutzt. Token-ähnliche Zahlen dort sind interne Details, die sich ohne Ankündigung ändern können. Das usage-Objekt der öffentlichen API, das Claude Code in deine lokalen JSONL-Dateien schreibt und das dieses Plugin liest, bleibt die einzige stabile, dokumentierte Quelle für genaue Token-Zahlen.

Limits: Prozente nur von Anthropic#

Prozente kommen nur noch von Anthropic. Bis 2.1 hat Token Usage für das 5h-Fenster und die Woche einen Prozentwert geschätzt, aus deinen eigenen Limit-Treffern oder hochgerechnet aus dem Feed. Wir haben diese Schätzung elf Tage lang gegen die offiziellen Werte gelegt. Beim 5h-Fenster lag sie im Schnitt 36 Punkte daneben, und in dem Moment, in dem ein Fenster offiziell voll war, stand unser Ring irgendwo zwischen 61 und 217 Prozent (eigene Messung, 37 Ablesungen, 06. bis 17.10.2026). Wie schnell ein Fenster voll ist, hängt stark davon ab, wie viel Kontext eine Sitzung mitschleppt, und das lässt sich aus den lokalen Logs nicht verlässlich ablesen. Die Ringe haben damit eine Genauigkeit vorgegeben, die sie nie hatten. Das war unsere Entscheidung, und sie war falsch.

Ab 2.5 gilt eine einfache Regel: Einen Prozentwert für ein Limit zeigen wir nur, wenn er von Anthropic kommt, zusammen mit der Uhrzeit, zu der er abgelesen wurde. Dafür brauchst du den Feed (siehe Offizielle Prozentwerte von Anthropic). Bei der Woche machen wir eine Ausnahme: Zwischen zwei Ablesungen rechnen wir vom letzten offiziellen Wert mit deinen gezählten Tokens weiter und kennzeichnen das auch so, weil sich das Wochenlimit in derselben Messung als stabil erwiesen hat (im Mittel 1,2 Punkte Abweichung). Ohne Feed siehst du, was wir sicher wissen: deine Tokens im laufenden Fenster und in der Woche, die Zeit bis zum Reset und die Spanne, in der dein 5h-Fenster bisher voll war. Der Heute-Ring zeigt kein Prozent mehr, sondern das Vielfache deines üblichen Tages. Alles andere im Plugin wird gezählt und bleibt, wie es ist.

Warum die Tokens unter einem Ring nicht zu seinem Prozentwert passen. Das Plugin zählt Input und Output. Den Kontext, den eine Sitzung bei jeder Anfrage mitschickt, rechnet Anthropic mit, deshalb passen Prozent und Tokens nicht direkt zusammen. Eine lange Sitzung mit großem Kontext kann ein Fenster mit vergleichsweise wenigen gezählten Tokens füllen. Maßgeblich ist der Prozentwert.

Was bleibt: die Spanne deiner Limit-Treffer. Unter den Ringen nennt das Plugin die niedrigste und die höchste Token-Zahl, bei der dein 5h-Fenster bisher voll war, zum Beispiel „Bei dir war das 5h-Fenster bisher nach 51 K bis 316 K voll (102 Limit-Treffer)". Gezählt werden Input und Output vom Start des Fensters bis zum jeweiligen Treffer. Das ist weder ein Limit noch eine Prognose, es zeigt, wie groß die Bandbreite wirklich ist. Mit Feed kommt der Fensterstart von Anthropic. Ohne Feed wird er aus deinen Logs rekonstruiert und kann einige Minuten abweichen, wenn claude.ai oder ein anderes Gerät das Fenster geöffnet hat. Ohne Feed steht unter den Ringen außerdem eine kurze Zeile mit einem Link direkt zur Einrichtung.

Bis 2.1 hieß dieser Abschnitt „Empirische Limit-Schätzung" und versprach, dass die Schätzung mit jedem Limit-Treffer präziser wird. Die Messung oben hat gezeigt, dass das nicht stimmte.

Was ist ein Token?#

Ein Token ist ein kleines Textstück, ungefähr drei Viertel eines englischen Wortes, im Deutschen wegen der längeren Wörter oft etwas weniger. Es ist weder genau ein Wort noch genau ein Zeichen. Der Satz „Guten Morgen, wie geht es dir heute?" ergibt etwa 8 Tokens. Längere oder ungewöhnliche Wörter kosten mehr, kurze häufige Wörter teilen sich manchmal einen Token. Dein Input und Claudes Antwort werden getrennt gezählt.

Input und Output#

Input ist alles, was Claude in einer Anfrage empfängt: deine Nachricht, die Systemanweisung, Dateiinhalte, Tool-Ergebnisse und den Gesprächsverlauf, der bei jeder neuen Nachricht erneut mitgeschickt wird.

Output ist das, was Claude zurückschreibt. Output-Tokens sind bei allen Modellen deutlich teurer als Input-Tokens, typischerweise um das 3- bis 5-fache.

Eine einzelne Frage ist günstig. Die Kosten entstehen durch Volumen, Kontextgröße und Wiederholung, nicht durch die Komplexität dessen, was du fragst.

C.Write — Cache-Schreiben#

Wenn Claude Code einen großen, wiederkehrenden Textblock sendet (Projektdateien, eine lange Systemanweisung, eine komplette Codebasis), kann die Infrastruktur von Anthropic ihn zwischenspeichern. Beim ersten Mal, dass dieser Block verarbeitet wird, wird er in den Cache geschrieben. Das ist ein Cache Write.

Es gibt zwei Arten von Cache Writes mit unterschiedlichem Preis: Ein 5-Minuten-Cache-Write kostet das 1,25-fache des Standard-Input-Preises, ein 1-Stunden-Cache-Write das 2-fache. In unseren eigenen Logs waren rund 90 % der Cache Writes von Claude Code im Abo die 1-Stunden-Art, Subagenten schrieben 5-Minuten-Caches. Seit 2.1.0 zeigt die C.Write-Zeile in der Seitenleiste die Aufteilung, wenn du mit der Maus darüberfährst. Es ist eine Investition: Du zahlst mehr im Voraus, damit nachfolgende Anfragen denselben Inhalt nicht erneut verarbeiten müssen. Cache Writes zählen außerdem auf das 5-Stunden-Limit, siehe Was auf ein Limit einzahlt.

Das Plugin zeigt C.Write in Aqua in der gesamten Seitenleiste.

C.Read — Cache-Lesen#

Sobald ein Block gecacht ist, kann Claude ihn bei nachfolgenden Anfragen aus dem Cache lesen, statt ihn von Grund auf neu zu verarbeiten. Das ist ein Cache Read.

Cache Reads kosten nur einen Bruchteil des Standard-Input-Preises: das 0,1-fache bei den meisten Modellen, das 0,05-fache bei Opus 5.5 und Sonnet 5.5, das 0,025-fache bei Fable 5.1. Wird derselbe Kontext viele Male genutzt, machen Cache Reads große Sessions deutlich günstiger, als sie sonst wären.

Das Plugin zeigt C.Read in Violett, als Zeichen für hohes Volumen bei niedrigen Kosten pro Token.

C.Write vs. C.Read — der Wiederverwendungsfaktor und was er über deine Arbeitsweise sagt#

Das Verhältnis dieser beiden Werte ist mehr als ein Kostendetail. Es zeigt direkt und ehrlich, ob ein Arbeitsabschnitt fokussiert oder zerstreut war.

Hohe Wiederverwendung heißt, du bist mit Rückfragen beim selben Kontext geblieben, statt ständig neu anzufangen. Niedrige Wiederverwendung heißt nahezu ständiger Kontextwechsel. Beides ist nicht „falsch", Erkunden hat seinen Platz. Aber wenn du tief und ausdauernd arbeiten wolltest und der Faktor etwas anderes sagt, lohnt ein Blick. Das Dashboard zeigt den Wert im Abschnitt Cache-Effizienz, mit einem Liniendiagramm in Aqua für C.Write und Violett für C.Read, passend zu den Farben der Seitenleiste.

Focus Score, ein zweites, unabhängiges Signal. Der Focus Score im Dashboard (0 bis 100) verbindet drei Dinge, die das Plugin ohnehin sieht: Cache-Wiederverwendung (die Stufen oben, 50 % der Wertung), Kontinuität (wenige, lange Sessions pro aktivem Tag zählen mehr als viele kurze, 30 %) und Tiefe (mehr Hin und Her pro Session zählt mehr als einmalige Fragen, 20 %). Das Ergebnis ergibt ein Abzeichen: Deep Work Mode (ab 80), Focused (ab 60), Balanced (ab 40) oder Scattered (unter 40).

Für Einsteiger: Die wirksamste Gewohnheit ist, für ein zusammenhängendes Problem in einer zusammenhängenden Session zu bleiben und Rückfragen zu stellen, statt den Kontext in einer neuen Nachricht neu zu erklären. Das hebt meist beide Werte und ist ohnehin die bessere Arbeitsweise. Für Erfahrene: Ein dauerhaft niedriger Faktor über ein ganzes Projekt kann heißen, dass Systemanweisung oder gemeinsamer Kontext jedes Mal neu aufgebaut statt wiederverwendet werden. Das lohnt eine Änderung am Arbeitsablauf (länger lebende Sessions, eine gemeinsame Referenzdatei, Subagenten, die Kontext erben), statt es als normale Kosten hinzunehmen.

Aktuelles 5-Stunden-Fenster#

Claude Code setzt ein 5-Stunden-Fenster durch, und das ist verankert, nicht rollierend. Das Fenster öffnet mit deiner ersten Nachricht und läuft dann exakt fünf Stunden. Ein neues beginnt erst, wenn diese Zeitspanne vollständig abgelaufen ist, in festen Fünf-Stunden-Blöcken, unabhängig davon, wie viel Leerlauf dazwischen lag. Es sind nicht „die letzten fünf Stunden rückwärts ab jetzt", und es ist unabhängig vom Wochen-Reset, der nach seinem eigenen Zeitplan läuft und dabei kein neues 5-Stunden-Fenster startet.

Das Plugin rekonstruiert diese echten Fenster aus deiner Aktivität und summiert das gerade offene, mit Input, Output, C.Write und C.Read als eigenen Zeilen. Das zählt genau im Moment des Fensterwechsels: Eine rollierende Rechnung würde das Ende des eben geschlossenen Fensters zum Anfang des eben geöffneten addieren. Heraus käme eine Zahl, die zu keinem von beiden gehört, und das ausgerechnet dann, wenn du sehen willst, dass du frisches Budget hast.

Das ist die unmittelbarste Ansicht deiner laufenden Arbeit. Wenn du eine Weile ohne lange Pause gearbeitet hast, zeigt dieses Fenster, was du seit seiner Öffnung verbraucht hast.

Warum der Countdown eine Tilde (~) zeigt

Der Reset-Countdown unten in der Seitenleiste lautet „Claude 5h resets in: ~Xh Ym". Die Tilde ist Absicht, sie zeigt, dass es ein Näherungswert ist und kein exakter Wert.

Claude Code schreibt Session-Daten erst nach dem vollständigen Abschluss einer Antwort in lokale Dateien, nicht in dem Moment, in dem du deine erste Nachricht sendest. Die erste Anfrage einer Session ist oft lang: Kontext laden, Dateien lesen, nachdenken. Eine solche erste Antwort kann 10 bis 25 Minuten dauern, und in dieser Zeit steht noch nichts im lokalen Session-Log. Der früheste Zeitstempel, den das Plugin lesen kann, ist also nicht dein tatsächlicher Session-Start, sondern der Moment, in dem deine erste Antwort angekommen ist.

Der Countdown im Plugin kann deshalb 10 bis 25 Minuten hinter Claudes eigener Anzeige liegen. Die genaue Reset-Zeit steht im Bereich zur Plan-Nutzung in Claude Code oder auf claude.ai. Der Wert im Plugin ist eine verlässliche Orientierung, verbindlich ist Claudes eigene Anzeige.

Mit dem Feed (siehe Offizielle Prozentwerte von Anthropic) schließt sich diese Lücke: Jede Ablesung enthält den Zeitpunkt, zu dem das laufende Fenster zurückgesetzt wird. Sobald es eine Ablesung aus dem laufenden Fenster gibt, nutzt das Plugin den offiziellen Start, auch wenn das Fenster auf claude.ai, einem anderen Gerät oder in einem anderen Werkzeug geöffnet wurde.

Die drei Zeitansichten und ihr Verhältnis zueinander#

Die Seitenleiste zeigt drei verschiedene Zusammenfassungen deiner Aktivität: Aktuelles 5h-Fenster, Diese Session und Heute. Das sind drei unabhängige Schnitte durch dieselben Daten, sie schachteln sich nicht automatisch ineinander, wie Stunden, Tage und Wochen es täten.

Die wichtigste Folge: Eine Session kann mehrere Tage umspannen. Hast du gestern eine lange Session begonnen und heute weitergemacht, zeigt „Diese Session" mehr Tokens als „Heute". Das ist so gewollt: Die Session sammelt über Tagesgrenzen hinweg, „Heute" zählt erst ab Mitternacht.

Genauso ist das 5-Stunden-Fenster kein Teil von „Heute": Ein Fenster, das gestern Abend geöffnet hat, reicht über Mitternacht, und alles darin zählt weiter auf dasselbe Limit. Beide können aber auch gleich sein: Hat dein Fenster heute früh geöffnet und du hast davor heute nicht gearbeitet, zeigen beide dieselbe Zahl, bis das Fenster schließt.

Das Plugin macht das sichtbar: Eine kleine Zeile unter jedem Titel nennt den genauen Zeitraum. Bei „Diese Session" steht, wann die Session begonnen hat, so siehst du sofort, ob die Zahlen mehrere Tage umfassen.

Modelle#

Claude Code leitet Anfragen je nach Aufgabe an verschiedene Modelle weiter. Die Seitenleiste zeigt einen gestapelten Prozentbalken der Modellverteilung der letzten 7 Tage, jede Modellfamilie in ihrer eigenen Farbe:

Die Modellfarben meiden bewusst Grün, Gelb und Rot. Diese drei bedeuten im Plugin gut, Warnung und kritisch: Eine Farbe benennt etwas oder bewertet es, nie beides. Bis Oktober 2026 nannte diese Tabelle noch die Farben von vor 2.0 (Cyan, Blau, Lila, Amber).

Die Modellverteilung erklärt viele Kostenschwankungen von Tag zu Tag. Ein Tag mit viel Opus sieht in den Kosten ganz anders aus als ein Tag, der überwiegend in Haiku lief. Für die aktuelle Modellpalette und genaue Preise ist Anthropics eigene Preisseite maßgeblich, siehe auch API-Preisübersicht weiter unten.

Sessions#

Claude Code schreibt eine JSONL-Logdatei pro Session. Das Plugin liest alle Dateien unter ~/.claude/projects/ und gruppiert den Verbrauch nach Sessions. Die Tabelle Top Sessions im Dashboard zeigt, welche einzelnen Läufe die meisten Tokens verbraucht haben, nützlich, um unerwartet teure Sessions zu finden.

Was auf ein Limit einzahlt#

Anthropic setzt zwei Limits durch und sonst keins: das 5-Stunden-Fenster oben und ein Wochenlimit, das zu einem festen Zeitpunkt zurückgesetzt wird. Ein Tageslimit gibt es nicht, der Heute-Ring ist deshalb kein Kontingent (siehe Der Heute-Ring).

Input- und Output-Tokens zählen, und Cache ist nicht umsonst. Messungen gegen die offiziellen Prozentwerte, die Claude Code meldet (Oktober 2026), deuten darauf hin, dass Cache Writes deutlich auf das 5-Stunden-Fenster einzahlen und Cache Reads ein wenig. Eine frühere Auswertung beobachteter Limit-Treffer hatte in die andere Richtung gezeigt, die neueren Messungen sind direkter. Die Zahlen im Plugin zählen weiterhin nur Input und Output. Muss eine lange Session ihren Cache neu aufbauen, etwa in einem neuen 5-Stunden-Fenster nach einer Pause oder wenn ein großer Kontext zum ersten Mal geladen wird, kann der offizielle Wert dem Plugin deshalb vorauslaufen. Praktisch heißt das: Lange Sessions mit großem Kontext verbrauchen das 5-Stunden-Fenster pro Antwort schneller als frische, kurze.

Anthropic veröffentlicht keines der beiden Limits in Tokens. Seit 2.5 zeigt Token Usage deshalb einen Prozentwert für ein Limit nur, wenn er von Anthropic kommt, immer mit der Uhrzeit der Ablesung (siehe Limits: Prozente nur von Anthropic). Dafür braucht es den Feed, eine kleine Datei mit den offiziellen Prozentwerten (siehe Offizielle Prozentwerte von Anthropic). Zwischen zwei Ablesungen wird die Woche mit deinen gezählten Tokens weitergerechnet und als „hochgerechnet" gekennzeichnet. Das 5-Stunden-Fenster nicht, denn wie schnell es voll wird, hängt vor allem davon ab, wie viel Kontext eine Sitzung mitschleppt, und das können die lokalen Logs nicht verlässlich sagen. Ohne Feed siehst du gezählte Tokens, die Zeit bis zum Reset und die Spanne, bei der dein 5-Stunden-Fenster bisher voll war.

Der Heute-Ring#

Für den Tag gibt es kein Limit. Anthropic begrenzt nur das 5-Stunden-Fenster und die Woche. Der Heute-Ring vergleicht deinen heutigen Verbrauch mit deinem eigenen Schnitt pro aktivem Tag, gerechnet über alle Tage, die Claude Code aufbewahrt (deine Einstellung zur Datenaufbewahrung, cleanupPeriodDays).

Seit 2.5 zeigt er das als Vielfaches, nicht als Prozent: „2,0x dein üblicher Tag" heißt, dass du heute doppelt so viel arbeitest wie sonst, mehr nicht. Ein voller Tag ist eine geänderte Arbeitsweise, keine Warnung, deshalb bleibt der Ring neutral grau (seit 2.1.0). Wie nah du an einem Limit bist, zeigen nur die Ringe für das 5-Stunden-Fenster und die Woche, und nur mit einem offiziellen Wert. Bis 2.1 stand für denselben Vergleich „200 %". Mit dem Vielfachen kommt jedes Prozentzeichen auf dem Bildschirm entweder von Anthropic oder ist eine gekennzeichnete Wochen-Hochrechnung aus einem Wert von Anthropic.

Offizielle Prozentwerte von Anthropic (der Feed)#

Optional, seit 2.1.0. Claude Code kennt die offiziellen Prozentwerte deines Tarifs, also die Zahlen, die /usage anzeigt. Zwei kleine Skripte aus dem Plugin-Repository schreiben sie nach ~/.claude/ratelimit-log.jsonl. Seit 2.5 ist diese Datei die einzige Quelle für Limit-Prozentwerte in Token Usage: Ohne sie bleiben die Ringe für das 5-Stunden-Fenster und die Woche grau und zeigen gezählte Tokens und die Zeit bis zum Reset, alles andere funktioniert gleich. Die vollständige Anleitung (Englisch) liegt im Ordner extras auf GitHub.

Was du davon hast

Ein echtes Beispiel aus unseren eigenen Daten vom 27. Oktober 2026: Um 13:10 rechnete das Plugin die Woche von offiziellen 24 % auf etwa 28 % hoch, die nächste offizielle Ablesung sechs Minuten später sagte 29 %.

Voraussetzungen

• Ein Pro- oder Max-Abo, mit dem Claude Code angemeldet ist. Mit einem API-Schlüssel gibt es keine Tarif-Prozentwerte.
• Node.js, denn beide Skripte sind kleine Node-Programme. Prüfen mit node --version. Fehlt es, installiere die LTS-Version von der Node.js-Website. Wurde Claude Code mit dem nativen Installer eingerichtet, bringt es Node.js nicht mit.
• Eine aktuelle Claude-Code-Version, und für die Abfrage die Claude-Code-Kommandozeile claude.

Welches Skript brauche ich?

Eine Statuszeile läuft nur, solange das interaktive Claude-Code-Terminal offen ist. Programme, die Claude Code einbetten, führen sie nicht aus. Dort liefert die Statuszeile allein also kaum oder keine Ablesungen.

Weg A: Statuszeilen-Skript

Kopiere das Skript nach ~/.claude/ratelimit-statusline.js und ergänze diesen Eintrag in ~/.claude/settings.json, neben den Einträgen, die schon dort stehen:

"statusLine": { "type": "command", "command": "node ~/.claude/ratelimit-statusline.js" }

Unter Windows nimm den vollständigen Pfad mit Schrägstrichen nach vorn, zum Beispiel node C:/Users/<du>/.claude/ratelimit-statusline.js. Starte Claude Code neu, die Statuszeile zeigt dann 5h 12% | week 34%. Du nutzt schon eine eigene Statuszeile? Behalte sie und übernimm den Protokoll-Teil unseres Skripts.

Weg B: zeitgesteuerte Abfrage

Bevor du es einrichtest: Jeder Lauf ist eine echte, sehr kleine Anfrage (der Prompt ok an Haiku, ohne gespeicherte Session) und zählt auf deinen Verbrauch. Ist in dem Moment kein 5-Stunden-Fenster offen, öffnet die Anfrage eins, dein nächstes Fenster beginnt dann zur Abfragezeit. Plane sie für Zeiten, zu denen du ohnehin arbeitest. Dreimal am Tag reicht für die Woche völlig, das Plugin rechnet sie zwischen den Ablesungen weiter. Der 5-Stunden-Ring zeigt nur eine Ablesung aus dem laufenden Fenster, bei drei Abfragen am Tag ist er deshalb die meiste Zeit grau. Das ist der ehrliche Zustand, kein Fehler. Seit 2.5 versucht es das Skript nach einer Zeitüberschreitung ein zweites Mal: Ein Lauf direkt nach dem Aufwachen aus dem Standby hat oft noch kein Netz.

Oder nur, während du arbeitest (seit 2.5, empfohlen, wenn du den 5-Stunden-Ring sehen willst). Mit --only-when-active gestartet, prüft das Skript zuerst, ob Claude Code in den letzten 20 Minuten in seine Session-Logs geschrieben hat, und beendet sich sonst ohne Anfrage. Während du arbeitest, ist ohnehin ein 5-Stunden-Fenster offen, die Abfrage öffnet also praktisch keins selbst und kann stündlich laufen. Der 5-Stunden-Ring zeigt dann die meiste Zeit, in der du arbeitest, einen offiziellen Wert. Jeder Lauf bei Aktivität ist eine sehr kleine Anfrage, Läufe ohne Aktivität kosten nichts. Bis 2.5.0 haben wir alle 30 Minuten empfohlen, das sind doppelt so viele Anfragen für eine Ablesung, die höchstens eine halbe Stunde frischer ist. Die Befehle für diese Variante unter Windows, macOS und Linux stehen in der oben verlinkten Anleitung im Ordner extras, mit cron ist es einfach 0 7-23 * * * und der Schalter am Ende.

Kopiere das Skript nach ~/.claude/ratelimit-poll.js und starte es einmal von Hand mit node ~/.claude/ratelimit-poll.js. Es gibt 5h 12% | week 34% aus. Dann plane es ein.

Windows (PowerShell, läuft um 12:00, 17:00 und 22:00, holt verpasste Läufe nach, wenn der Rechner aus war, und öffnet kein Konsolenfenster):

$node     = (Get-Command node).Source
$script   = "$env:USERPROFILE\.claude\ratelimit-poll.js"
$action   = New-ScheduledTaskAction -Execute 'conhost.exe' -Argument "--headless `"$node`" `"$script`""
$triggers = '12:00','17:00','22:00' | ForEach-Object { New-ScheduledTaskTrigger -Daily -At $_ }
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable
Register-ScheduledTask -TaskName 'TokenUsageLimitPoll' -Action $action -Trigger $triggers -Settings $settings

Warum conhost.exe --headless (seit 2.5.1): node.exe ist ein Konsolenprogramm, deshalb öffnet die Aufgabenplanung bei jedem Lauf ein Konsolenfenster, auch bei Läufen, die gar nichts abfragen. Bis 2.5.0 haben unsere Befehle node.exe direkt gestartet und genau das getan. So gestartet bleibt der Lauf unsichtbar. Getestet haben wir es unter Windows 11. Microsoft dokumentiert diesen Schalter nicht, und manche Sicherheitssoftware meldet versteckte Konsolenstarts als verdächtig. Wenn deine das tut oder die Aufgabe nicht läuft, nimm stattdessen -Execute $node -Argument "`"$script`"" und lebe mit dem kurzen Fenster.

Schon mit einer früheren Anleitung eingerichtet? Das hier behält deine Aufgabe, Zeiten und Schalter und ergänzt nur den unsichtbaren Start:

$old = (Get-ScheduledTask -TaskName 'TokenUsageLimitPoll').Actions[0]
if ($old.Execute -notmatch 'conhost') {
  $new = New-ScheduledTaskAction -Execute 'conhost.exe' -Argument "--headless `"$($old.Execute)`" $($old.Arguments)"
  Set-ScheduledTask -TaskName 'TokenUsageLimitPoll' -Action $new
}

macOS und Linux (crontab -e, mit vollständigen Pfaden aus which node und which claude, weil cron mit einem minimalen PATH läuft):

0 12,17,22 * * * CLAUDE_BIN=/voller/pfad/zu/claude /voller/pfad/zu/node /Users/<du>/.claude/ratelimit-poll.js

Unter Linux heißt der Benutzerordner meist /home/<du>. Fehler zeitgesteuerter Läufe landen in ~/.claude/ratelimit-poll-errors.log. Findet das Skript die Claude-Code-Kommandozeile nicht, setze CLAUDE_BIN auf ihren vollständigen Pfad.

Prüfen, ob es läuft

• Die Datei ~/.claude/ratelimit-log.jsonl existiert und bekommt neue Zeilen.
• Aktualisiere die Seitenleiste. Der Wochen-Ring zeigt einen Prozentwert mit „Stand hh:mm" (oder „hochgerechnet" mit dem offiziellen Wert darunter), und der Hinweis „Offizielle Prozente gibt es mit dem Feed." unter den Ringen ist verschwunden. Der 5-Stunden-Ring zeigt direkt nach einer Ablesung im laufenden Fenster einen Prozentwert. Im Dashboard steht an den Panels „official percentage from Anthropic" oder „projected from the last official value".
• Direkt nach einer Ablesung zeigen /usage in Claude Code und die Ringe des Plugins dieselben Prozentwerte.

Wie das Plugin die Ablesungen nutzt

• Fensterstart: Jede Ablesung enthält den Zeitpunkt, zu dem das laufende 5-Stunden-Fenster zurückgesetzt wird. Das Fenster sind die fünf Stunden davor, so kennt das Plugin den echten Start, auch wenn das Fenster dort geöffnet wurde, wo es nicht hinsehen kann.
• 5-Stunden-Ring: zeigt die letzte Ablesung nur, solange ihr Fenster noch offen ist, mit der Uhrzeit der Ablesung und den seitdem gezählten Tokens. Im Fenster kann der offizielle Wert nur steigen, er ist also eine Untergrenze. Hochgerechnet wird nichts. Eine Ablesung aus einem früheren Fenster wird nicht gezeigt.
• Wochen-Ring: zeigt die letzte Ablesung der laufenden Woche. Zwischen zwei Ablesungen wird er mit deinen gezählten Tokens gegen das Wochenlimit weitergerechnet, das die Ablesungen ergeben (Tokens der Woche bis zu einer Ablesung geteilt durch ihren Prozentwert, aus Ablesungen ab 10 %, darunter ist die Rundung auf ganze Prozent zu grob), und als „hochgerechnet" gekennzeichnet. Nach einem Wochen-Reset ohne neue Ablesung geht es ab 0 % mit dem Limit der Vorwoche weiter, gekennzeichnet als „hochgerechnet seit Reset".
• Nutzungsguthaben: Mit Nutzungsguthaben (Usage Credits) kannst du nach dem Wochenlimit weiterarbeiten. Ablesungen ab 100 % und alles danach in derselben Woche fließen nicht ins Wochenlimit ein. Eine Woche bei 100 % zeigt den offiziellen Wert ohne Hochrechnung.
• Wochen-Reset: wird als genauer Zeitpunkt aus der Ablesung übernommen und stimmt deshalb auch über die Zeitumstellung hinweg.
• Weitere Fenster: Meldet Anthropic mehr als das 5-Stunden-Fenster und die Woche (etwa ein eigenes Wochenlimit für ein Modell), zeichnen beide Skripte das auf, und das Plugin zeigt es unter den Ringen, so wie gemeldet.
• Eine Weile kein Feed: Ohne passende Ablesung werden die Ringe wieder grau und zeigen gezählte Tokens und die Zeit bis zum Reset. Dazwischen wird nichts geschätzt.

Bekannte Grenzen

• Die Wochen-Hochrechnung zählt nur Input und Output. Offiziell zählen auch Cache Writes (Cache Reads ein wenig). Über eine Woche gleicht sich das gut aus (im Mittel 1,2 Punkte Abweichung in unserer Messung), ein großer Cache-Neuaufbau zeigt sich aber erst mit der nächsten Ablesung ganz.
• Ablesungen gibt es nur, wenn ein Skript läuft: solange eine Statuszeile angezeigt wird oder zu den geplanten Zeiten.
• Ganze Prozent: Die offiziellen Werte kommen gerundet. Ein Prozent eines 5-Stunden-Fensters können einige tausend Tokens sein.

Fehlersuche

Datenschutz und Entfernen

Alles bleibt auf deinem Rechner. Jede Zeile enthält einen Zeitstempel, die Prozentwerte mit ihren Reset-Zeiten und, von der Statuszeile, die Session- und Modell-ID. Das Plugin liest die Datei nur und führt die Skripte nie selbst aus. Zum Entfernen löschst du den Eintrag statusLine, die geplante Aufgabe (Unregister-ScheduledTask -TaskName 'TokenUsageLimitPoll') oder die cron-Zeile, und wenn du magst die Protokolldatei. Die Ringe für das 5-Stunden-Fenster und die Woche bleiben dann grau und zeigen gezählte Tokens und die Zeit bis zum Reset.

Aktualisiert am 10. Oktober 2026: Die erste Fassung dieses Abschnitts erwähnte Node.js nicht und bot nur die Statuszeile an, die in Programmen wie Obsidian nicht läuft. Beides ist ergänzt. Aktualisiert für 2.5: Bis 2.1 nutzte das Plugin die Ablesungen, um seine eigenen Limit-Schätzungen zu korrigieren, und fiel ohne sie auf diese Schätzungen zurück. Seit 2.5 sind die Ablesungen die einzige Quelle für Prozentwerte.

Wöchentlicher Reset#

Das Wochenlimit wird zu einem festen Zeitpunkt zurückgesetzt, und zwar je Konto unterschiedlich. Alles Wochenbezogene hängt daran: der Wochen-Ring, die Prognose und die Aktivitäts-Heatmap.

Normalerweise musst du hier nichts einstellen. Mit dem Feed übernimmt das Plugin den genauen Reset aus der offiziellen Ablesung. Ohne Feed liest es ihn aus der Meldung, die Claude schreibt, wenn du in ein Wochenlimit läufst. In beiden Fällen zeigen die Einstellungen einen grünen Haken und woher der Wert stammt. Solange noch kein Reset erkannt wurde, nimmt das Plugin Sonntag 18:00 an und sagt das auch.

Zeitumstellung. Anthropics Reset ist in UTC festgelegt, seine Uhrzeit bei dir verschiebt sich deshalb um eine Stunde, wenn die Uhren umgestellt werden. Bis 2.1 hat das Plugin ihn als Wochentag und Uhrzeit in Ortszeit gespeichert, nach der Umstellung auf Winterzeit lag deshalb jede Wochengrenze eine Stunde daneben. Seit 2.5 wird ein erkannter Reset als genauer Zeitpunkt geführt und folgt der Umstellung von selbst.

Von Hand geht es unter Einstellungen → Wöchentlicher Reset. Eine manuelle Einstellung gewinnt und bleibt in Ortszeit: Die automatische Erkennung überschreibt sie nicht, sie bestätigt sie nur.

Die Seitenleiste, Heatmap und Kalender#

Eine Symbolleiste links wechselt zwischen vier Seiten. Seit 2.0 ist das die einzige Darstellung, die frühere „Classic"-Ansicht und der Schalter dafür sind entfallen.

Alles auf der Übersicht stammt bewusst von heute oder aus der laufenden Woche, was längere Zeiträume umfasst, liegt auf der Auswertung oder im Dashboard. Im Kopfbereich erzeugen Dashboard und Report Dateien, CSV exportiert in deinen Vault, und der Pfeil aktualisiert sofort.

Jede der vier Token-Zeilen auf der Übersicht trägt eine kleine Markierung: ein grüner Punkt, wenn der Wert nahe an deinem eigenen jüngsten Schnitt liegt, ein gelber Pfeil, wenn er deutlich darüber liegt. Das Vergleichsfenster richtet sich nach deiner Claude-Datenaufbewahrung, nicht nach einer festen Anzahl Tage.

Aktivitäts-Heatmap

Das Raster auf der Übersicht zeigt deine laufende Abrechnungswoche. Eine Zeile je Kalendertag, eine Zelle je zwei Stunden, zwölf Zellen pro Tag.

Es hat acht Zeilen, nicht sieben: Eine Woche, die etwa von Sonntag 17:00 bis zum nächsten Sonntag 17:00 läuft, berührt acht Kalendertage, die erste und die letzte Zeile sind deshalb bewusst Teiltage. Zellen außerhalb des Fensters sind nur als leere Rahmen gezeichnet. Genau das macht die Grenze deines Zyklus sichtbar, statt sie in künstlichen 24-Stunden-Scheiben zu verstecken.

Die Farbe vergleicht jede Zelle mit deinem eigenen üblichen 2-Stunden-Block: dem Schnitt aller 2-Stunden-Blöcke mit Aktivität über die gespeicherten Tage (der Wert steht unter dem Raster). Niedrig ist unter der Hälfte davon, mittel bis dahin, hoch bis zum Doppelten, rot mehr als das Doppelte. Die Abstufung innerhalb einer Stufe zeigt, wo genau darin eine Zelle liegt. Bis 2.1 wurden die Zellen an einem geschätzten 5-Stunden-Limit gemessen, das es nicht mehr gibt.

Drei Arten von Nichts bleiben getrennt: außerhalb des Fensters (nur Rahmen), noch nicht erreicht (blass) und wirklich keine Aktivität (gefüllt). Nur das Letzte sagt etwas darüber, wie deine Woche lief. Neben dem Raster zählt Aktive Tage die Tage dieser Abrechnungswoche mit Aktivität.

Aktivitätskalender

Die Kalender-Seite zeigt die letzten zwei Monate nebeneinander. Zwei statt einem, weil ein einzelnes Raster am Monatsanfang nur eine Handvoll brauchbarer Tage zeigt und genau den Anlauf verbirgt, den du dort suchst. Die Pfeile verschieben das Paar weiter zurück, so weit das Archiv reicht, in die Zukunft geht der Kalender nie.

Jeder vergangene Tag trägt einen farbigen Punkt, gemessen an deinem eigenen jüngsten Tagesschnitt: grün darunter, gelb um den Schnitt herum, rot bei einem Ausschlag (2x oder mehr). Tage ohne Aktivität haben keinen Punkt. Ein Klick auf einen Tag legt eine private Notiz an, sie liegt in den Plugin-Einstellungen, nie in deinen Session-Daten.

Daten exportieren (CSV)#

Drei CSV-Dateien: die Projektübersicht, die Matrix Tag mal Vault und die Kennzahlen. Zwei Wege dorthin, und sie landen an verschiedenen Orten.

CSV-Button im Kopf der Seitenleiste: Das Plugin schreibt die Dateien in deinen Vault, in den Ordner aus Einstellungen → CSV-Export-Ordner im Vault. Das Menü nennt diesen Ordner, bevor du klickst. Dieselben Exporte liegen in der Befehlspalette unter „Export".

CSV-Export-Menü im Dashboard: Das Dashboard ist eine Browser-Seite, übergibt die Datei also deinem Browser, und der entscheidet über den Ablageort, meist dein Download-Ordner. Eine Webseite kann keinen Zielordner wählen, das ist eine Browser-Regel, keine fehlende Funktion.

Beide Wege liefern rohe Zahlen und ISO-Datumsangaben, direkt weiterrechenbar in Excel, Sheets oder einem Skript. Alles entsteht lokal, kein Upload, kein Netzwerk, wie im ganzen Plugin.

Die Kennzahlen folgen derselben Regel wie die Ringe (seit 2.5): die offiziellen Werte für das 5-Stunden-Fenster und die Woche mit der Uhrzeit der Ablesung, die gekennzeichnete Wochen-Hochrechnung, das Wochenlimit, das der Feed ergibt, und die Spanne deiner Limit-Treffer (niedrigster und höchster Wert). Die früheren Zeilen mit geschätzten Limits sind entfallen. Textzellen, die mit =, +, - oder @ beginnen, etwa ein ungewöhnlicher Ordnername, bekommen ein führendes Hochkomma, damit Excel oder LibreOffice sie nicht als Formel ausführen. Reine Zahlen bleiben, wie sie sind.

Archiv & Langzeit-Daten#

Warum es das überhaupt gibt. Claude Code verwaltet seine lokalen Session-Dateien selbst und löscht sie nach Zeitplan, standardmäßig nach 30 Tagen, gesteuert über cleanupPeriodDays in seiner eigenen ~/.claude/settings.json. Ohne eine Kopie an anderer Stelle ist alles Ältere schlicht weg.

Was geschrieben wird, und wohin. Immer wenn Obsidian offen ist (bei jeder Aktualisierung, durch die regelmäßige Abfrage oder den Datei-Watcher), prüft das Plugin, welche der letzten Tage schon eine Archivdatei haben, und schreibt eine für jeden fehlenden Tag, auch für heute, laufend aktualisiert. Die Dateien landen in einem normalen Ordner in deinem Vault, eine pro Kalendertag: Token Usage Archive/JJJJ-MM-TT.md (Ordnername in den Einstellungen änderbar). Jede Datei enthält nur Summen: Token-Zahlen nach Art, Anzahl der Sessions, Token-Volumen je Modell und die Aufschlüsselung nach Vault und Projekt für diesen Tag, nie einen Prompt, eine Antwort oder irgendetwas, das nach Gesprächsinhalt aussieht.

Einmal geschrieben, gilt die Datei eines vergangenen Tages als endgültig und bleibt bei späteren Aktualisierungen unberührt. Die eine bewusste Ausnahme: Bringt ein Release eine ganz neue Datenquelle (so kamen in v1.8.0 die Sessions aus dem Agent-Modus der Desktop-App dazu), schreibt ein einmaliger Neuaufbau die betroffenen letzten Tage einmal neu, damit Summen, die vor dieser Quelle unvollständig waren, nicht dauerhaft falsch aussehen.

Das Archiv lässt sich ganz abschalten (Einstellungen → Tägliches Archiv aktivieren), wenn das Plugin keine Dateien in deinem Vault anlegen soll. Alles funktioniert dann weiter, die Rückschau reicht aber nur so weit, wie Claude Code selbst noch Daten auf der Festplatte hat.

Dashboard & Auswertung nach Vault und Projekt#

Die Seitenleiste ist für den schnellen Blick gebaut, das HTML-Dashboard (Befehlspalette → „Open Token Usage dashboard") für das Arbeiten mit den Zahlen. Es erzeugt eine statische HTML-Datei neu und öffnet sie in deinem Browser: eine Momentaufnahme, keine Live-Verbindung, und in der Ecke steht ehrlich, von wann sie ist.

Drei Reiter. Dashboard: die Budget-Panels für das 5-Stunden-Fenster, heute und die Woche, dann fünf Kennzahl-Karten (Weekly Forecast, Limit Health, Cache Efficiency, Daily Velocity, Focus Score), ein Wochenbalken, das Tagesdiagramm, Modellverteilung, Histogramm, Top Sessions und die Rate-Limits, in die du gelaufen bist, mit ihrer Spanne. Reports: dieselben Zahlen im Aufbau des Markdown-Reports. Projects: die Aufschlüsselung nach Vault und Projekt, siehe unten.

Dieselbe Regel wie in der Seitenleiste (seit 2.5): Die Budget-Panels, die Gesamtzone, die Karte Limit Health und das Urteil des Wochenbalkens nutzen nur offizielle Werte mit der Uhrzeit der Ablesung oder die daraus gekennzeichnete Wochen-Hochrechnung. Ohne Feed zeigen die Panels gezählte Tokens und die Zeit bis zum Reset, und Limit Health verweist auf die Einrichtung, statt zu raten. Der Weekly Forecast bleibt: Er rechnet deinen eigenen gezählten Verbrauch bis zum Ende der Abrechnungswoche hoch, er ist kein Limit.

Das Zeitraum-Menü (30/60/180/360 Tage) stellt Kennzahlen, Tagesdiagramm und Cache-Diagramm sofort im Browser um, ein vollständiges 360-Tage-Fenster ist immer eingebettet. Modellverteilung, Histogramm, Top Sessions und die Erkennung von Rate-Limits bleiben trotzdem beim Live-Datenfenster, denn das Archiv für längere Zeiträume enthält nur Tagessummen, nicht diese Session-Details. Das gilt auch für die Spanne deiner Limit-Treffer: Sie wird aus den Tokens gemessen, die bis zum jeweiligen Treffer gezählt wurden, und die hat nur das Live-Fenster.

Ordner- und Modellnamen werden entschärft (seit 2.5). Der Projektname im Dashboard ist der letzte Ordner des Arbeitsverzeichnisses, in dem eine Session gestartet wurde. Bis 2.1 setzte das Dashboard diese Namen ungefiltert in die Seite ein. Ein präparierter Ordnername, etwa der eines geklonten Repositorys, hätte damit Skript in der Dashboard-Seite in deinem Browser ausführen können. Wir haben das bei unserer eigenen Sicherheitsprüfung im Oktober 2026 gefunden und haben keinen Hinweis, dass es je genutzt wurde. Die Seitenleiste in Obsidian war nicht betroffen.

Reiter Projects, für mehr als einen Vault oder Kunden. Jede Zeile ist ein Ordner, in dem eine Claude-Code-Session gestartet wurde: dein Obsidian-Vault, der Sammelplatz des Agent-Modus der Desktop-App (angezeigt als Claude Desktop (Agent Mode)) oder jedes andere Verzeichnis, in dem du Claude Code direkt aufgerufen hast. Ordner unter 1 % der Gesamtsumme werden zu einer Zeile „Other" zusammengefasst. Mit „Show sub-project detail" klappst du jeden Vault, dessen Arbeitsverzeichnis während einer Session gewechselt hat, in seine Unterordner auf, direkt in der Tabelle. Dieselbe Aufschlüsselung steht auch im eigenständigen Export Vault_Token_Usage_Projects.md, praktisch, um Kosten bei der Abrechnung auf Kunden aufzuteilen. Ein Klick auf eine Spaltenüberschrift sortiert.

Export-Befehle (Befehlspalette), jeder überschreibt seine Zieldatei im Vault bei jedem Lauf: Create Token Usage report (Token Usage Report.md), Open Token Usage dashboard (Token Usage Dashboard.html), Create Vault Token Usage Projects report (Vault_Token_Usage_Projects.md). Alle drei Pfade sind einstellbar, siehe Einstellungen im Überblick.

Was gemessen wird (und was nicht)#

Das Plugin erfasst jede Art, wie du Claude Code nutzt: im Terminal, in Obsidian, in einem Editor wie VS Code und im Agent-Modus der Desktop-App, alles fließt in dieselben Zahlen (wie genau, steht unter Datenquellen & Transparenz). Nicht zeigen kann es den normalen Chat, also Gespräche im normalen Chatfenster der Claude-Desktop-App oder auf claude.ai im Browser. Dort werden keine Token-Zahlen in dem Format auf die Festplatte geschrieben, das dieses Plugin liest, verfügbar ist dort nur ein gerundeter Prozentwert deines Tarif-Limits. Fühlt sich ein Tag voller an, als das Dashboard zeigt, liegt es sehr oft daran.

Einstellungen im Überblick#

Jede Einstellung des Plugins, in der Reihenfolge, in der sie unter Einstellungen → Token Usage erscheint. Die Vorgaben sind so gewählt, dass eine frische Installation ohne Änderung gut läuft.

Jedes Pfad- und Ordnerfeld hat daneben einen Knopf „Im Explorer/Finder anzeigen", der genau diesen Ort in deinem Dateimanager öffnet.

API-Preisübersicht#

API-Preise von Anthropic pro Million Tokens, Standard-Input und Output, Stand Oktober 2026:

* Haiku 5.5 für Prompts bis 100.000 Tokens, darüber $0,50 Input / $2,50 Output.
** Sonnet 5 startete mit $2 / $10 als Einführungspreis bis 31. August 2026. Anthropic hat ihn inzwischen zum regulären Preis gemacht, die angekündigte Erhöhung auf $3 / $15 fand nicht statt. Die frühere Fassung dieser Seite sagte das noch anders.

Cache-Preise zusätzlich zum Standard-Input-Preis:

• C.Write: das 1,25-fache des Standard-Input-Preises für einen 5-Minuten-Cache, das 2-fache für einen 1-Stunden-Cache (bei Claude Code im Abo der Normalfall)
• C.Read: das 0,1-fache des Standard-Input-Preises, das 0,05-fache bei Opus 5.5 und Sonnet 5.5, das 0,025-fache bei Fable 5.1

Warum Kosten entstehen#

Eine einzelne Anfrage ist selten teuer. Kurzes Rechenbeispiel mit Sonnet 5 zum regulären Preis von $2 / $10 pro Million:

• 10.000 Input-Tokens × $2 / 1M = $0,02
• 2.000 Output-Tokens × $10 / 1M = $0,02
• Gesamt: ca. $0,04

Das ist nahezu nichts. Das Problem sind Wiederholung und wachsender Kontext. Jede neue Nachricht in einer Session schickt typischerweise den bisherigen Gesprächsverlauf und alle offenen Dateien erneut als Input mit. Nach zehn Wechseln trägt Nachricht zehn alle neun vorherigen Runden plus alle angehängten Dokumente, der Input wächst also mit jedem Schritt, selbst wenn du nur eine kurze Frage tippst.

Die Frage selbst ist selten der Kostentreiber. Entscheidend ist, was mit ihr mitgeschickt wird.

Was die Kosten treibt#

• Lange Sessions, in denen ein großes Kontextfenster bei jeder Anfrage erneut gesendet wird
• Große angehängte Dateien oder komplette Codebasen, die als Input bei jeder Nachricht mitreisen
• Häufige schnelle Anfragen in kurzer Zeit
• Ein teures Modell für Aufgaben, die ein günstigeres genauso gut erledigt

Praktische Tipps#

Erst messen. Das Tagesdiagramm und die Session-Tabelle des Plugins zeigen, wo die Tokens tatsächlich hingehen. Was du nicht angeschaut hast, kannst du nicht verbessern.

Unnötigen Kontext vermeiden. Große Dateien, die nur „für den Fall der Fälle" angehängt werden, zählen bei jeder Anfrage als Input. Schick nur mit, was Claude für die aktuelle Aufgabe braucht.

Modell nach Aufgabe wählen. Nicht jede Anfrage braucht Opus. Kurze Fragen, Formatierungsaufgaben und einfache Code-Änderungen funktionieren oft mit Haiku oder Sonnet zu einem Bruchteil der Kosten. Vergleiche Qualität und Gesamtkosten pro erledigter Aufgabe, nicht nur den Preis pro Token.

Den Cache verstehen. Ein Anstieg bei C.Write zu Beginn einer Session ist normal, ein großer Kontext wurde aufgebaut. Entscheidend ist, ob C.Read folgt. Wird derselbe Kontext bei vielen Anfragen wiederverwendet, amortisieren sich die einmaligen Write-Kosten schnell, und die effektiven Kosten pro Anfrage sinken deutlich.

Das Dashboard nutzen. Das HTML-Dashboard (über den Diagramm-Knopf in der Seitenleiste) zeigt deine Nutzungshistorie, 30, 60, 180 oder 360 Tage über das Zeitraum-Menü im Kopf, dazu Modellverteilung und den Trend der Cache-Effizienz. Muster über mehrere Tage zeigen sich dort, nicht in der Ansicht einer einzelnen Session.

Häufige Fragen & Fehlersuche#

Funktioniert das unter macOS und Linux oder nur unter Windows? Auf allen Plattformen, der Kern des Plugins war schon immer plattformneutral. Das einzige plattformspezifische Detail ist der Ablageort der Sessions aus dem Agent-Modus der Desktop-App, eine reine Windows-Eigenheit, ausführlich unter Datenquellen & Transparenz.

„Diese Session" zeigt mehr Tokens als „Heute", ist das ein Fehler? Nein. Eine Claude-Code-Session kann über Mitternacht laufen, siehe die drei Zeitansichten oben.

Warum sind meine Ringe für das 5-Stunden-Fenster und die Woche grau, ohne Prozentwert? Seit 2.5 zeigt das Plugin einen Limit-Prozentwert nur, wenn er von Anthropic kommt. Dafür braucht es den optionalen Feed. Ohne ihn zeigen die Ringe gezählte Tokens und die Zeit bis zum Reset, und eine kurze Zeile darunter verlinkt die Einrichtung. Mit einer Abfrage zu festen Zeiten, ein paar Mal am Tag, bleibt der 5-Stunden-Ring trotzdem die meiste Zeit grau, weil eine 5-Stunden-Ablesung nur in dem Fenster gilt, in dem sie entstanden ist. Läuft die Abfrage mit --only-when-active stündlich, ändert sich das. Siehe Limits: Prozente nur von Anthropic.

Warum zeigt die Karte „Limit Health" im Dashboard keinen Wert? Aus demselben Grund: Sie braucht einen offiziellen Wochenwert aus dem Feed. Solange es keinen gibt, verweist die Karte auf die Einrichtung, statt zu raten.

Wo ist das geschätzte Limit hin? Es ist mit 2.5 entfallen, weil es zu oft falsch lag: Beim 5-Stunden-Fenster im Schnitt 36 Punkte neben den offiziellen Werten. Geblieben ist die Spanne, bei der dein 5-Stunden-Fenster bisher voll war.

Mein Chat im Browser (claude.ai) oder im normalen Chat der Desktop-App taucht nirgends auf. Erwartet, kein Fehler, siehe Was gemessen wird und Datenquellen & Transparenz oben.

Die Plugin-Prüfung von Obsidian meldet „Direct Filesystem Access". Muss mich das beunruhigen? Nein, dieser Hinweis ist für das, was das Plugin tut, erwartet und unvermeidbar. Was gelesen wird und was nicht, steht genau unter Datenquellen & Transparenz.

Die Zahlen eines Tages haben sich nach einem Plugin-Update geändert. Sind alte Daten beschädigt? Mit großer Sicherheit nicht, siehe den einmaligen Neuaufbau unter Archiv & Langzeit-Daten.

Kann ich mehr als einen Obsidian-Vault erfassen oder den Verbrauch nach Kunden aufteilen? Ja, siehe Dashboard & Auswertung nach Vault und Projekt.

Brauche ich einen API-Key oder ein Anthropic-Konto für dieses Plugin? Nein. Es liest lokale Dateien, die Claude Code ohnehin auf deinem Rechner schreibt.

Ich hatte Obsidian ein paar Wochen geschlossen. Ist dieser Verbrauch für immer weg? Wenn er in der Zeit, in der Obsidian geschlossen war, aus deiner Claude-Datenaufbewahrung gefallen ist, ja, siehe den Kasten zur ehrlichen Grenze unter Archiv & Langzeit-Daten.

Kompatibilität & Claude-Code-Updates#

Token Usage liest die JSONL-Session-Dateien, die Claude Code lokal schreibt. Anthropic aktualisiert Claude Code regelmäßig, manchmal auf eine Weise, die beeinflusst, wie Session-Daten aufgezeichnet oder wie interne Telemetrie gezählt wird.

Wir prüfen Anthropics Release-Notes bei jedem größeren Claude-Code-Update und passen das Plugin bei Bedarf an. Wesentliche Kompatibilitätsänderungen stehen im Plugin-Changelog auf GitHub.

Über dieses Plugin#

Token Usage ist ein quelloffenes Obsidian-Community-Plugin. Es liest lokale JSONL-Dateien von Claude Code, keine Daten werden irgendwohin geschickt. Fehlt dir etwas auf dieser Seite? Issues und Wünsche sind jederzeit willkommen.

• GitHub: beolatn/TokenUsage
• Obsidian Plugin-Verzeichnis: Token Usage
• Autor: Björn-Olaf Lange · langeatn.de

Die Preise auf dieser Seite stammen aus den Anthropic Platform Docs. Stand Oktober 2026. Preise können sich ändern, aktuelle Werte immer direkt auf der Anthropic-Website prüfen.