Anthropic wrote the rule for counting tokens. Its own meter breaks it.

The number I trusted

Since May a tracker on my machine has logged every token my systems consume. I built it because Claude Code's own Stats tab, under /usage, kept losing the count: its history ran out after a while, and I wanted the whole run. So I built mine the way theirs works, reading the same session files the same way, and checked one against the other. They agreed to the decimal. When I asked Claude Code how many tokens I had used, it read the same files and gave the same number. Three counters, one figure, and I built four articles on it.

On 6 September I was checking which day in July had been the most expensive, and went past all three counters into the raw session files Claude Code writes to disk.

One call becomes four. That is the whole mechanism. Claude Code streams a response and writes a line to the session file for each piece of it: the text, then each tool call. Every line carries the token count of the whole call: the cache fields, 96 percent of the volume, repeated identically, the output field growing as the response streams. Sum the lines and a call that read half a million tokens from cache reads two million.

Here is one, from 11 July, as it sits in the file: four lines written over the course of a minute, the same request ID, the same message ID, the same usage on every line: 131 input tokens, 497,971 cache reads, 4,810 output tokens.¹ Most calls are written as two or three lines. The record on my disk is forty-two.²

My tracker added the lines up, because that is how the tab does it. Across everything on my disk the lines say 55.5 billion tokens. The calls say 29.9 billion.² Three counters agreed because they shared a mistake, not because they were right. The rest of this article is about the one of the three that everybody else has too.

What the meter is for

If you use Claude Code as a working tool, the odds are you pay a flat rate, 20, 100 or 200 dollars a month at list price, and for that you have no invoice. The chat app shows a percentage. The Usage tab shows a percentage. The Stats tab shows tokens. It is the only place in the product where a subscriber can see what the subscription delivered, and it is the screen people screenshot when they ask whether 200 dollars a month is worth it. Anthropic invites the arithmetic: its documentation gives a benchmark in dollars per developer per day, and the Session block on the same screen prices your session at API list rates. So a subscriber does the arithmetic: tokens times list price equals what the plan is worth. I did it myself, in print.

The number reaches two groups. Power users work in the terminal, where the Stats tab lives and where it can be checked. The desktop app, built for people who want file access and agents without a terminal, reads the same file the CLI writes and counts it the same way; its "Total tokens" figure covers a shorter window, but each token in it is counted per line.³ I would guess, and it is a guess, that the second group takes it at face value more often than the first.

Take the comparison a subscriber actually makes. Everything else you can say about a model is a judgement of its output; what it took to produce that output can be measured in one unit only, and without this tab a subscriber cannot see it at all. Tokens are the one measure that carries across vendors: output tokens are what you got out of a model, and the plans all cost about the same. Put three subscriptions side by side at 200 a month, and if two of them show a billion tokens and the third shows two billion, you will believe the third gives you twice as much. It does not have to. It only has to count each call twice. It has already reached the comparisons: in August a user asked a public leaderboard to accept the Stats cache as a source, so that history deleted from disk would not vanish from the board, and that profile's total is now the per-line sum.⁴ The meter does not just misstate what you used; it inflates the one number a buyer uses to compare. A meter that showed half the real usage would have produced support tickets. This one produced five threads on the vendor's own tracker, eight people reporting or reproducing it, and no fix.

None of it touches a bill. Invoices and weekly limits are computed on the server. Nobody is being overcharged. What is wrong is the only number you are given to judge what you got.

The rule, the meter, the receipt

Anthropic knows how to count. Its developer documentation says so, in plain words: "When Claude uses tools in parallel, multiple messages share the same id with identical usage data. Track which IDs you've already counted and skip duplicates to avoid inflated totals."⁵

The product follows that rule in two places and breaks it in a third, all in the same window. The Usage tab counts correctly: the person who filed the current bug report found it reporting 1,647 requests, exactly the number of distinct message IDs in his files, while the Stats tab beside it summed the same responses over 4,430 lines.⁶ Two tabs, one window, one set of files, twice the tokens in one of them. The result Claude Code returns when run as a command follows the rule too: in a test on 6 September it matched the once-per-call count in all four token fields, while the once-per-line sum came out at twice the total.⁷ The correct count is inside the product. The Stats tab doesn't use it.

Against my own files the tab's "Last 7 days" figure of 5.80 billion is the per-line sum to the second decimal; the per-call figure is 2.92 billion. The tab's "All time" figure, 62.7 billion as I write, is summed the same way since my first session in November 2025, and it can no longer be recounted: Claude Code deletes session files after thirty days by default, so the evidence for the total expires while the total stands.⁸ Priced field by field at list rates the dollar figure comes out at about the same ratio.⁸ Someone else measured the same screen in early September and got 2.5 times.⁶ The factor depends on how you work: the more tools your agents call per response, the further off it is. Mine is 1.86. Yours is whatever the script at the end of this article says.

