How the numbers work
What each figure on this site means, how the plans page estimates a weekly limit, and where that estimate goes wrong.
Where the numbers come from
Codex writes a log of every session to the machine it runs on, with the tokens it recorded for each response. The token-counter plugin reads those logs on that machine. When a sharer asks, its share skill sends a summary here: counts per day, each month's top sessions, and the weekly limit readings Codex logged beside them.
These are the counts Codex recorded, not a bill. Every figure is self-reported: the server turns away arithmetic no real log produces, but it cannot verify a report.
Terms
- Tokens
- Recorded input plus output. The leaderboard, profiles and the plans page all count this way.
- Recorded input
- Every input token Codex recorded for a response, cached or not.
- Cached input
- The part of recorded input Codex logged as cached. 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
- 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.
- Plan
- The plan type Codex logs beside those readings, such as
plus. It comes from the logs, not from the sharer's account.
How the plans page estimates a weekly limit
- For each sharer and plan: the tokens counted in their recent weekly windows, divided by the percentage points of the limit Codex reported used in them, times 100. Weeks that used only a few points are left out, since rounding in the reported percentage would swamp them. Only recent weeks count, because limits change.
- That is how many tokens a full weekly limit held, as one sharer's logs saw it. The plans page takes the median across sharers, so one unusual account cannot drag it far.
- A plan shows no number until enough sharers, with enough weeks between them, are on it. Then it shows a provisional median, with the full range of sharers' estimates from lowest to highest. With more sharers the median becomes the headline, and its range the middle half of sharers. The plans page says, for each plan, how many sharers its next step takes.
- 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 observed range: 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.
Why an 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. OpenAI's pricing page says cloud chats and ChatGPT Work share a plan's limits with Codex. All of these 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. About says who runs it.
How accurate is it?
The token counts are as good as Codex's logs: the plugin counts a share from the same ledger as its local report, so the two agree day for day. The weekly limit estimate is rougher. It rests on the percentages Codex logged, 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 the range sharers observed, not as a promise of what a plan holds.
Why do the 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.
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, the handle you pick and, unless you leave it out, your report page. 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/jack-beanstalk-2022/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.