Server quota is a fraction with a private denominator. Your token counter can't see it.

Because the server expresses quota as utilization, a dimensionless fraction, not a token count. In /src/models.rs the Window struct has exactly two fields: utilization: f64 and resets_at: Option<DateTime<Utc>>. There is no tokens_used field. The denominator Anthropic divides by (your plan's effective ceiling for that bucket, at that moment, under the current weighting) is not returned on the wire and is not published. A local counter can tell you 'I sent 1.4M input tokens this session' but cannot convert that into utilization because the denominator is private. The only way to know your server-side utilization is to read the server's own number.

Three endpoints, all under /api/organizations/{org_uuid}/, called with your existing claude.ai session cookie: /usage returns utilization and resets_at per rolling bucket, /overage_spend_limit returns metered dollars used against a monthly cap, and /subscription_details returns next_charge_date and payment method. You can see the exact calls in src/api.rs lines 16-60 of the Rust binary and in extension/background.js lines 24-29 of the browser extension. Both parse the same JSON into the same Rust structs defined in src/models.rs.

The server is inconsistent and the extension handles both shapes. In extension/background.js lines 58-63 the helper pctFromWindow does: const u = w.utilization; return u <= 1 ? u * 100 : u. So a value of 0.97 means 97 percent, and a value of 97 also means 97 percent. This matters if you write your own caller: do not assume one or the other, branch on <= 1. The Rust side stores utilization: f64 and prints '{:>5.1}%' directly, which works because downstream code expects already-scaled percents from the CLI formatter.

They read the local JSONL transcript on disk and sum tokens. That sum is an accurate numerator. It is not utilization. For one thing, not every token on disk was chargeable against every bucket (the per-bucket weightings are invisible to the client). For another, server-side adjustments from before you started logging, from other devices on the same account, or from OAuth app traffic never appear in your local files. A token counter is an answer to 'how much did my session cost locally'. It is not an answer to 'am I about to be rate-limited by claude.ai'.

No. platform.claude.com's Usage and Cost API is for Console API customers and returns spend broken down by workspace and model for paid API usage. Claude Pro and Max plans ship through claude.ai with different quota semantics (rolling windows, bucketed weights, extra-usage credit on top). The claude.ai/settings/usage page renders from /api/organizations/{uuid}/usage, which is a different, undocumented endpoint on a different host, returning utilization fractions rather than token or dollar counts. claude-meter targets that endpoint specifically because it is what the product itself uses.

Stable enough that the shape has not changed through 2026-04-24, but Anthropic can and occasionally does rename fields on deploys. The mitigation is that ClaudeMeter is open source (MIT) and deserializes into a strongly typed struct. If a field is renamed, serde fails loudly on the next poll and the error bubbles to the menu bar as '!' with the parse message. You would see the break in one git diff of src/models.rs rather than in a silently wrong number.

With the browser extension route, no. The extension runs inside Chrome (or Arc, Brave, Edge) and calls the endpoint with credentials: 'include', which reuses your already-logged-in claude.ai session automatically. With the menu-bar-only route, the app reads Chrome Safe Storage via keychain and decrypts the session cookie on your machine. No cookie value ever leaves localhost. Both routes match the byte-for-byte view the settings page renders.

Because utilization slides. The rolling windows recompute continuously on the server: as old traffic ages out, the denominator effectively shifts, and utilization drifts even without any new messages. Sampling every 60 seconds matches the temporal resolution a human can act on and is below the rate at which the number typically changes in a heavy session. POLL_MINUTES = 1 in extension/background.js line 3.

For each rolling bucket, a Window object with utilization: f64 (the fraction) and resets_at: Option<DateTime<Utc>> (when this bucket's oldest charged traffic ages out of the window). There are seven such buckets in the UsageResponse struct: five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork. No token integers, no message counts, no dollar amounts on this endpoint. The dollar numbers live on the companion /overage_spend_limit endpoint and are for metered billing only.

Those headers are on API responses, not claude.ai responses. They give you the most restrictive currently-active API rate limit (tokens per minute, requests per minute, input tokens remaining). They do not expose the rolling 5-hour or 7-day consumer-plan utilization. The consumer plan's utilization is returned only by the private /api/organizations/{uuid}/usage endpoint. Different surface, different contract, not interchangeable.

Only indirectly, and only for a fixed workload held constant. If you send a known set of messages across a fresh window and watch utilization climb, you can estimate the tokens-per-percent ratio for that bucket during that hour. That ratio is not constant across buckets, across models, or across weekday peaks. We saw it change after the 2026-03-26 server-side tightening. Any tool pretending to publish 'your remaining tokens' by inverting utilization is guessing.

Because the settings page does not stay open and does not alert when you approach a limit. ClaudeMeter runs in the menu bar, refreshes every 60 seconds, and color-codes the badge (green under 80 percent, amber 80 to 100, red at 100). The underlying data is identical; the ergonomics are different. If you want the raw number in a terminal, the same binary ships a CLI: /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter --json.