Total5.80 bn2.92 bn

Cache read5.6 bn2.83 bn

Cache write217.6 m90.6 m

Output12.3 m6.8 m

Input3.9 m1.1 m

What the Stats tab showsWhat the files say, counted once per call

Part of the community fixed this in June 2025. ccusage, the most used third-party counter, deduplicates on message ID and request ID; so does the leaderboard tool tokscale, whose source names the problem: "CC's streaming API writes the same messageId:requestId multiple times as the response streams in; later entries often carry more complete token counts."⁹ The fix is a set of IDs. Ten lines. But a reference that is wrong does not read as wrong; it reads as the standard. At least eight open-source counters sum the same files the same way, among them a template collection with thirty thousand stars on GitHub, and when one developer audited six of them, one line of the audit read: "Sum everything you see and you get exactly 2×."¹⁰ They matched the Stats tab, so they looked right. Some were fixed the day the report came in. Others are still open, like the vendor's. Every tool calibrated against the vendor's screen inherits the error. I am not telling you to install a third-party tool. I am telling you the fix is trivial, that volunteers wrote it fifteen months ago, and that most subscribers have only the built-in screen.¹¹

One more thing about that window. The Usage tab, which counts correctly, carries a note: "Approximate, based on local sessions on this machine." The Session block, which counts correctly, carries a note in the documentation that for subscribers "the session cost figure isn't relevant for billing purposes." The Stats tab, which counts wrong, carries no note.¹² The vendor warns you about the numbers that are right and says nothing about the number that isn't.

Thirteen months

The timeline, without adjectives.

A precision about the August closure, because it is the sharpest fact here and the easiest to overstate. What was closed was a report about the log format, not the Stats tab, and the answer was correct as far as it went. It does not show that Cherny knew the tab was wrong. It shows that a report saying "sum these files and you get double" reached the person who built the product, was answered from his account with the rule, and that nobody then checked whether the product followed it. The reply cited the rule. Nobody checked.

One consequence for later: between format changes the Stats cache is merged forward, not recomputed, so a fix without a recompute leaves every existing curve as it is. The daily curve on my screen starts on 9 May 2026, when the format last changed; the blank months before it are the series not existing yet, not me not working.¹⁹

The question

Anthropic bills and rate-limits from the server. The screen it gives a subscriber is the only count of the three that is wrong, and the only one a subscriber can check.

So, two questions, and I mean them as questions. Boris Cherny: you know how this should be counted; the rule was cited from your account when the August report was closed. The Stats tab is the one counter your subscribers can hold against their own files, and it is the one that counts wrong. Can we assume that everything we cannot check counts right? And when the fix is a set of IDs, ten lines, and the report has come back five times in thirteen months, how is it still not made?

Dario Amodei: this tab is the only place a subscriber can see what was consumed, and tokens are the only unit that lets anyone compare your product with another. A company valued at close to a trillion dollars in May and, by the Financial Times' account on 4 September, lining up banks for a listing at around two trillion, counts wrong in the one place its customers can check. How should an outsider trust the numbers they cannot check? Your press office was asked twice, on 6 and 7 September. Ten days on, nothing has come back, and the five threads on your own tracker have waited longer than that. For a correction this small, on a meter this visible, I find that remarkable, and I would like to be told why I am wrong.²⁰

The reply, if one comes, will be added here in full.

Numbers without a method

A wrong statistics tab says nothing about Anthropic's models, its benchmarks or its safety work. Those are other systems and other teams, and anyone who reaches for that conclusion will be swatted down in the first reply.

Put the question the other way round. Of every number in this chain, the Stats tab is the only one a customer can check, because it is computed from a file on the customer's own disk. The limits, the five-hour window, the weekly quota, the benchmark per developer, the share of subscribers affected: all of it is counted on the vendor's server and reported without a receipt. The one checkable figure was wrong by half for thirteen months, and finding it took a subscriber reading his own files. That says nothing about whether the other counters are right. It says there is no way for anyone to know. Every meter that measures a sale is calibrated by someone other than the seller: the pump, the scale, the taxi. This one is not. Three things would fix that, and none of them is hard: publish the counting method, give subscribers a per-request receipt they can export, and let someone outside the company audit the meters. This spring the business press ran a season of stories about developers gaming their token counts; every one of them took the count as given, and not one asked how it was counted.²¹

