How the numbers work · tokenusage.dev

How homepage category runs are measured

The homepage reads selected local results from /api/subscriptions.benchmarks.results for seven categories: Coding, Image generation, Audio generation, 3D asset generation, Writing, Research & analysis, and Math & reasoning. Coding is one ten-turn simulated session; each other task uses one turn. Research reads supplied synthetic documents. Each published result uses one pinned model, one category version and the category's requested effort.Codex runs use ChatGPT Plus. Claude Opus, Sonnet and Haiku runs use Claude Pro; Fable runs use Claude Max 20x. GPT-6.1 Sol and Opus 5.5 are measured first. Unpublished model/category results stay empty.

Tools are disabled except Codex's native image generator. Codex generates raster images; Claude draws SVG through code. Both tools write audio-synthesis code and 3D assets as Wavefront OBJ text. Completing the scripted turns and required artifact does not establish output quality.

For recorded input plus output T and the result's weekly meter movement d, text weekly estimates are 100T/d tokens. Codex and Claude Pro results use the overall weekly meter; Max 20x Fable results use the Fable weekly meter. Native-image weekly estimates are 100 completed images/d. Publication requires completed tasks, matching terminal usage and task counts, isolated evidence, and movement of at least five percentage points and more than the meter step on the result's weekly meter. Native-image publication additionally requires the runner's verified all-bucket and credit-attribution checks. The publisher checks those summary fields without replaying raw evidence. Reported five-hour windows are guarded; an absent Codex window is recorded and does not establish unlimited session capacity. Other session, model or image limits can bind earlier.

Token totals include CLI system prompts and retained history. The live harness checks observed about 17,100 input tokens per Codex turn and about 2,040 per Claude turn; these are included rather than subtracted. Cached input and both cache-write durations are subsets of input. Reasoning, when reported, is a subset of output. Native-image token totals contain only reported orchestration-model usage; the image model's tokens are not reported.

For a text run, API cost is ((input - cachedInput) × inputPrice + cachedInput × cachedInputPrice + output × outputPrice + (cacheWrite5m/4 + cacheWrite1h) × inputPrice) / 1,000,000. Prices come from that model's catalog row. Monthly API value multiplies this cost by 100/d and by 365.25/12/7 weeks per month. Cache writes already receive the base input price; the additional terms supply their five-minute and one-hour premiums. Native-image rows publish no API value. Codex native-image rows show images per week; their API-value column shows "--" because image-model tokens are not reported.

Codex Pro $100, $200 and $500 multiply the measured Plus weekly estimate and API value by 10, 20 and 50: twice the 5× OpenAI gave Pro $100 at launch and the 10× and 25× reported for Pro $200 and Pro $500, since OpenAI doubled Pro limits on October 29, 2026. OpenAI publishes no numeric Pro multiple versus Plus, so these are assumptions.For Opus and Sonnet, Claude Max 5x and Max 20x multiply the measured Pro figures by 5 and 10. Max 5x uses Anthropic's per-session multiple of 5; applying it weekly is a site assumption. Max 20x uses 10, the weekly multiple measured with Opus on Max 20x in October 2026, not Anthropic's per-session multiple of 20. Fable is measured on Max 20x against the Fable weekly meter. Max 20x uses that estimate directly; Max 5x uses one half as a projection. The Pro card shows Opus, Sonnet and Haiku; both Max cards show Opus, Fable and Sonnet. The value bar separately compares monthly API value with the card's own subscription price. Higher-tier scaling assumptions are explained on this method page.

Cards show weekly capacity and monthly API value. Speed appears only in the daily Speed chart. Category runs may retain turn timings locally as evidence; those timings are not published in capacity records. Requested effort does not establish equal hidden reasoning budgets.

