Open source Claude usage trackers, April 2026: sorted by what they actually read.
Most public roundups list seven trackers in a table and grade them on icons and dark mode. The thing that actually matters is which ones read your local ~/.claude/projects/*.jsonl files (a numerator, useful) and which ones read the same private endpoint claude.ai/settings/usage renders from (utilization, what a 429 enforces against). Inside the server-truth camp, the next question is the cookie ceremony you accept on first run. This guide walks both.
The split that matters and the one that doesn't
A Claude usage tracker either reads what you sent (a number you can compute from disk) or what Anthropic counted against your plan (a number only the server knows). The first is a numerator. The second is a fraction whose denominator the server keeps private and adjusts on its own deploys. They look like the same number until you hit 100 percent on the settings page while your local count is showing 1.4M tokens, and then it becomes obvious they were answering different questions all along.
Every roundup currently published treats this as a footnote, lists seven trackers in a flat table, and grades them on UI. So this guide starts there: what does each tool read, and what is the cost of getting that number into your menu bar.
The seven trackers, one card each
Each card names what the tool reads and what it asks of you. The local readers are honest local readers; the server readers are honest server readers; the cookie ceremony differs.
ccusage
Reads ~/.claude/projects/*.jsonl and prints a summary in the terminal. Pure local. Answers 'how many tokens did this machine send', not 'where am I against my plan'. No cookie, no network egress, runs anywhere Node runs.
Claude-Code-Usage-Monitor (Maciek)
Python TUI that polls the same JSONL and renders a live dashboard with predictions and burn-rate. Local-only. The predictions are extrapolations of your token rate, not the server's actual ceiling.
phuryn/claude-usage
Local Python web dashboard. Scans ~/.claude/projects, builds a SQLite index, and serves charts on localhost. Deepest historical view of any local tracker. Still does not see server utilization.
ClaudeUsageBar
macOS menu bar, MIT, server-endpoint reader. Setup asks you to open DevTools at claude.ai/settings/usage, find the /usage request, and paste the entire Cookie header into 'Set Session Cookie'. Refreshing the cookie when it rotates is on you.
hamed-elfayome/Claude-Usage-Tracker
Swift menu bar app, three auth modes: Claude Code CLI keychain, embedded WKWebView sign-in (extracts sessionKey for you), or paste a sk-ant-sid01- key by hand. macOS 14+ only.
lugia19/Claude-Usage-Extension
Chrome and Firefox extension that instruments the chat UI. Hooks the SSE message_limit stream and breaks usage down per file/project. Killer feature: shows what fraction of your context window each attachment eats. No menu bar, no CLI.
ClaudeMeter
Two surfaces: a Manifest V3 Chrome extension that calls /api/organizations/{org}/usage with credentials: 'include' (no cookie paste, ever), and a macOS menu bar app that reads the snapshot off a localhost bridge at 127.0.0.1:63762. Multi-browser, multi-org, MIT.
Setup, surfaces, and what each tracker actually sees
ccusage, Maciek's monitor, and phuryn's dashboard share the local-log row almost identically. The interesting differences are in the server-truth half: cookie paste vs embedded webview vs credentials-include.
| Feature | The other six trackers, by row | ClaudeMeter |
|---|---|---|
| Reads server-enforced utilization (matches /settings/usage) | ccusage / Maciek / phuryn: No. ClaudeUsageBar / hamed / lugia19: Yes. | Yes. Calls the same private endpoint /settings/usage renders from. |
| Setup: cookie paste required | ccusage / Maciek / phuryn: N/A (local). ClaudeUsageBar: Yes, manual paste. hamed: Yes, paste OR embedded webview. lugia19: No (runs in browser). | No. credentials: 'include' on fetch reuses Chrome's existing claude.ai session. |
| Surface: menu bar app | ccusage: No. Maciek: No. phuryn: No. ClaudeUsageBar: Yes. hamed: Yes. lugia19: No. | Yes. Free macOS menu bar binary, brew install --cask m13v/tap/claude-meter. |
| Surface: real browser extension | ccusage / Maciek / phuryn / ClaudeUsageBar / hamed: No. lugia19: Yes (DOM/SSE). | Yes. Manifest V3 extension that hits the JSON endpoint, not the DOM. |
| Multi-org on the same account | Local readers: only what your local logs cover. ClaudeUsageBar / hamed: one cookie at a time. lugia19: per active org. | Yes. Iterates account.memberships and polls /usage for every org. |
| Multi-browser (Chrome, Arc, Brave, Edge) | Local readers: irrelevant. ClaudeUsageBar / hamed: cookies from one browser at a time. lugia19: one extension per browser. | Yes. The menu bar app identifies each browser by the POST's TCP peer process. |
| Telemetry sent to third parties | All seven: none claimed. | None. Bridge binds 127.0.0.1:63762; no external host besides claude.ai itself. |
| License | ccusage / Maciek / phuryn / ClaudeUsageBar / hamed / lugia19: open source (mostly MIT). | MIT. |
| Linux / Windows | Local readers: yes. lugia19: yes via browser. ClaudeUsageBar / hamed: macOS only. | macOS only today. Linux/Windows not on the roadmap. |
The anchor fact: 0 option in 0 fetch call
The reason the ClaudeMeter extension never asks for a cookie is one word in one option bag. Manifest V3 lets a service worker make credentialed fetches to any host listed in host_permissions using the cookies the user's browser already stores for that origin. The whole helper is seven lines, and the relevant option is on line 7.
Combined with the manifest below, the extension can read claude.ai and write to your localhost bridge, and nothing else. There is no surface to copy a cookie into because there is no need.
What that buys you on first run
The cookie-paste route exists because most desktop apps cannot read your browser's cookie jar without macOS asking for the entire Chrome Safe Storage keychain entry (which also covers saved passwords and credit cards). So tools that go that route either swallow that prompt or ask you to paste the cookie out by hand. A real Manifest V3 extension does not have that problem because it runs inside the browser, with the same origin gate Chrome itself uses.
How the cookie actually reaches the endpoint
One arrow on the left, one cookie, one localhost bridge
The cookie never leaves Chrome's cookie jar. The extension asks Chrome to attach it on outgoing requests to claude.ai. The snapshot ends up on a localhost socket the menu bar app reads.
Cookie-paste route, step by step
What ClaudeUsageBar (and most paste-route tools) ask of you
This is fine, until the cookie rotates. Then you do it again.
Extension route, step by step
What ClaudeMeter's MV3 extension asks of you
The extension never sees the raw cookie value; Chrome does. When the cookie rotates, your browser handles it, and the next 60-second poll just works.
A five-question decision flow
Do you need to know your server-enforced utilization, or just how many tokens you sent on this machine?
If the answer is 'just tokens on this machine', you want a local-log reader and the rest of the buyer's-guide section is moot. ccusage is the simplest, claude-monitor adds a TUI with predictions, phuryn's tool gives you the deepest historical view. None of them call claude.ai.
If you need server truth, are you on macOS?
If yes, you want a menu bar surface so the number is in your face. The macOS choices are ClaudeUsageBar (cookie paste), hamed-elfayome's tracker (embedded webview or paste), and ClaudeMeter (extension reuses your existing browser cookie via credentials: 'include').
Are you willing to copy a Cookie header out of DevTools every time it rotates?
If yes, ClaudeUsageBar is the simplest. If no, you want either an embedded webview (hamed-elfayome) or a real browser extension that piggybacks on your live session (ClaudeMeter). The webview path means re-signing into Claude inside the app; the extension path means pinning the icon and forgetting it exists.
Do you use more than one Chromium browser for Claude?
If you split work and personal across Chrome and Arc (or Brave, Edge), the menu bar app you want has to identify which browser each snapshot came from. ClaudeMeter labels each snapshot by looking up the owning process of the bridge POST's TCP peer; ClaudeUsageBar and the others handle one cookie at a time.
Do you want context-window forensics inside the chat UI itself?
That is lugia19's lane. Her extension reads the SSE message_limit stream and breaks usage down per project file. It is complementary to a menu bar tool, not a substitute. Many people end up running both.
Honest tradeoffs to know before you install anything
Every server-truth tracker on this list reads an undocumented claude.ai endpoint. Anthropic can rename a field on a deploy and break every parser at once. ClaudeMeter mitigates by deserialising into a strongly typed Rust struct (src/models.rs), so the break shows up as a loud parse error in the menu bar instead of a silently wrong number; lugia19's extension is similarly verbose. Local-log readers have the opposite tradeoff: they will never break from an Anthropic deploy, but they will quietly drift from server reality.
The ClaudeMeter macOS app is macOS-only and the maintainer has said Linux/Windows aren't planned. Safari cookies (.binarycookies under Full Disk Access) are not supported. None of the server-truth tools have a published SLA from Anthropic; they all rely on the same private endpoint and the same Referer-must-match check.
And no tracker can recover the denominator. The denominator shifted on the 2026-03-26 server-side tightening, which moved many users from comfortable to throttled without anyone changing their behaviour. Read the post on that day for the receipts. The same shift would not have been visible from any local-log tool at all.
Try the route that skips the cookie ceremony
ClaudeMeter is free, MIT, and the menu bar binary plus the Chrome extension take about three minutes total to install. The extension does not ask for a sessionKey. If you also want lugia19's per-file context-window breakdown, run both; they don't conflict.
Install ClaudeMeterStuck deciding between local-log and server-truth?
Bring your workflow and we'll walk through which tracker (or pair of trackers) covers the question you actually have.
Frequently asked questions
What does 'open source Claude usage tracker' mean? Aren't they all just hitting the API?
No. There are two completely different families. Local-log readers walk the JSONL transcript files Claude Code writes to ~/.claude/projects and sum tokens. Server-truth readers call the private endpoint at https://claude.ai/api/organizations/{org_uuid}/usage that the claude.ai/settings/usage page itself renders from. The first kind tells you 'how many tokens did this device send'; the second kind tells you 'what fraction of my plan ceiling has Anthropic counted', which is the only number a 429 enforces against. Both are useful. They are not interchangeable, and most public roundups don't draw the line.
Why is the cookie-paste step a real problem?
Because the private claude.ai endpoint authenticates via your normal session cookie. To read it from a non-browser process, you have to deliver that cookie. ClaudeUsageBar tells you to open DevTools at claude.ai/settings/usage, find the /usage request in the Network tab, and copy the entire Cookie header into a text field. hamed-elfayome's tracker offers an embedded WKWebView so you sign into claude.ai inside the app and the app extracts the sessionKey for you. Either way, the cookie is now sitting in another process that has to refresh it on its own when claude.ai rotates the session. A real Manifest V3 extension running inside Chrome can simply set credentials: 'include' on its fetch call and reuse whatever cookie Chrome is already storing for claude.ai. No copy, no paste, no rotation handling.
Which tools read local logs and which read the server endpoint?
Local logs (numerator only): ccusage, Maciek-roboblog/Claude-Code-Usage-Monitor, phuryn/claude-usage. They look at ~/.claude/projects/*.jsonl and sum inputTokens + outputTokens. Server endpoint (utilization): ClaudeUsageBar (cookie paste), hamed-elfayome/Claude-Usage-Tracker (embedded webview or manual key), lugia19/Claude-Usage-Extension (Chrome extension reading the live SSE message_limit stream from the chat UI), and ClaudeMeter (Manifest V3 extension calling /api/organizations/{org}/usage with credentials: 'include', plus a menu bar bridge). The Chrome Web Store extension labelled simply 'Claude Usage Tracker' that doesn't link a GitHub source belongs to lugia19; her code is at github.com/lugia19/Claude-Usage-Extension.
What makes ClaudeMeter different from lugia19's Chrome extension if both are Manifest V3?
Lugia19's extension instruments the claude.ai chat interface itself, watching the SSE stream and counting attachments per project. It is excellent for 'what is eating my context window', and the breakdown by source is genuinely the killer feature in that lane. It does not ship a desktop surface or a CLI; you check it from the toolbar popup. ClaudeMeter ships three surfaces: the extension popup, a macOS menu bar app, and a CLI binary that prints --json. The extension's only job is to reuse your session cookie to call /api/organizations/{org}/usage and POST the snapshot to a localhost bridge at 127.0.0.1:63762. The menu bar app reads from that bridge and identifies which browser sent each POST by looking up the peer TCP socket's owning process, so multi-browser users get correct labels. Both projects are MIT and they cover different jobs, not the same job.
If I'm only on Pro, do I really need a tracker?
If you ever hit a 5-hour or 7-day cap mid-session, yes, because the settings page does not stay open and does not warn you as you approach a limit. The rolling 5-hour window starts the moment you send your first message and slides continuously, so 'how much have I burned in this window' is not something you can compute from a wall clock. Pro and Max both surface the same seven Window fields (five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) on /api/organizations/{org}/usage; the difference is the denominator, not the shape.
Can I just curl the endpoint and not install anything?
Yes, and it is a useful sanity check. Grab your full Cookie header from claude.ai DevTools, get your org UUID from /api/account memberships[0].organization.uuid, and run: curl -s https://claude.ai/api/organizations/$ORG/usage -H "Cookie: $COOKIE" -H "Referer: https://claude.ai/settings/usage". The Referer header is load-bearing; drop it and you get 403. You will see the same shape every server-truth tracker parses: seven Window objects, each with a utilization fraction (0..1 or 0..100, branch on <=1) and a resets_at timestamp. The reason a tool is worth installing is that this curl gives you one snapshot; the server's denominator slides as old traffic ages out, so utilization drifts even with zero new messages and you want a poller.
What about the anthropic-ratelimit-* HTTP headers?
Those are on api.anthropic.com responses, not claude.ai responses. They expose API tier rate limits (tokens per minute, requests per minute, input tokens remaining) for paid Console API customers. They do not expose the 5-hour or 7-day consumer-plan utilization. The consumer plan uses an entirely separate undocumented endpoint, and that endpoint is what every server-truth tool listed here actually calls.
Is the menu bar route worth it if I'm a Linux or Windows user?
Today, no, ClaudeMeter is macOS-only and the maintainer has said Linux and Windows aren't planned. If you want a server-truth read on Linux or Windows in 2026, your best open source options are lugia19's Chrome extension (cross-platform via the browser) or running curl in a script and parsing the JSON yourself. Local-log readers (ccusage, claude-monitor) work everywhere because they only touch files.
How do these tools handle multiple Claude organizations on one account?
Most don't. ClaudeMeter does, because the extension iterates account.memberships from /api/account and polls /usage for every org in the list. Local-log readers don't see the concept at all because their input is per-machine transcripts. Cookie-paste tools (ClaudeUsageBar) follow the cookie's lastActiveOrg and you would have to switch active org in claude.ai and re-paste to see another one. If you split a personal Pro plan and a work Team plan on the same Google sign-in, this matters.
Are any of these maintained as of April 2026?
All seven trackers in this guide had a release or a substantive commit on GitHub within the last 60 days as of 2026-04-24. lugia19's extension shipped v5.2.3 on 2026-04-24 (Firefox), v5.2.2 on 2026-04-22 (Chrome). hamed-elfayome's Swift app is at v3.1.0 from 2026-04-14. Maciek's claude-monitor and phuryn's claude-usage have shipped patches in April. ccusage continues to track Claude Code's logging schema. ClaudeMeter's macOS app and extension are MIT and actively maintained at github.com/m13v/claude-meter. None of this is guaranteed to age well; pin a version if your workflow depends on it.
Keep reading
Why token counters cannot see what Anthropic enforces
Server quota is a fraction with a private denominator. Local counters have the numerator only.
Tracking a rolling 5-hour window without a stopwatch
Why a calendar window won't catch the slide and how to read the resets_at timestamp instead.
Your plan has seven reset clocks, not one
Every Window field in /usage ships its own resets_at. The bucket at 100 percent is your real countdown.