A Claude Pro usage meter your browser automation loop can actually read mid-run

ClaudeMeter. It is free, MIT-licensed, macOS-only, and ships with a CLI binary at /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter. The reason it fits browser automation specifically is the --json flag: claude-meter --json prints a Vec<UsageSnapshot> to stdout, with named fields five_hour.utilization, seven_day.utilization, seven_day_oauth_apps.utilization, and extra_usage.used_credits. Those are the same percentages that claude.ai/settings/usage renders. A Playwright, Computer Use, or Claude Code loop can shell out to claude-meter --json once per iteration and decide whether to keep going. ccusage and Claude-Code-Usage-Monitor cannot do this; they read ~/.claude/projects JSONL files, which is local-token estimation, not the server-side bucket Anthropic actually enforces against agentic loops.

Because ccusage measures a different signal. It tails ~/.claude/projects JSONL files and totals tokens per session. That is faithful for what your local Claude Code traffic weighed in tokens, but Anthropic's per-org rolling 5-hour window and the seven_day_oauth_apps weekly bucket are computed server-side, with peak-hour multipliers, per-model weights, and any browser-chat usage on the same account stacked into the same buckets. ccusage at 5 percent and claude.ai at 90 percent is the predictable mismatch. The 429 fires off the server number, so an automation loop guard has to read the server number. ClaudeMeter pulls it from /api/organizations/{org_uuid}/usage on claude.ai, which is the same endpoint the settings page uses.

No. The browser extension lives at extension/background.js in the m13v/claude-meter repo. It uses chrome.alarms to fire a refresh job every periodInMinutes: 1, and its fetch call passes credentials: 'include' against https://claude.ai/api/account, then /api/organizations/{org}/usage, /api/organizations/{org}/overage_spend_limit, and /api/organizations/{org}/subscription_details for each membership. Because the extension runs inside Chrome (or Arc, Brave, Edge), the request reuses the session cookie your browser already holds. There is no cookie paste, no API key, no service account. Load the unpacked extension once, visit claude.ai once, and the menu bar plus the localhost bridge start receiving snapshots inside sixty seconds.

An array of UsageSnapshot objects, one per (browser, account_email) pair. Each snapshot has org_uuid, browser, account_email, fetched_at, an errors array, and three optional sub-objects: usage (with five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork as Window structs of {utilization, resets_at}, plus extra_usage as {is_enabled, monthly_limit, used_credits, utilization, currency}), overage (the pay-as-you-go pool details), and subscription (status, next_charge_date, billing_interval). Pipe it into jq, ingest it into a Python loop, parse it in a Rust agent, whatever you want. Schema is in the public source at src/models.rs in the m13v/claude-meter repo.

Two of them, depending on what you are protecting against. five_hour.utilization is the rolling 5-hour window, which is the wall an agentic browser-control loop hits within minutes if you are running Computer Use or a Playwright-driven Claude Code session in tight iteration. seven_day_oauth_apps.utilization is the agentic-loop-specific weekly bucket Anthropic added in 2026; it tracks Claude Code and other OAuth-app traffic separately from your claude.ai web chat. In practice, gate on whichever is higher. If five_hour goes past 80 percent, sleep until five_hour.resets_at. If seven_day_oauth_apps goes past 80 percent, the loop is going to die in a day or two regardless; queue the remaining work or switch to Sonnet for the rest of the week.

Two paths. Easy path: claude-meter --json runs in well under one second on a warm cookie cache, so spawning it once per loop iteration is fine for any iteration cadence above a few seconds. Faster path: the menu bar app exposes a localhost bridge at 127.0.0.1:63762. The browser extension POSTs the same Vec<UsageSnapshot> to it every minute (extension/background.js BRIDGE constant on line 2). The bridge is POST-only by design (request handler at src/bin/menubar.rs lines 372-388 returns 404 to anything else), so reading from your script means tapping the same /api/organizations/{org}/usage endpoint yourself with the cookies the extension is already collecting, or sticking with the CLI. The CLI is the intended programmatic surface.

Yes. extra_usage.used_credits in the JSON output is the dollar amount your account has accrued past the included plan quota, in the currency reported by extra_usage.currency, governed by extra_usage.monthly_limit. If your loop guard cares about real money rather than utilization fraction, key on used_credits crossing whatever ceiling you set. The overage block adds the disabled-reason and disabled-until fields, which is what tells you Anthropic has frozen extra-usage on your account (out_of_credits true means new prompts are blocked even if your five-hour bucket is fine). Both blocks come from /api/organizations/{org}/overage_spend_limit on claude.ai, exposed unchanged in the snapshot.

No. Each (browser, account_email) pair is its own snapshot row. The menu bar app identifies the sending browser by looking up the peer TCP socket's owning process, not by trusting Sec-Ch-Ua headers (which Arc, Brave, and Edge set to Chromium). So if your automation runs three Chromium-family browsers in parallel against the same Claude account, you see three rows, each labeled by the actual binary, all reading the same per-account quota. dedupe_by_account in the CLI then collapses snapshots that belong to the same Claude account before printing, so claude-meter --json gives you one snapshot per account regardless of how many browser tabs were involved in fetching it.

Not supported yet on the menu bar app side. The macOS-only constraint comes from the AppKit code path that paints the colored title segments, which has no cross-platform analogue. The browser extension itself runs in any Chromium browser on any OS and exposes the same usage snapshots via chrome.storage.local; if you have a Linux or Windows automation runner, you can read those snapshots in the extension context (or call the same /api/organizations/{org}/usage endpoint directly with whatever HTTP client your runner has, using the session cookie from the running profile). The CLI loop-guard pattern in this guide is macOS-specific; the underlying server-truth idea is portable.

No outbound network egress beyond claude.ai itself. The bridge listens only on 127.0.0.1, the request fires once per minute (or once per loop iteration if you call the CLI), and there is no telemetry, no analytics endpoint, no third-party SDK in the binary. Source is MIT at github.com/m13v/claude-meter and the pieces a curious reviewer cares about are small: extension/background.js for the fetcher, src/api.rs for the parsed response, src/models.rs for the snapshot schema, src/bin/menubar.rs for the bridge.

No. Nothing fixes it; Anthropic enforces the buckets server-side and an agentic loop is exactly the workload that fills them fastest. What this fixes is the visibility gap. Without a meter, a browser automation script runs blind and gets cut off by a 429 mid-iteration, often deep into a multi-step task. With a loop guard reading claude-meter --json, the script knows its own state and can sleep until resets_at, switch to a cheaper model for the remaining iterations, or queue the remaining work for a future window. That is what 'meter for browser automation' actually means in practice: a feedback signal the loop can act on.