All projections use unrounded counts and prices. Displayed capacity, API value and value ratios are rounded to two significant figures. A measured-plan weekly figure is an extrapolation from a measured run. Figures scaled from a lower plan are assumed estimates. Meter resolution, reporting lag, account variation, policy changes and workload changes can affect the result. The cards make no claim of an overall quality winner. For capability trends, read our AI benchmarks by field.

The homepage category cards

How the daily Speed chart is measured

The daily Speed chart measures one fixed small task: returning the integers from 1 through 64 as a comma-separated line. Probe version 1 uses three fresh single-turn sessions per measured Speed series at high effort. Current probes use Standard/default service. Earlier probes used the Ultrafast service tier for the additional GPT-6.1 Sol and GPT-6 Astra series. Codex uses our ChatGPT Pro login; Claude uses our default Max 20x login, separately from capacity accounts. Kimi K3.1 Pro, GLM-5.3 and DeepSeek V4 Pro use the OpenCode CLI signed in to OpenCode Go. Each published point is the median completion time for that model and UTC day, rounded to two significant figures. Codex timing runs from request write to completion receipt, Claude from system/init receipt to result receipt, and OpenCode from exported assistant creation to completion. Setup and process exit are excluded. The Output speed chart divides each daily Nerf Watch run’s total output tokens by total completion seconds across its four fixed tasks. Effort is low, except DeepSeek V4 Pro uses high, its lowest available variant. Current runs use Standard/default service; the historical Ultrafast measurements used the Ultrafast tier. Reported reasoning or thinking tokens are included once; OpenCode’s separately reported reasoning is added to output. The rate includes waiting within each measured turn, is rounded to two significant figures, and starts with new measurements without backfill.

The Windows task is scheduled at 00:10 UTC. A delayed start uses its actual UTC date. A model without three valid responses is absent; an empty day records a completed probe without successful models; a missing day records no accepted probe. The chart starts with the first local probe. The former sharer-derived history is archived privately. Shares and deletions do not change probe points. The homepage reads this series through /api/subscriptions.responseTimes.

For historical API measurements, read our research on AI model speed.

Where shared-report numbers come from

Codex writes a log of every session to the machine it runs on, with the tokens it recorded for each response; Claude Code records the tokens it saw for a response in its transcripts, and a call without transcript usage leaves none. The token-counter plugins read those logs on that machine. When a sharer asks, a plugin's share skill sends a summary here: counts per day, each month's top sessions, and the weekly limit readings logged beside them.

Shared-report counts are what Codex or Claude Code recorded, not a bill. Reports are self-reported: the server turns away arithmetic no real log produces, but it cannot verify a report. Shares do not supply homepage cards or daily speed probes.

Terms in shared reports

Tokens: Recorded input plus output. The leaderboard, profiles and shared-report API count this way.
Recorded input: Every input token Codex or Claude Code recorded for a response, cached or not. Claude input includes base input, cache creation and cache reads.
Cached input: Recorded input logged as cached by Codex, or cache reads recorded by Claude Code. It is a subset of recorded input, never added on top.
Uncached input: Recorded input less cached input.
Cache hit: Cached input as a share of recorded input.
Output: Tokens the model wrote, reasoning included.
Reasoning: The part of output spent reasoning. A subset of output.
Active time: The time between consecutive responses in a session, leaving out any gap over 30 minutes. Span is the wall-clock time from its first response to its last.
Days and months: The sharer's local calendar days, as in the plugin's report. A session belongs to the day its first response landed on.
Weekly window: For Codex, one run of a plan's weekly limit, from one reset to the next. Beside each response, Codex logs the plan and how much of the weekly limit the server says is used. A window starts where that percentage drops, which is not always seven days after the last one started. For Claude Code, the stretch of one weekly window that the sharer's percentage readings cover. Its start is the nominal reset minus seven days, not proof that the quota opened then.
Plan: The plan type Codex logs beside those readings, such as plus. It comes from the logs, not from the sharer's account. For Claude Code, the plugin maps its captured account observations to claude:pro, claude:max-5xor claude:max-20x, and gives a window a plan only when every observation from its first reading on, and the latest one before it if there is one, agree and the subscription was created no later than that reading; otherwise the plan is unknown.
Response time: For Codex, from the moment a prompt was complete, the sharer's message or the last tool output, to the moment Codex recorded the response: network, queueing, reading the prompt, writing the answer and any retry, together. Codex records no send time, so the plugin reads it off the logs' own timestamps. For Claude Code, from the last known prompt-side record, frozen at first output and floored at the previous response end in the same stream and at completed compaction, to the last response record.
Turn time: From the sharer's message to the last response of the turn, tools and approvals included. For Claude Code, a turn is computed from its transcript stream.
Output tokens/s, above pace: The plugin's estimates, marked with a star wherever they appear. For each model and effort it fits a line under the fastest tenth of responses: a fixed overhead plus a time per output token and per uncached input token. Output tokens/s is that line's rate, and above pace is the share of response time over it. That share is mostly queueing and retries, but slow stretches of writing land there too, so it is not a measured queue time.

