A Claude plan pricing tracker is a three-endpoint join, not a token counter

What “tracker” usually means, and the gap

Open the browser tab that does what most popular trackers do and you find a single bar: 62 percent of a 5-hour window, or some estimated weekly value computed from local Claude Code token logs. Useful, but it is missing the entire pricing half. If your org is on Claude Max at $200 a month with metered billing enabled, the things you actually want to watch are: the rolling-window utilization, the dollar amount you have spilled into extra usage this cycle, the cap you set on extra usage so you do not get surprise-billed, and the renewal date so you can compare last month to this month. That information lives across three separate undocumented endpoints behind your claude.ai cookie. They look stable, they have not been documented anywhere, and the only way to assemble them is to call all three and stitch the JSON yourself.

Endpoint zero: enumerate the orgs

Before any of the three real endpoints are reachable, you need an org_uuid for the URL path. That comes from /api/account. The response carries your email and a list of memberships. Most Pro users have one. Anyone in a team has at least two. Each membership produces an independent snapshot.

The shape is small but load-bearing. ClaudeMeter iterates every membership and treats each org as its own row in the dropdown. Tier and overage cap differ per org, which is why averaging them would lie.

Endpoint one: the rolling-window utilization

This is the endpoint everyone already knows about. /api/organizations/{org_uuid}/usage returns the bars you see on claude.ai/settings/usage. What is less well known: it returns more than one window. On Claude Pro and Max you get five_hour, seven_day, plus per-model breakdowns (seven_day_sonnet, seven_day_opus), and an extra_usage block that mirrors part of the overage endpoint.

The schema is fixed in src/models.rs as the UsageResponse struct, lines 18-28. If a field is renamed upstream, the serde deserializer fails fast and the menu bar surfaces a parse error rather than a silently wrong number.

Endpoint two: overage spend limit

The endpoint that turns a usage tracker into a pricing tracker. /api/organizations/{org_uuid}/overage_spend_limit returns the metered-billing posture for the org: the cap you set, how many dollars of extra usage you have already consumed this cycle, whether you are out of credits, and whether an admin has paused the spend.

Three fields here that exist nowhere else. disabled_reason tells you why an admin paused metered spend (for example, billing failed). disabled_until tells you the timestamp the pause auto-clears. out_of_credits flips to true the moment your used_credits equals monthly_credit_limit, which is the live signal that further prompts will start to fail rather than spill. You will not see any of these in a token-counting tracker, because they are pricing-state flags, not usage measurements.

Endpoint three: subscription details

The other half of the pricing picture. /api/organizations/{org_uuid}/subscription_details returns your tier and renewal posture: status (active, past_due, canceled), next_charge_date, billing_interval, and payment_method (brand, country, last4, type).

A small but useful detail: billing_interval decides which plan dollar amount to show next to your tier in the dropdown. monthly + Pro means $20 (or local currency); monthly + Max means $100 or $200 depending on the tier you picked; annual flips both to a different yearly line. Without that field, a tracker has to guess. With it, the dropdown shows a per-org renewal preview that lines up with what the billing email is going to look like.

The actual join

One alarm, one loop, four awaits per org. Below is the exact shape of fetchSnapshots from the open-source extension. Note the try/catch around overage and subscription: those endpoints can 404 on free orgs without breaking the tick.

The loop is sequential rather than parallel by design. claude.ai applies Cloudflare-style request shaping; firing three calls back to back at minute boundaries looks identical to what a real settings-page reload does. Polling all three in parallel is faster but trips bot heuristics more often.

How the four sources collapse into one menu-bar snapshot

Three pricing-aware endpoints feed one fetchSnapshots call. The output goes three places: badge, dropdown, CLI.

Step by step: what one tick produces

What only a three-endpoint tracker shows

Token counters cover one column on the right. Pricing-aware fields all live in the left column.

What this lets you do that a usage-only tracker cannot

Three concrete examples. First, when five_hour.utilization crosses 100, you can read overage_spend_limit.is_enabled on the same tick to know whether the next prompt will spill into metered billing or 429. Second, when watching a long Claude Code agent loop you can pair used_credits deltas with rolling-window deltas to derive a real dollars-per-prompt rate, not a token-derived guess. Third, on the day next_charge_date fires you can compare this cycle's overage burn against last cycle's before the actual charge lands, because the renewal timestamp is in the same payload as the spend. None of those are possible with one endpoint.

The honest caveat

All three endpoints are internal and undocumented. The field names in this guide map to the Rust structs at src/models.rs (UsageResponse, OverageResponse, SubscriptionResponse) and have been stable for many months, but Anthropic can rename or restructure any of them in any release. ClaudeMeter deserializes strictly: a missing field surfaces as a parse error, not as a wrong number, so you find out immediately rather than days later when the dropdown is silently lying. The README documents the risk and the menu bar shows a ! state when any one of the three breaks.