Method and caveats
A fresh Claude Pro account is driven through headless Claude Code in controlled bursts. Each burst spends mostly one kind of token, and the account's usage meter is read after every call. From how far the meter moves per token of each kind, the site solves what the subscription actually charges, and converts it all into one unit.
The meter
Paid Claude plans have two limits: a rolling five-hour window and a weekly cap. Both are reported as whole-percent utilization. Anthropic publishes no token or dollar figure for either, only a list of factors that affect usage: message length, conversation length, model, effort, tool use, and that cached content "counts less".
Claude Code's streamed JSON output includes a rate_limit_event on every call, carrying both windows' utilization as a fraction and their reset times. That is the same data the /usage command shows. The harness reads it from each burn call, so every call doubles as a meter read with no separate endpoint and no polling limit. The reading arrives in the response headers, before that call's own output is counted, so it is paired with the spend of the calls before it. A tiny probe call brackets each run at both ends.
The three burn modes
Every call runs claude -p with all tools disabled, a one-line system prompt, effort low, Sonnet 5.5 or Opus 5.5, and no session persistence. Each mode holds the token mix constant so that one run measures one weight.
| Mode | Prompt | What dominates the spend |
|---|---|---|
| output | "Write a 4000-word essay about topic." Fifteen rotating topics, continuous prose. | Output tokens, about 7K per call. Overhead is Claude Code's ~11K system prompt as a 1-hour cache write on the first call and a cache read after. |
| input | About 70K tokens of plain English (Unix manual pages, a different slice each call) followed by "reply with exactly OK". | Cache-write tokens. Claude Code puts a cache breakpoint on the user message, so the big prompt is billed as a 1-hour cache write rather than plain input. Plain input cannot be isolated through Claude Code. |
| cache | The same 70K-token prompt on every call, inside the cache window. | Cache-read tokens, about 80K per call, with one cache write on the first call. |
A partial run stops once the five-hour meter has risen a set number of points, typically 8 to 10. A full run keeps going until the account is rate-limited, which measures the window outright instead of extrapolating.
Two things learned the hard way: a 60K-token prompt of shuffled dictionary words is flagged by the model's safeguard classifier and refused, which is why the filler is real prose; and refused calls still charge the meter for their input.
From meter movement to a window size
The meter only reports whole percents, so a single before-and-after difference carries a ±1 point error. Two refinements shrink it:
- Step fit. Every time the integer meter ticks up, the run has crossed a threshold at a known cumulative spend. A regression through those crossings gives percent-per-token far more precisely than one ratio. Runs so far fit with r² above 0.99.
- Solving the weights. With one run per mode, three equations in three unknowns give the meter's points per token of each kind: output, input-or-cache-write, and cache read. Plain input is negligible in every mode and is folded into cache write. The ±1-point ranges shown next to each weight come from re-solving at every corner of the rounding error.
Pinning output to its API list price turns those weights into a "meter-implied price" per token kind, which is the easiest way to see how the subscription's weighting differs from the public price list.
What the meter charges per token kind
Solved from the latest run of each mode per model, with output pinned to its API list price so the other weights read as prices. The ±1-point range re-solves the system at every corner of the meter's whole-percent rounding.
Loading from summary.json…
The units on the front page
- Adjusted output tokens. Every token kind converted into output tokens by the meter's own weights, then scaled to a full window: 100 points divided by the meter's points per output token. This is the headline because output tokens are the one kind people can picture, and because it is independent of what mix you happen to run.
- API credits. Adjusted output tokens priced at the model's list output rate. What the same usage would cost if it were all output and billed per token.
- Cache reads (adjusted). The same budget spent entirely on the cheapest token kind. A reminder that a long agent loop, which is almost all cache reads, goes a very long way.
Window. Five hours is measured directly. A day is shown as 4.8 windows, which assumes every window is used fully; the weekly cap usually binds before that. The week is a pooled estimate: the weekly meter moves slowly, so every run's adjusted spend is accumulated against it across runs, and the range stays wide until many runs have landed.
Ranges. The five-hour figure carries the ±1-point rounding of the meter, which the step fit narrows to a few percent. The weekly figure is much coarser: the weekly meter has moved only a handful of points inside runs so far, and its range is shown in the weights section below. The day figure inherits the five-hour figure's precision but assumes every window is used in full.
Plan. Only Pro is measured. Max 5x and Max 20x are shown as straight multiples of Pro, marked as extrapolated. Anthropic describes those tiers as multiples of Pro's usage, and one informal comparison against a real Max account came out near 4x, but nothing on this site has verified them.
Caveats
- Open question: does the rate change by time of day? The first run from GitHub Actions, at 9:51am US Pacific, moved the meter about 1.6x as far per Opus output token as a run at 8:38pm the night before, with cleaner inputs. One pair of runs is not evidence, so the schedule now burns a small Opus output run twice a day, at 03:00 and 17:00 UTC, to build a peak-versus-off-peak comparison. Same-day runs of a mode are pooled, so the headline reflects the day's average rather than the latest run.
- Three runs and three unknowns is an exact fit; the evidence for linearity is the within-run step fits, not the cross-run solve. More runs per mode will overdetermine the system and give real residuals.
- The weights are per model. Sonnet and Opus are solved separately; other models are not measured.
- Anthropic can change allowances at any time, and says so. Every run is dated, and the history chart exists to catch drift.
- Thinking tokens count as output tokens. Burns run at effort low so there are almost none, but a thinking-heavy workload spends output tokens you do not see.
- Everything is measured through Claude Code, with its system prompt and caching choices. A different client with different cache breakpoints would spend the same budget differently, but the meter weights should be the same.
Data and code
Raw per-call records for every run are in data/raw/, run summaries in runs.json, solved weights and window sizes in summary.json. The harness, analyzer, and this site are at github.com/mitchellgordon95/claude-token-count. Runs are scheduled from GitHub Actions and committed back to the repo, so the history is the git log: a small Opus output burn twice daily, all three modes on both models every Sunday, and a full burn to the limit on the first of the month.