How the shared-report API compares plans

The shared-report /api/subscriptions endpoint compares Codex and Claude plans at $20, $100 and $200 a month and adds Codex Pro at $500, with three models per plan. The site picks the plans and models; a sharer cannot add one. The homepage reads its catalog and API prices but ignores its cell figures.
Each API cell is one model on one plan: a weekly limit estimate, its value at API list prices, and available response times. Both vendors use the same calculation and sample thresholds. Those thresholds do not govern homepage category-run figures.
Codex cells fill from shares sent with token-counter 1.10.0 or later, whose weekly windows record each model's tokens and speed mode. Claude cells fill from claude-usage shares: a window counts the responses between its first recorded percentage reading and the earliest reading that reached its peak, so later readings at the same peak add nothing. A rejected weekly 429 counts as a 100% reading; the plugin assumes it refers to the all-model limit and records that assumption. A window whose readings decline, conflict or miss an endpoint is not shared.

Claude quota evidence in the shared-report API

Claude's reference account resets on Friday at midnight in UTC+8, as confirmed by server reset times. Counts stop at the corresponding plan percentage reading; later usage is excluded. A weekly limit refusal establishes a 100% reading.

The restored October dataset in the shared-report API comes from one real account; its other profiles are extrapolations. The API identifies their provenance; extrapolated profiles are not independent measurements. Models without a qualifying majority week remain empty, and no response time is inferred. Cache creation tokens are part of uncached input; their API value uses 1.25 times the input price for a five-minute cache and twice the input price for a one-hour cache. This dataset does not supply homepage cards.

Claude Code sharers' own qualifying windows now fill Claude cells too, beside that dataset.

How the shared-report API estimates a weekly limit

For each sharer: the tokens counted in their recent weekly windows, divided by the percentage points of the limit the vendor reported used in them, times 100. Only weeks that started in the last 90 days and used at least 5 percentage points count, because limits change.
That is how many tokens a full weekly limit held, as one sharer's logs saw it. A cell's figure is the median across the sharers on that model and plan, so one unusual account cannot drag it far.
A week counts for the model that makes up at least 60% of its cost at API list prices. Its tokens on other models are converted to that model at the same prices, input, cached input and output each at their own rate, so a week that is 70% Sol and 30% Astra by cost counts as a week of Sol. Fast tokens count 2.5 times and Ultrafast 8 times, the rates at which they draw on the limit.
The conversion assumes a plan charges each model in proportion to its API price, which OpenAI does not say. If the other model in a week at the 60% cutoff actually drew twice as much of the limit per dollar, the estimate would be about 29% low; if half as much, 25% high.
Codex's automatic reviewer may make up at most 5% of a week's tokens. Its tokens are left out and the points it used stay in, so it can only lower an estimate.
An API cell publishes no number until enough sharers, with enough weeks between them, are on it. It then publishes a provisional median; with more sharers the median becomes headline. These bands do not govern homepage category-run figures.
Every figure it publishes is rounded to two significant figures, and there is no mean: one account could drag a mean anywhere, and the mean before and after a share would give away that sharer's exact estimate.
The result is an estimate of what sharers' weeks held. OpenAI's pricing page gives no limit in tokens. It says model choice, context, reasoning, tool use, retrieval and caching all affect usage, and that Fast mode draws on included usage at 2.5 times the Standard rate. So the same limit can hold more tokens in a cache-heavy week, and fewer in a week of Fast mode.

