Claude usage meter vs activity dashboard: two surfaces, two different questions

A meter is an ambient surface. It has one job: keep one or two numbers visible without you asking, so you notice them in your peripheral vision while you keep working. An activity dashboard is a deliberate surface. You stop what you are doing, open it in a tab, and read charts, breakdowns, history, costs, and per-session detail. Meters answer the in-the-moment question (should I keep prompting now?). Dashboards answer the retrospective question (where did my week go?). On Claude Pro and Max specifically, the meter saves you from the 5-hour wall and the dashboard tells you which model burned the most weekly compute.

Yes, claude.ai/settings/usage is the official surface, but it is not really a dashboard in the analytics sense. It renders the same /api/organizations/{org_uuid}/usage JSON ClaudeMeter polls, with two progress bars (5-hour, weekly) plus per-model rows on Max. There are no historical charts, no per-session breakdown, no costs. Anthropic's full analytics dashboard with charts and per-user attribution is gated to Team and Enterprise (support.claude.com/en/articles/12883420). For Pro and Max individuals, the activity dashboard surface is shallow on purpose and the meter pattern fills the gap.

Because the 5-hour wall hits without warning. By the time you remember to open the dashboard, you have already burned cycles to get there: switch to the browser, find the tab, wait for the page to load, read the bars. A menu bar chip is in the same field of view as your editor and your terminal at all times. ClaudeMeter polls every sixty seconds (POLL_INTERVAL at src/bin/menubar.rs line 18, POLL_MINUTES at extension/background.js line 3) and the title is colored bg_for at lines 942-950 with RGB (215, 58, 73) at 100 percent and RGB (219, 118, 32) at 90 percent. The orange flash at 90 is the tap on the shoulder you do not get from a dashboard you have to remember to open.

It can auto-refresh, but the UX is still a dashboard's UX. The phuryn/claude-usage local dashboard refreshes every 30 seconds and renders Chart.js charts of token usage; that is a dashboard with a polling job, not a meter. The reason it does not become a meter is that you have to keep its tab focused or visible on a second monitor for the live updates to enter your visual field. A meter does the opposite work: it lives in a place you cannot help but see (the macOS menu bar, the toolbar of the browser you are already in), and it shows the absolute minimum number of bytes (two percentages, one color) so glancing is cheap. You glance at a meter. You visit a dashboard.

Not in ClaudeMeter, and that is the part most home-built menu bar apps get wrong. The redraw is split into two tiers. The poll fires once a minute. The title repaint is cheap and runs on every numeric change. The full menu rebuild is expensive (it tears down and re-attaches the submenu tree, which dismisses an open dropdown) and only runs when the account set changes: a new email logged in, an account flipped stale, an account got forgotten. The branch lives at src/bin/menubar.rs lines 136-146. The comment names the reason: "Mid-flight percentage updates reach the user on their next click via title + re-render." If you keep the dropdown open through a long agentic loop, the percent in the title still ticks; the dropdown stays put.

Both walk ~/.claude/projects/*.jsonl on your local disk and total input_tokens + output_tokens for sessions on this machine. That is a faithful local-log signal for Claude Code traffic only. Neither sees per-model weighting on the seven_day_opus and seven_day_sonnet sub-buckets, the peak-hour multiplier on the rolling 5-hour bucket, or browser-chat usage that depletes the same caps but never writes to ~/.claude/projects. ccusage at five percent of estimated spend while claude.ai shows ninety percent of the rolling window is a frequent, normal mismatch. Run ccusage as a cost-attribution dashboard and ClaudeMeter as the meter that reflects what Anthropic actually checks before throwing a 429.

Because the dashboard already has the cookie. When you open claude.ai/settings/usage, the browser sends your session cookie automatically and the page renders. A separate native menu bar app does not have access to that cookie. Without help, it would have to either ask you to paste your cookie manually (which Anthropic-Claude-Code-Usage-Monitor and similar tools do) or decrypt Chromium's cookie store via Apple Keychain (which works but is fragile across browser updates). The ClaudeMeter browser extension solves it the lazy way: it makes the same fetch your browser already makes for the settings page, then POSTs the JSON to localhost:63762 where the menu bar app picks it up. Same data the dashboard gets, no manual paste step.

If you spend more than two hours a day in Claude Code on Max, both. The meter pins you to the moment so you do not start a sixty-prompt Opus refactor with the weekly Opus sub-bucket already at 91 percent. The dashboard (claude.ai/settings/usage plus ccusage if you also care about cost per pull request) is where you go on Friday afternoon to figure out which model class burned your week and whether to switch to Sonnet for the next sprint. They are complementary, not redundant. The meter is read-only ambient awareness, the dashboard is investigative.

Less, in the steady-state case. ClaudeMeter polls once a minute; that is one HTTPS request per sixty seconds against claude.ai. When the browser extension is running, BRIDGE_FRESHNESS at src/bin/menubar.rs line 350 is set to 120 seconds: if the extension has POSTed a snapshot in the last two minutes, the menu bar app skips the cookie-decrypt fetch entirely and just receives the extension's snapshot. So in practice the meter is one HTTPS request per minute total, not one per surface. A dashboard tab loaded in the foreground often refreshes more aggressively and burns more on rendering charts than the meter does on polling JSON.

Yes, MIT licensed, github.com/m13v/claude-meter. The Rust core, the menu bar binary at src/bin/menubar.rs, and the browser extension under extension/ are all readable. There is no telemetry: no analytics, no crash reporting, no third-party SDK. The only network call is your one-per-minute HTTPS request to claude.ai using the session cookie that is already in your browser, and the localhost POST from the extension to 127.0.0.1:63762 that never leaves the loopback interface.