Entwickler baut permanente Verbrauchsanzeige für Claude Code auf Windows
Claude-Code-Nutzer stoßen mitten in der Arbeit an das Nutzungslimit, der offizielle /usage-Befehl liefert den Stand aber nur auf Anfrage. Aus lokalen Logs ließ sich das Fünf-Stunden-Fenster schätzen, woraus eine dauerhaft eingeblendete Gauge entstand.
Wenn Sie den ganzen Tag mit Claude Code arbeiten, wurden Sie wahrscheinlich mitten in einer Aufgabe durch die Meldung "usage limit reached" gestoppt. Der Befehl /usage nennt Ihnen zwar die offizielle Zahl, aber nur, wenn Sie anhalten und danach fragen. Ich wollte die Antwort dauerhaft in einer Ecke meines Bildschirms sehen, während ich arbeite, und habe deshalb ein kleines Windows-Gauge gebaut, das anhand der Logdateien, die Claude Code ohnehin schreibt, schätzt, wie viel Kontingent noch übrig ist. In diesem Beitrag geht es darum, wie diese Schätzung funktioniert.
Claude Code schreibt pro Session eine JSONL-Datei unter ~/.claude/projects/<project>/<session>.jsonl. Die Assistant-Zeilen enthalten message.usage:
{ "timestamp": "...", "message": { "model": "...", "usage": { "input_tokens": 12, "output_tokens": 840, "cache_creation_input_tokens": 3021, "cache_read_input_tokens": 98000 }}} Enter fullscreen mode Exit fullscreen mode Die Dateien werden nur angehängt und nie überschrieben, daher merke ich mir pro Datei das letzte Byte-Offset und lese nur die neuen Inhalte. Selbst bei Gigabytes an Logs kostet jede Aktualisierung fast nichts. Anmeldedaten oder Tokens werden niemals gelesen.
cache_read_input_tokens ist riesig (ein langes Chat liest leicht 100k oder mehr pro Runde). Addiert man diesen Wert ein, verfälscht das die Schätzung erheblich. Ich zähle input + output + cache_creation als Verbrauch und nutze cache_read nur, um einzuschätzen, wie weit der Kontext eines Chats inzwischen gewachsen ist.
Ein Fenster beginnt mit der ersten Anfrage nach dem Ende des vorherigen Fensters, abgerundet auf die volle Stunde, und dauert 5 Stunden (eine Schätzung, die dem beobachteten Verhalten entspricht):
BLOCK = timedelta ( hours = 5 ) def usage_blocks ( events ): out = [] for ts, i, o, cc, _cr, _m in events: if not out or ts >= out [ - 1 ][ 1 ]: start = ts. replace ( minute = 0, second = 0, microsecond = 0 ) out. append ([ start, start + BLOCK, 0 ]) out [ - 1 ][ 2 ] += i + o + cc return out Enter fullscreen mode Exit fullscreen mode 4. Woher kommt das Limit? Die Plangrenzen werden nicht offengelegt und ändern sich mit der Zeit, daher lernt das Gauge Ihr Limit:
Zeilen mit Ausgabenlimits basieren auf Geldbeträgen und werden daher für das Lernen ignoriert.
Aus den letzten 30 Minuten Nutzung projiziert das Tool, wann Ihr Kontingent aufgebraucht sein wird, und zeigt ein gelbes Badge an, wenn Sie schneller verbrauchen als Ihr üblicher Spitzenwert. Es ist keine perfekte Vorhersage, aber zu wissen, dass "noch etwa eine Stunde übrig" ist, bevor man ein großes Refactoring startet, hat verändert, wie ich meine Arbeit plane.
Derselbe Ansatz liest auch die Logs von Codex, Gemini CLI und Antigravity. Cursor speichert keine Nutzungsdaten lokal, daher schätzt dessen Tab die Aktivität nur aus der Chat-Datenbank (schreibgeschützt geöffnet).
Das Ganze ist als AI Usage Gauge verpackt (Windows, Benutzeroberfläche auf EN/JA/ZH/KO). 7 Tage kostenlose Testphase, danach ein einmaliger Kauf.
https://github.com/aivex2024-spec/usagegauge
Inoffizielles, unabhängiges Tool, keine Verbindung zu Anthropic. Die Zahlen sind Schätzwerte. Feedback zur Schätzmethode ist jederzeit willkommen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
If you use Claude Code all day, you've probably been stopped mid-task by "usage limit reached". /usage tells you the official number, but only when you stop and ask. I wanted the answer to sit in the corner of my screen while I work, so I built a small Windows gauge that estimates what's left from the logs Claude Code already writes. This post is about how the estimate works.
Claude Code writes one JSONL file per session under ~/.claude/projects/<project>/<session>.jsonl. Assistant lines carry message.usage:
{ "timestamp": "...", "message": { "model": "...", "usage": { "input_tokens": 12, "output_tokens": 840, "cache_creation_input_tokens": 3021, "cache_read_input_tokens": 98000 }}} Enter fullscreen mode Exit fullscreen mode The files are append-only, so I remember the last byte offset per file and read only what's new. Even with gigabytes of logs, each refresh costs almost nothing. It never reads login data or tokens.
cache_read_input_tokens is huge (a long chat easily reads 100k+ per turn). Adding it in wrecks the estimate. I count input + output + cache_creation as usage and use cache_read only to judge how long a chat's context has grown.
A window starts at the first request after the previous window ended, floored to the hour, and lasts 5 hours (an estimate that matches observed behaviour):
BLOCK = timedelta ( hours = 5 ) def usage_blocks ( events ): out = [] for ts, i, o, cc, _cr, _m in events: if not out or ts >= out [ - 1 ][ 1 ]: start = ts. replace ( minute = 0, second = 0, microsecond = 0 ) out. append ([ start, start + BLOCK, 0 ]) out [ - 1 ][ 2 ] += i + o + cc return out Enter fullscreen mode Exit fullscreen mode 4. Where does the limit come from? Plan limits aren't published and change over time, so the gauge learns your limit:
Spend-limit lines are money-based, so they're ignored for learning.
From the last 30 minutes of usage it projects when you'll run out, and shows a yellow badge when you're going faster than your usual peak. It's not a perfect prediction, but knowing "about an hour left" before starting a big refactor has changed how I plan work.
The same approach reads Codex, Gemini CLI and Antigravity logs. Cursor doesn't store usage locally, so its tab only estimates activity from its chat database (opened read-only).
All of this is packaged as AI Usage Gauge (Windows, EN/JA/ZH/KO UI). 7-day free trial, then a one-time purchase.
https://github.com/aivex2024-spec/usagegauge
Unofficial, independent tool — not affiliated with Anthropic. Numbers are estimates. Feedback on the estimation method is very welcome.