So I wrote the counter I should have written in May. Sixty-eight lines of Python, no dependencies, read-only; it counts your session files both ways and prints the ratio.²² On my machine it says 55,534,208,448 per line, 29,884,358,700 per call, 1.86. Run it. Then decide which of your numbers you built on the first column.

One disclosure, since someone will ask. This article was researched and drafted with the model whose meter it examines, as every part of this series has been. The counting was not. It was done from the raw files with the script above, and the script does not care who wrote it. Run it against your own files and you will not need to trust me either.

What it changed in my own writing

Parts 1, 2, 4 and 6 of this series were built on the inflated figure. Each now carries a dated note at the top and every affected number is marked in place; the details live there, not here.²³ The conclusions did not move: they were ratios, and ratios survive a factor of two. The level moved. Fifty billion tokens was twenty-six. Fifty thousand dollars at list price was 27,600. I should have caught it: a second counter that shares an assumption with the first is not a second counter. So the recount was done the other way round, from the raw files with a different rule, and the case file went to two models from other vendors with one instruction: find where I am going soft on my own model's maker.²⁴

Three questions

Where does the token figure you quote come from: the Stats tab, a tool that deduplicates, or the invoice?

If it is the Stats tab, halve it as a first estimate and run the script for your own factor. The invoice and the Usage tab count correctly. The Stats tab does not.

What decision did you make on that figure?

A plan kept, a business case, a comparison between vendors. Each of those was made on a number about twice the truth, in the direction that made the plan look like better value.

If it were halved tomorrow, what would change?

For the conclusions in this series, nothing: they were ratios. For a subscription decision at the margin, or a deck built on dollars per developer per day, everything.

Notes and sources

