A silent tightening tracker is a list of six capabilities. Here is the list.

Because it reads ~/.claude/projects/*.jsonl files and counts tokens. Silent tightening does not change the number of tokens your message consumes; it changes the server-side weight the backend applies to those tokens when it charges the five_hour and seven_day buckets. Tokens in the log look identical before and after. The only place the new weight shows up is in the JSON response at /api/organizations/{org_uuid}/usage, which no local-log tool fetches.

Six: (1) hits /api/organizations/{org_uuid}/usage directly rather than estimating from local logs, (2) polls on at least a 60-second cadence so slope changes show up as slopes instead of staircases, (3) reads all seven rolling buckets, not just the headline two, (4) normalizes the 0-1 vs 0-100 utilization field which ships both scales in the same response, (5) logs raw JSON per sample so you can diff a schema change later, and (6) runs in the background so an idle user still captures the weekday 13:00 UTC knee. ClaudeMeter checks all six.

five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork. They are declared as explicit Option<Window> fields in ClaudeMeter's Rust struct at src/models.rs lines 18-28. Each ships a utilization number and its own resets_at. Anthropic documents two of them (five_hour and seven_day). The other five silently appeared in the payload and still work the same way.

Once per 60 seconds. The Chrome extension calls chrome.alarms.create("refresh", { periodInMinutes: 1 }) in extension/background.js. Anything slower than a minute turns the slope change at 13:00 UTC weekdays into a staircase of samples and you lose the knee in the curve. Anything faster would be pointless because Anthropic's own Settings page does not recompute the five_hour bucket any faster than that, and you would be hammering the endpoint for no new data.

Not with the extension route. The Chrome extension fetches /api/organizations/{org}/usage with credentials: "include", so your existing claude.ai session cookie is used automatically. The other route, the menu bar binary alone, reads Chrome's Safe Storage via keychain. Either way, no cookie paste and no second login.

It means the change lands without touching the HTML of claude.ai/settings/usage or any public documentation. The bar on Settings keeps looking the same. The fields in the endpoint payload keep the same names. Only the relationship between your workload and the utilization numbers shifts. If your detector depends on Anthropic telling you something changed, you cannot see it until someone on Reddit notices their five_hour bucket filling twice as fast during weekday afternoons.

Not without adding a completely new data source. Both tools are fundamentally log-scanners. Their signal is what Claude Code wrote to the local filesystem. To catch silent tightening you need to add an HTTP client, a session cookie plumbing, and a schema for the /usage response. At that point you have rewritten the hard part of ClaudeMeter. A simpler path is to run both together and read ClaudeMeter for server truth, your existing tool for local token accounting.

Because a typed struct rejects unknown-but-important drift louder than a generic HashMap would. UsageResponse in src/models.rs has five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork as distinct fields. If Anthropic renames one or adds an eighth, the deserializer surfaces that shape change as a loud error instead of silently mapping it into a missing key that goes unplotted. That loud failure is how you catch the next silent schema change early.

It is the same endpoint claude.ai/settings/usage polls when you reload that page. You are asking for your own org's usage with your own session cookie. No undocumented behavior, just a JSON GET. That said, the endpoint is undocumented and Anthropic can change the field names or cadence limits without notice. ClaudeMeter is open source (MIT), so if the endpoint shape changes, you can see exactly what moved and why in the src/models.rs diff.

The 2026-03-26 change. The seven_day bucket stayed flat across a fixed 50-message Sonnet workload. The five_hour bucket climbed 1.4x to 2x faster on weekdays 13:00-19:00 UTC on the same workload. Both deltas came straight from the /api/organizations/{org}/usage response, polled every 60 seconds before and after the boundary. The per-model seven_day_sonnet and seven_day_opus buckets did not move.