tokenstat
homepricingstatshelpsign in
tokenstat
Troubleshooting

Why your numbers disagree with a vendor's dashboard

György
Reviewed by
György
Updated Jul 30, 2026 3 min

If tokenstat and a vendor's usage page disagree, that is usually both of them being right about different questions. This page explains which gaps are expected, so you can tell them apart from a real problem.

They are measuring different things

A billing page shows what you were charged. tokenstat shows usage measured at list rates, whether or not anyone charged for it. If a subscription covered the work, tokenstat marks it plan-covered and keeps it out of the charged column, but it still shows what that work was worth. Those are two different numbers on purpose, and neither is trying to be the other.

This is the single most common source of a "why is this so much higher" reaction, and it is the answer roughly every time.

They cover different windows

A vendor dashboard usually shows a billing period. tokenstat shows whatever you ask it for, defaulting to what it has archived. Comparing a calendar month against a billing month that starts on the 6th will not line up.

Pin both to the same dates before concluding anything:

tokenstat summary --from 2026-07-01 --to 2026-07-31

They see different machines

tokenstat reads the machine it is running on. A vendor account spans every machine you signed into. If you use a laptop and a desktop, the local number will be lower by exactly the work you did on the other one.

That gap is the reason syncing a profile exists: it merges machines into one picture, which a local CLI cannot do for you.

The timezone boundary is yours

Days are bucketed in the machine's own timezone, because that is the day you actually worked. Vendors typically bucket in UTC. Near a month boundary, or if you work late, a day's usage can land on different sides of the line in the two systems.

Some rows are inferred, not read

Not every log records everything cleanly. tokenstat marks each row with a confidence, exact, high, strong, or derived, so a number that had to be worked out never looks like one that was read straight from the file. A report with many derived rows is a report to treat as approximate, and it will say so rather than quietly rounding.

Some tools are not on disk at all

Cursor records no token counts locally. If a meaningful part of your work happens in Cursor, tokenstat will be lower until you connect it through its API with tokenstat auth cursor.

Antigravity IDE sessions need tokenstat fetch with the app running. Its CLI conversations are read offline.

The full list of what each tool does and does not record is in which tools tokenstat reads.

Some history was deleted before it could be read

Claude Code removes its transcripts after 30 days. Anything not scanned before then is gone, and a vendor's own dashboard may still show it. tokenstat doctor compares your archive against Claude Code's rollup and tells you how much has been lost.

What is actually worth reporting

Expected: a higher list-rate figure than your bill, a lower total than the vendor when you use more than one machine, small boundary differences near midnight or month end, gaps for Cursor or Antigravity IDE.

Worth reporting: a source doctor says is present but which produces no rows, a count that changes between two scans of unchanged data, or a model priced as something it plainly is not. Open an issue on the repository with the doctor output, and do not paste log contents: they contain your prompts and your code.