1. Session transcript, 11 July 2026, request req_011Ccuez6RjiGqVoj1v4CJcj, message msg_011Ccuez9Mqtj1ZiWESjXQhZ: four assistant lines at 04:41:07, 04:41:31, 04:41:48 and 04:42:08 UTC, content blocks text, tool_use, tool_use, tool_use, identical usage on all four.
2. All 4,661 session files under ~/.claude/projects on 6 September 2026, counted with the script in note 22: 55,534,208,448 tokens once per line, 29,884,358,700 once per request ID keeping the largest usage record per request; 140,048 calls; lines per call 1: 28 percent, 2: 52, 3: 15, 4: 3, five or more: 2, maximum 42. The tracker was fixed and rerun on 6 September; the pre-fix database is kept. Two days (7 and 8 July) have partially deleted files and are estimated from the observed ratio.
3. Anthropic, Claude Code desktop documentation, code.claude.com/docs/en/desktop: local sessions run on an "embedded CLI" and "plan usage is shared across all your Claude Code surfaces". Issues #85509 (10 August 2026: the desktop app "reading from the same local stats-cache.json"), #75777 (the Overview panel shows Sessions, Messages and Total tokens) and #87772 (only the CLI writes the cache; the desktop app has a read-only loader). How many users are on each surface is not published; the only size figure Anthropic has published is that Claude Code reached one billion dollars in run-rate revenue within six months (November 2025).
4. viberank issue #138, opened 21 August 2026: "Accept stats-cache.json as a second provenance source, so history lost to cleanupPeriodDays isn't lost from the board"; the user disclosed the method and offered to revert; the profile then read 221.7 billion tokens. A later comment in the thread (4 September) warns that "treating it as 'Claude Code's own exact counters' would rank stats-cache users roughly 1.6–2× above ccusage users for the same usage". The tokscale importer refuses the same file ("importing it would risk double counting"), quoted from the tool's own output as archived in the ai-usage-proof repository.
5. Anthropic, "Track cost and usage", code.claude.com/docs/en/agent-sdk/cost-tracking, retrieved 6 September 2026. The same page: "Per-step output_tokens is a placeholder, so read output tokens from the result message."
6. github.com/anthropics/claude-code, issue #91775, opened 3 September 2026: Stats tab 706.5 million on a seven-day window, per line 707.2 million, deduplicated 278.1 million; Usage tab 1,647 requests against 1,647 distinct message IDs; Stats summed over 4,430 lines. Status checked 6 September: open, no comments.
7. claude -p … --output-format json --max-turns 8 --allowedTools Read --model sonnet, 6 September 2026, Claude Code 2.1.260, session c2323d3b-a2c7-4acc-8acd-e1fb3b6988a6: three calls, written as 5, 1 and 1 lines. Result usage: input 6, output 920, cache creation 56,257, cache read 141,673. Transcript once per request: identical. Once per line: 14 / 2,876 / 189,293 / 216,709, total 408,892 against 198,856. A first, smaller test the same day (session ffe680fe…, four calls, one of them two lines) gave the same exact match and a per-line total of 273,334 against 221,397. Anthropic's documentation says to read totals from the result message.
8. Screenshots of /usage, 6 September 2026 11:53 to 11:56 CEST, Claude Code 2.1.260, archived. Last 7 days: shown 5.8b; per line from files 5.80 billion; per request 2.92; input 3.9 million shown against 1.1; cache write 217.6 against 90.6 million; cache read 5.6b against 2.83 billion; output 12.3 against 6.8 million. All time: 53.2 billion shown, 29.9 per request. Per field over the whole history: input ×3.1, cache write ×2.3, cache read ×1.84, output ×1.45. On 15 September the same tab showed 8.1 billion for the last seven days; the files on that day counted once per line gave 8.37 billion, once per call 4.03 billion, a ratio of 2.08; for the last thirty days 21.0 billion shown, 24.1 per line, 12.4 per call. The tab's source is ~/.claude/stats-cache.json, field dailyModelTokens. Dollar ratio: 1 June to 18 August priced field by field at the list rates in Part 1's notes, cache reads 16,254 dollars, cache writes 6,148, output 2,810, input 331, total 25,543 once per call, against 44,900 once per line, a ratio of 1.76.
9. ccusage: rust/adapters/claude/src/lib.rs, deduplication on message ID, request ID and session ID, keeping the entry with the largest total; duplicate detection present in the repository at least since 12 June 2025 (pull request #65 unified an existing check). Claude-Code-Usage-Monitor: data-reader.py, key message_id:request_id. tokscale: claudecode.rs, lines 485 to 486, quoted in full.
10. Li Zhuojun, dev.to, 18 August 2026, "I audited six token usage trackers": "Sum everything you see and you get exactly 2×"; "a number everyone uses and nobody can verify is a bad number, even when it happens to be correct." Reports of the same per-line counting in third-party tools, all still open at the time of writing: tokmon #1 (18 April 2026), ClaudeBar #207 (8 June, "overcount ~4x"), cc-lens #38 (21 June), claude-code-templates PR #754 (25 July, 30,745 stars), ccstatusline #549 (11 August, "over-report ~1.84x"). Fixed within days: claude-devtools #74 (February), cclens PR #24 (5 September), agent-cost PR #11 (10 September). Raw copies in the case file.
11. The maintainers of those tools have a known objection, and it belongs on record: the session files also understate output, because the count on early lines is a placeholder (ccusage issue #866 and Claude Code issues #21971, #25941, #27361, #28197, note 14). True, and it does not rescue the tab: on my files 88 percent of calls record ten or fewer uncached input tokens, and the result message in note 7 reports the same small figures, consistent with prompt caching rather than placeholders. Cache reads, which #866 itself describes as accurate, are 96 percent of my deduplicated volume; correcting the placeholders raises the true figure and cannot turn a two-times overcount into an undercount.
12. Screenshots as in note 8. Usage tab, under "What's contributing to your limits usage?": "Approximate, based on local sessions on this machine — does not include other devices or claude.ai." Stats tab, Overview and Models, all three date ranges, footer visible: no such note. Anthropic, "Manage costs effectively", code.claude.com/docs/en/costs: "The Session block in /usage shows API token usage and is intended for API users. Claude Max and Pro subscribers have usage included in their subscription, so the session cost figure isn't relevant for billing purposes."
13. Issue #6805, opened 29 August 2025, labels bug / has repro / area:cost / area:core; closed by github-actions 14 February 2026, locked 21 February.
14. Claude Code CHANGELOG.md, retrieved 6 September 2026 (latest 2.1.263). 2.1.89: "Fixed /stats undercounting tokens by excluding subagent usage, and losing historical data beyond 30 days when the stats cache format changes." 2.1.211: "Fixed /clear not resetting the session cost counter — the statusline's cost now starts at $0 after /clear." 2.1.214: as quoted. 2.1.221: as quoted. 2.1.239: "Cost estimates (/cost, status line, --max-budget-usd) now include the 1.1× US-only-inference premium for data-residency workspaces." 2.1.181 and 2.1.246 fix date placement in the /stats chart and heatmap. No entry mentions the Stats tab's per-line counting.
15. Issue #87303, opened 17 August 2026 with measurements (cache reads 1.59×, output 1.86×, 188 duplicated usage objects all byte-identical); closed at 21:34 UTC the same day by the user account bcherny (GitHub's closed_by field and event log). The closing comment, posted at 21:33 with performed_via_github_app: Claude (app owner: anthropics): "This shape is intentional and documented: when one API response contains several content blocks … it is emitted as several assistant messages that share the same message.id and carry the same usage object. Consumers are expected to count each message.id once … Closing as documented behavior — reply if you think the docs are still missing something and we can reopen. 🤖 Generated with Claude Code" followed by a second line "Generated by Claude Code". Boris Cherny is described by Anthropic as the creator of Claude Code; he left for Cursor in July 2025 and later returned.
16. Issues #90991 (31 August 2026) and #91775 (3 September 2026), both open and without comments from Anthropic on 6 September; status rechecked on the morning of publication and stated in the text. The author of this article posted a comment on #91775 on 7 September with the reproduction in note 7; a third independent reproduction, on Windows, Claude Code 2.1.270, followed on 13 September. Status on the morning of publication: #91775 open with two reproductions and no reply from Anthropic; #90991 open, no comments.
17. github.com/jannemecekAI/ai-usage-proof, 4 September 2026, README and audit-report.md, a de-minified reading of Claude Code's stats module: "counts every transcript line, no message dedup (measured 2.013× the deduplicated count of the same files)"; "No identity tracking"; "3,565 of 3,565 multi-line messages carry byte-identical usage on every line". That counter does not see the deeper workflow transcripts, so against a full scan of that machine the factor is 1.65 rather than 2.01.
18. Issue #94224, opened 14 September 2026: the desktop app's Usage breakdown "counts token usage once per transcript content-block entry instead of once per API request … Cache read … inflated ~2.5× … a session that truly read ~168M cache tokens is shown as ~418M … The 5-hour / weekly limit bars appear unaffected". No comments at the time of writing. The breakdown was announced by Boris Cherny on X on 21 May 2026: "run /usage to see a breakdown of which Skills, Agents, MCPs, and Plugins are using your tokens".
19. Issue #91775 and issue #85509 (10 August 2026) both describe dailyModelTokens in stats-cache.json as merged forward day by day behind lastComputedDate, with a full recompute only when the cache's schema version changes (for example after a reinstall). On my machine the cache for 7 July matches the files as they are today, after a partial deletion, not as they were in August, consistent with one such recompute having occurred.
20. Anthropic, "Anthropic raises $65B in Series H funding at $965B post-money valuation", anthropic.com/news/series-h, 28 May 2026. Financial Times, 4 September 2026, headline "Anthropic close to awarding Morgan Stanley and Goldman Sachs top roles in $2tn IPO". CNBC, 17 August 2026: annualised revenue run rate of 65 billion dollars at the end of July.
21. Fortune, 9 April 2026 ("Claudeonomics"); TechCrunch, 17 April ("you get more of whatever you're measuring"); The Pragmatic Engineer, 23 April; Ars Technica on the Financial Times, 12 May (Amazon tracking token consumption on internal leaderboards); Nature Machine Intelligence, 18 May ("token usage is surely not a good metric for productivity"); Fortune, 1 June (the chief executive of Cognizant calling token counts a "vanity metric"). Raw copies in the case file, research/claude-code-tokenrakning-2026-09-06/ravdata-2026-09-15.
22. count_claude_tokens.py, published with this article at hallengrens.com/files/count_claude_tokens.py. Python 3, 68 lines, no dependencies, read-only. Dedupe key: requestId, falling back to message.id; merge rule: keep the usage record with the largest total for each key; a line counts if it carries message.usage and a timestamp.
23. Deduplicated ledger: 1 June to 18 August 2026, 24.7 billion tokens across 123,878 calls (Part 1 said 45.7 billion, 244,771), priced at the list rates in Part 1's notes about 25,500 dollars against 630 euros paid, about thirty-five times (Part 1 said sixty); 9 May to 24 August 26.3 billion (Part 4 said fifty), about 27,600 dollars (Part 4 said 50,000); against Ramp's April 2026 benchmarks (median 2,246, 75th percentile 14,843 dollars a month) about four times the median and below the 75th percentile. Part 6's run: 1,004,123,005 tokens 1 to 3 July (said 1,876,567,387). Full list in each article's notes.
24. Two reviews of the case file, 6 September 2026, by models from two other vendors, briefed that the author's model is Anthropic's and asked to flag softening. Both flagged the same one: an early draft conflated "misleading measurement" with "overbilling" in order to dismiss the former. That conflation is gone. The first reviewer also insisted on the distinction about the August closure kept above. Eleven further reviews, each from a different reader's position, preceded this version.