How the shared-report API compares response times

Each sharer's plugin times their responses over the last 30 days and sends the median and 90th percentile per model and reasoning effort, which their profile shows.
An API cell's response time is the median of its sharers' medians on that model and plan, at one reasoning effort, and publishes only once enough sharers were timed on it for the cell's band.
The daily Speed chart uses the local probes described above. API cell response times in this section still come from sharers. Shares and deletions do not feed the daily chart.
Response times depend on the task, caching, network conditions, queueing and time of day. The daily chart shows what the fixed task took on our accounts and machine.

Why a shared-report estimate can be off

Low, most often. Usage the sharer's logs do not see can draw on the same limit: Codex on another machine, cloud chats, ChatGPT Work; or, for Claude plans, Claude Code on another device or usage in the Claude app. OpenAI's pricing page says cloud chats and ChatGPT Work share a plan's limits with Codex. These can raise the percentage without adding tokens here.
High, sometimes. Tokens in the logs that did not draw on the plan add tokens without raising the percentage: a session signed in with an API key, which is billed at API rates, or GPT-5.3-Codex-Spark, which launched with limits of its own, until its deprecation in September.
Out of date. Limits and models change, and an estimate pools several recent weeks. Changes lists the ones that can move it.

Questions

Is this official?

No. tokenusage.dev is an independent site, not affiliated with or endorsed by OpenAI or Anthropic. About says who runs it.

How accurate are shared reports?

The token counts are as good as Codex's or Claude Code's logs: each plugin counts a share from the same ledger as its local report, so the two agree day for day. Claude Code prunes old transcripts, so its plugin keeps a capture history and replaces a shared month only when it can still reproduce everything it submitted before. The public API's shared-report weekly limit estimate is rougher. It rests on the percentages the logs recorded, on how much of a sharer's usage their logs saw, and on a limit that does not weigh every token alike. Read it as an estimate from sharers' weeks, not as a promise of what a plan holds.

Why can shared-report estimates err low?

Because what the logs miss usually still draws on the limit. Codex on a second machine, a cloud chat or ChatGPT Work raises the percentage and adds no tokens here, so the tokens per point come out smaller than they were. Claude Code on another device or usage in the Claude app can do the same.

What is sent?

Counts per day, each month's top sessions by active time and by tokens under a hashed id, the weekly limit readings with the tokens counted beside them, response times per model and reasoning effort over the last 30 days, the handle you pick and, unless you leave it out, your report page. Neither plugin sends the hour-of-day or weekday buckets the protocol allows. Never prompts, outputs, file contents, paths, session titles or your account. Privacy says what is kept and what is public.

How do I delete my data?

Ask Codex to remove your data from tokenusage.dev, or run python3 scripts/share.py --delete --yes from the plugin's token-share directory, ~/.codex/plugins/cache/stdcmms-lang/token-counter/*/skills/token-share. It deletes everything you shared, your report page included, and releases your handle. It needs the token from your first share, which the plugin keeps on your machine; if you lost it, see Contact.

For Claude Code, ask it to remove your data from tokenusage.dev, or run python scripts/share.py --delete --yes (python3 on macOS and Linux) from that plugin's token-share directory, ~/.claude/plugins/cache/stdcmms-lang/token-counter-claude/*/skills/token-share. Its share token is separate from the Codex plugin's, and the deletion leaves the local capture history in place.