The Claude weekly quota server-truth meter, and why its number cannot disagree with claude.ai

Anthropic's per-organization usage endpoint, served from claude.ai under the path /api/organizations/[org_uuid]/usage. That is the JSON the /settings/usage page renders into the bars and percentages you can already see in your browser. ClaudeMeter calls the same URL with your existing claude.ai session cookie and parses the response into the Window struct in src/models.rs lines 4-7 of github.com/m13v/claude-meter. Two fields: utilization: f64 and resets_at: Option<DateTime<Utc>>. Nothing else; there is no other source of weekly truth on the wire.

They sum input/output tokens from ~/.claude/projects/*.jsonl. The numerator is real. The denominator is not on disk. Anthropic's plan caps are expressed as utilization (a dimensionless fraction the server computes against a private weighting) and the local logs do not include the weighting, the per-model multipliers, or the rolling-window arithmetic. So a local counter at 5% can perfectly coexist with a server response of seven_day.utilization = 0.91. Both are honest about different things; only one of them will rate-limit you. ClaudeMeter sits next to ccusage, not against it.

Because that is what your browser sends when you reload the settings page. Look at src/api.rs line 126 of the open-source repo. The Rust client sets exactly three headers on each GET: Cookie (your session), Referer (the settings URL), and Accept: */*. Cloudflare's bot heuristics see a request that is byte-identical to a tab reload, so the response is byte-identical too. The meter is impersonating your own browser, not consuming a 'tracker API' that does not exist.

60 seconds when you have ClaudeMeter running with the browser extension. The extension's chrome.alarms job is set to POLL_MINUTES = 1 in extension/background.js line 3, fetches /usage, and POSTs the snapshot to the menu-bar app at http://127.0.0.1:63762/snapshots. If you cross 80 percent on any window, the menu-bar app's HIGH_UTIL_FAST_POLL kicks in (src/bin/menubar.rs line 34) and POLL_MIN drops the cadence to 90 seconds (line 29) so the bar reflects burn while you are at the wall.

Brew install --cask m13v/tap/claude-meter and accept the macOS keychain prompt for 'Chrome Safe Storage'. The menu-bar app reads Chromium's encrypted cookie file directly and runs the same call itself. This is documented in the README under Route B. The trade-off is the prompt is broad (Chrome's master key covers cookies, saved passwords, and credit cards) and only Chromium-family browsers are supported on this path. The extension route avoids the prompt entirely.

Only at the seam. If the server returns an updated utilization at second 31 of the minute, the next poll happens at second 60, so for 29 seconds the menu bar is stale. The popover dropdown shows fetched_at at the bottom so you can see exactly how old the number is. The two NEVER disagree on the calculation itself, only on freshness; both numbers came from the same payload, computed once on Anthropic's side.

Yes. The shape is below. You need a session cookie from claude.ai (open DevTools, copy the Cookie header from any /api/organizations/.../usage call in the Network tab) and the org UUID (it is in the URL of any settings page). A one-line curl plus jq prints the exact same utilization the bar would render. ClaudeMeter exists because doing that on a 60-second loop, across multiple orgs, while watching for the worst bucket, while not paying telemetry to a third party, is the actual work.

Free, MIT licensed, github.com/m13v/claude-meter. Network egress: one HTTPS request per minute to claude.ai per org membership and (when present) one to the same host's /api/organizations/{org}/overage_spend_limit and /subscription_details endpoints. No analytics ping, no auth server, no cloud account. The bridge between the extension and the menu bar is bound to 127.0.0.1:63762; nothing on your network can reach it. Audit src/api.rs (142 lines) and extension/background.js (121 lines) before you trust me.