2.1.0Oktober 2026
Release auf GitHub → (öffnet in neuem Tab)Sechs Dinge in diesem Plugin waren falsch, und zwei davon waren Aussagen, die wir selbst in den 2.0.0-Notizen unten gemacht haben. Alle sechs sind hier korrigiert. Deine Zahlen ändern sich nach dem Update, meist nach unten, und hier steht, warum.
Korrekturen
- Lange Antworten wurden vielfach mitgezählt. Claude Code schreibt eine einzelne Antwort einmal pro Inhaltsblock ins Sitzungsprotokoll, bei langer gestreamter Ausgabe bis zu etwa 75 Mal, und jede Zeile wiederholt die vollständigen Token-Zahlen dieser einen Antwort. Das Plugin hat jede Zeile addiert, eine Antwort mit 7,7K Output-Tokens erschien deshalb als rund 580K. In einer gemessenen halben Stunde zeigte die Seitenleiste 1,31M Tokens bei tatsächlich 70K: Der 5-Stunden-Ring sprang auf 448 %, Heute auf 330 % und Diese Woche auf 114 %, obwohl nichts Ungewöhnliches passiert war. Jede Antwort wird jetzt genau einmal gezählt, erkannt an Nachrichten-ID und Request-ID, und die Zeile mit dem höchsten Output-Wert gewinnt. Auch kurze Antworten waren betroffen, etwa um den Faktor zwei, deine Zahlen können nach dem Update also etwas niedriger ausfallen. Weil die 5-Stunden-Schätzung aus denselben Zählungen abgeleitet wird, kann auch sie sich leicht verschieben
- Die Arbeit von Subagenten wurde nie gezählt. Wenn Claude Code Subagenten einsetzt (das Agent-Werkzeug), schreibt es deren Arbeit in einen Unterordner der Sitzung. Dort hat das Plugin nie nachgesehen, diese Tokens fehlten also in jeder Zahl. In unseren eigenen Daten waren das 0,7 % der letzten 30 Tage, aber bis zu 47K Tokens in einem einzigen 5-Stunden-Fenster, das ans Limit lief. Subagenten-Protokolle werden jetzt gelesen und der Sitzung zugerechnet, zu der sie gehören
- Cache zählt doch. Hier lagen wir in 2.0.0 falsch. In den 2.0.0-Notizen steht, Cache-Lesen und Cache-Schreiben zählten nicht aufs Limit, „geprüft an über 80 beobachteten Limit-Treffern“. Diese Auswertung lief auf den überhöhten Summen des ersten Fehlers oben und konnte deshalb nicht zeigen, was sie behauptete. Seitdem gegen die offiziellen Prozentwerte gemessen, die Claude Code meldet: Cache-Schreiben zählt deutlich aufs 5-Stunden-Fenster, Cache-Lesen ein wenig. Ein Beispiel aus unseren Daten: Eine lange Sitzung, die nach einer Pause ihren Cache neu aufbauen musste, verbrauchte 17 % eines frischen Fensters bei nur 4,4K Input- und Output-Tokens. Die Zahlen des Plugins zählen weiterhin nur Input und Output, der offizielle Prozentwert kann ihnen also vorauslaufen, am stärksten am Anfang eines Fensters. Glossareintrag und Hilfeabschnitt „Was auf ein Limit einzahlt“ sind neu geschrieben
- Die Wochenschätzung konnte deutlich zu niedrig liegen. Sie ist die niedrigste Woche, die je ans Wochenlimit kam. In unseren Daten waren das 1,14M Tokens gegenüber rund 2,7M laut offiziellen Prozentwerten, und die Seitenleiste zeigte 141 %, während Claude Code 61 % meldete. Auch Cache, den das Plugin nicht zählt, bringt dich ans Limit, eine Woche kann also bei einer niedrigen Tokenzahl enden. Ohne den neuen Statusline-Feed (unten) kommt die Schätzung weiter aus deinen Treffern, und die Hilfe sagt offen, dass sie zu niedrig sein kann. Mit dem Feed wird der offizielle Wert verwendet
- „29-Tage-Durchschnitt“ war nicht, was wir gerechnet haben. Die 2.0.0-Notizen und das Dashboard sagen, „Heute“ werde mit deinem 29-Tage-Durchschnitt verglichen. Seit 1.7 nutzt das Plugin tatsächlich alle Tage, die Claude Code aufbewahrt (deine Aufbewahrungseinstellung). Die Beschriftungen sagen das jetzt, die Rechnung bleibt
- Die Cache-Preise in der Hilfe waren unvollständig und teils veraltet. Wir hatten geschrieben, ein Cache-Write koste etwa 1,25× des Input-Preises. Das gilt für den 5-Minuten-Cache, der 1-Stunden-Cache kostet 2×, und genau der ist bei Claude Code im Abo der Normalfall (rund 90 % in unseren eigenen Logs). Cache-Reads kosten bei Opus 5.5 und Sonnet 5.5 nur 0,05× statt 0,1×. Der Preistabelle auf der Hilfeseite fehlten außerdem die neuesten Modelle, und sie nannte den Sonnet-5-Preis noch einen Einführungspreis. Ein Nutzer im Obsidian-Forum hat uns im Oktober auf den 1-Stunden-Cache hingewiesen, und wir hatten diese Korrektur für 2.1 zugesagt. Glossar, README und Hilfe folgen jetzt der offiziellen Preisseite, Stand Oktober 2026
Geändert
- Der Heute-Ring ist neutral grau. Es gibt kein Tageslimit, und Grün, Gelb und Rot neben zwei echten Limits lesen sich wie eine Warnung. Ein voller Tag ist eine geänderte Arbeitsweise, kein Risiko. Das Dashboard-Panel nennt stattdessen das Vielfache („2.5x your usual day“)
Neu
- Optional: Limits an den offiziellen Prozentwerten verankert. Claude Code übergibt jedem Statusline-Skript die offiziellen Prozentwerte für das 5-Stunden-Fenster und die Woche. Ein kleines Skript, das mit diesem Release kommt (
extras/ratelimit-statusline.js), zeigt sie in deiner Statuszeile und protokolliert sie auf deinem Rechner. Liegt dieses Protokoll vor, beginnt das 5-Stunden-Fenster dann, wenn das offizielle Fenster beginnt, und beide Limit-Ringe zeigen bei jeder Ablesung genau den offiziellen Prozentwert und zählen bis zur nächsten mit deinen Tokens weiter. Ohne das Skript ändert sich nichts. Einrichtung: siehe Hilfeseite, Abschnitt „Offizielle Prozentwerte aus der Statuszeile“ - Glossareintrag „Der Heute-Ring“, dazu „Was auf ein Limit einzahlt“ neu geschrieben, in allen fünf Sprachen
- Tooltip an C.Write mit der Aufteilung nach 1 Stunde und 5 Minuten. Fahr mit der Maus über eine C.Write-Zeile, dann siehst du, wie viel davon für eine Stunde und wie viel für fünf Minuten geschrieben wurde. Eine eigene Zeile dafür haben wir geprüft und verworfen: In der Seitenleiste ist kein Platz für eine fünfte Zeile, und das Plugin rechnet keine Kosten aus
Bekannte Grenzen
- Zwischen zwei Ablesungen addiert das Plugin nur Input und Output. Ein Cache-Neuaufbau (neuer Chat, abgelaufener Cache) erscheint mit der nächsten Ablesung
- Archivierte Tage, die älter sind als dein Aufbewahrungsfenster, behalten ihre alten Zahlen: Die Protokolle, aus denen man sie neu zählen könnte, gibt es nicht mehr. Tage innerhalb des Fensters werden nach dem Update einmal neu geschrieben
- Ob 1-Stunden- und 5-Minuten-Cache-Writes unterschiedlich aufs Limit zählen, ist noch offen. In allen Abschnitten, die wir messen konnten, waren die Cache-Writes ausschließlich 1-Stunden-Writes, ein eigenes Gewicht für die 5-Minuten-Art lässt sich daraus noch nicht bestimmen. Wir messen weiter