2.1.0October 2026
Release on GitHub → (opens in a new tab)Six things in this plugin were wrong, and two of them were claims we made ourselves in the 2.0.0 notes below. All six are corrected here. Your numbers will change after updating, mostly downward, and this is why.
Corrections
- Long responses were counted many times over. Claude Code writes a single response to its session log once per content block, and for long streamed output up to about 75 times, each line repeating the full token counts of that one response. The plugin added up every line, so one reply of 7.7K output tokens showed up as roughly 580K. In a measured 30-minute stretch the sidebar displayed 1.31M tokens against a real 70K: the 5-hour ring jumped to 448%, Today to 330%, This Week to 114%, although nothing out of the ordinary had happened. Each response is now counted exactly once, identified by its message ID and request ID, and the line with the highest output count wins. Short replies were affected too, at about a factor of two, so your figures may be a little lower after updating. Because the 5-hour estimate is derived from the same counts, it may shift slightly as well
- Subagent work was never counted. When Claude Code runs subagents (the Agent tool), it writes their work into a subfolder of the session. The plugin never looked there, so those tokens were missing from every figure. On our own data that was 0.7% of the last 30 days, but up to 47K tokens inside a single 5-hour window that hit its limit. Subagent logs are now read and counted with the session they belong to
- Cache does count. We were wrong about this in 2.0.0. The 2.0.0 notes say cache reads and writes do not count toward a limit, "verified against 80+ observed limit hits". That analysis ran on the inflated totals of the first error above, so it could not show what it claimed. Measured since against the official percentages Claude Code reports: cache writes clearly count toward the 5-hour window, cache reads a little. One example from our own data: a long session that had to rebuild its cache after a pause took 17% of a fresh window on just 4.4K input and output tokens. The plugin's figures still count input and output only, so the official percentage can run ahead of them, most of all at the start of a window. The glossary entry and help section "What counts toward a limit" are rewritten
- The weekly estimate could sit far too low. It is the lowest week that ever hit the weekly cap. On our own data that was 1.14M tokens against about 2.7M implied by the official percentages, and the sidebar showed 141% while Claude Code said 61%. Cache use that the plugin does not count also drives you into the cap, so a week can end at a low token figure. Without the new status line feed (below) the estimate still comes from your hits, and the help says plainly that it can be too low. With the feed, the official figure is used
- "29-day average" was not what we computed. The 2.0.0 notes and the dashboard say Today is compared against your 29-day average. Since 1.7 the plugin has in fact used every day Claude Code keeps on disk (your retention setting). The labels now say so; the calculation stays
- Cache prices in the help were incomplete and partly out of date. We wrote that a cache write costs about 1.25× the input price. That is the 5-minute cache; the 1-hour cache costs 2×, and it is the usual kind for Claude Code on a subscription (about 90% in our own logs). Cache reads cost 0.05× rather than 0.1× on Opus 5.5 and Sonnet 5.5. The price table on the help page also lacked the newest models and still called the Sonnet 5 price introductory. A user in the Obsidian forum pointed out the 1-hour cache in October, and we promised this correction for 2.1. Glossary, README and help now follow the official pricing page as of October 2026
Changed
- The Today ring is neutral grey. There is no daily limit, and green, amber and red next to two real limits read like a warning. A busy day is a change in how you work, not a risk. The dashboard panel names the multiple instead ("2.5x your usual day")
New
- Optional: limits anchored on the official percentages. Claude Code passes the official 5-hour and weekly percentages to any status line script. A small script shipped with this release (
extras/ratelimit-statusline.js) shows them in your status line and logs them on your machine. When that log exists, the 5-hour window starts when the official window starts, and both limit rings show exactly the official percentage at every reading, then count on with your tokens until the next one. Without the script nothing changes. Setup: see the help page, section "Official percentages from your status line", or the README section of the same name - Glossary entry "Today ring", and "What counts toward a limit" rewritten, in all five languages
- C.Write tooltip with the 1-hour and 5-minute split. Hover over any C.Write row to see how much of it was written for one hour and how much for five minutes. We looked at splitting the row itself and decided against it: the sidebar has no room for a fifth row, and the plugin does not compute costs
Known limits
- Between two readings the plugin adds input and output only. A cache rebuild (new chat, expired cache) appears with the next reading
- Archived days older than your retention window keep their old figures: the logs needed to recount them no longer exist. Days still inside the window are rewritten once after updating
- Whether 1-hour and 5-minute cache writes weigh differently on the limit is still open. In every segment we could measure, the cache writes were all of the 1-hour kind, so a separate weight for the 5-minute kind cannot be determined yet. We keep measuring