Claude Code usage in the macOS menu bar: the two-tier redraw that keeps the dropdown from snapping shut

ClaudeMeter. It is free, open-source (MIT), and lives at github.com/m13v/claude-meter. Install with brew install --cask m13v/tap/claude-meter, load the unpacked browser extension from the same repo, and the menu bar icon lights up within sixty seconds with two numbers: 5h percent and 7d percent. The numbers are pulled from /api/organizations/{org_uuid}/usage on claude.ai, the same endpoint claude.ai/settings/usage renders. It is the same server quota Anthropic actually checks before throwing a 429 on your next Claude Code prompt.

Because the menu bar is in the same field of view as your editor and terminal, but does not steal a row of your terminal. ccusage --watch and similar tools render a live updating row inside a terminal pane, which is fine until you tab to a different pane or your tmux split changes layout. The macOS menu bar sits above every Space, every full-screen app, and every workspace; the chip is in your peripheral vision while Claude Code is mid-edit. If you also want a status line, the same data is available via claude-meter --json on the CLI; you can wire it into Starship, tmux, or fish without losing the menu bar version.

No, and that is the part most home-built menu bar apps get wrong. ClaudeMeter splits the redraw into two tiers. The poll fires once a minute. The title repaint is cheap and runs on every numeric change. The 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 went stale, an account got forgotten. The branch lives at src/bin/menubar.rs lines 137-146. The comment on the same branch names the reason: 'Mid-flight percentage updates reach the user on their next click via title + re-render.' If you keep the dropdown open during a long Claude Code run, the percent in the title still ticks; the dropdown stays put.

ccusage and Claude-Code-Usage-Monitor read your local ~/.claude/projects JSONL files and total tokens per session. That is a faithful local-log signal for Claude Code traffic only. They cannot see the per-model weights, the peak-hour multiplier, the per-attachment cost, or any browser-chat usage Anthropic stacks into the same five_hour and seven_day buckets. ccusage at 5 percent next to claude.ai at 90 percent is a normal, predictable mismatch. ClaudeMeter shows the second number, the one Anthropic uses to decide whether to 429 your next prompt. ClaudeMeter does not replace ccusage; ccusage tells you what your Claude Code traffic weighed in tokens, ClaudeMeter tells you what fraction of the cap Anthropic counted that against. Both repos are linked at the bottom of this page.

Two percentages: 5h and 7d. Three formats configurable from the dropdown's 'Menu bar style' submenu (TitleFormat enum at src/bin/menubar.rs lines 22-31). Long is 'Claude 5h 47% · 7d 62%'. Medium is '5h 47% · 7d 62%'. Compact is '47 · 62'. Each percent is its own NSAttributedString segment so the background can be colored independently: bg_for at lines 942-950 paints RGB (215, 58, 73), saturated red, at >=100 percent; RGB (219, 118, 32), orange, at >=90 percent; no background below. With the dropdown closed, you read both numbers in your peripheral vision, and the orange flash at 90 is your tap on the shoulder.

Yes, and not by trusting a header. The menu bar app receives POSTs from the browser extension on 127.0.0.1:63762. To label which Chromium browser sent the snapshot, it asks the OS who owns the peer TCP socket: lsof -nP -iTCP:<port> -sTCP:ESTABLISHED returns the connected process, ps -o command= returns its executable path, and classify_browser_exe at src/bin/menubar.rs lines 464-477 maps '/google chrome.app/' to 'Chrome', '/arc.app/' to 'Arc', '/brave browser.app/' to 'Brave', and '/microsoft edge.app/' to 'Edge'. Sec-Ch-Ua headers are a fallback only, because Arc identifies as Chromium in many of those headers and would mislabel rows.

Each (browser, account_email) pair becomes its own snapshot. The menu bar then compresses them into one title. With one account, you see '5h 47% · 7d 62%'. With two, you see 'M: 5h 47% · 7d 62% P: 5h 30% · 7d 12%' where M and P are the first letter of each account email (account_tag at lines 952-958). The dropdown shows one submenu per account, labeled with the email and the browser. Mergewith_persisted at lines 840-895 keys snapshots by (browser, account) so a POST from Chrome does not disturb your Arc rows, and a stale row stays visible (with a 'stale' marker) for two hours after the last fetch.

No. set_macos_accessory at src/bin/menubar.rs lines 1116-1126 calls NSApplication::sharedApplication(mtm).setActivationPolicy(NSApplicationActivationPolicy::Accessory) before anything else. Accessory means the process has no Dock icon, no app menu, and no Cmd-Tab presence. The status item in the menu bar is the entire user surface. If you want to quit, the dropdown has a Quit row. If you want to launch it on login, the brew cask installs a launch agent so it comes back after reboot.

Every 60 seconds, but with a backoff. POLL_INTERVAL at line 18 is sixty seconds. BRIDGE_FRESHNESS at line 350 is 120 seconds. If the browser extension has POSTed a snapshot to the localhost bridge in the last 120 seconds, the poll loop skips the cookie-decrypt fetch entirely (lines 331-342). So in the common case, where you have the extension loaded and a browser open, the menu bar app does zero direct claude.ai requests; it just receives extension snapshots. If you close the browser, the cookie-decrypt path takes over after 120 seconds of bridge silence. One HTTPS request per minute either way.

Yes. The brew cask installs a CLI binary at /Applications/ClaudeMeter.app/Contents/MacOS/claude-meter. Run it with no flags for a human-readable block (format_window in src/format.rs lines 75-98 renders each window as 'X.X% used -> resets <local clock> (in Nh)'). Run with --json for the parsed UsageSnapshot as JSON. The localhost bridge is also a read endpoint: curl http://127.0.0.1:63762/snapshots returns whatever the menu bar last received. That is the hook for embedding the same number into a Starship prompt or tmux status line, alongside the menu bar.

Not supported yet. The menu bar app is macOS-only because the AppKit code path that paints the colored title segments (the macos_title module at lines 1128-1283 of src/bin/menubar.rs) is locked behind cfg(target_os = 'macos') and there is no cross-platform analogue for setAttributedTitle on a status item. The browser extension itself runs anywhere Chromium runs, and exposes the same snapshot at chrome.action.setBadgeText, but the tray-icon Linux/Windows fallback in tray-icon does not support per-segment background colors. Until that lands upstream, the macOS-only experience is what ships.

It reads what your browser is already storing, decrypts it with the key your browser already gave macOS, and never leaves the loopback interface. Specifically: Chrome's Safe Storage entry has an ACL that already trusts /usr/bin/security, so calling /usr/bin/security find-generic-password -wa Chrome -s 'Chrome Safe Storage' returns the AES key without a prompt. Arc, Brave, and Edge prompt once on first run because their ACLs do not list the security binary; click Always Allow once and the path runs silently afterward. The decrypted cookie is held in memory just long enough to fetch /api/organizations/{org_uuid}/usage and gets dropped. No telemetry, no analytics, no network egress beyond claude.ai itself. The bridge listens only on 127.0.0.1; the browser extension and the menu bar app are the only two processes that touch it.