Claude Code Token Usage in JSONL: I Double-Counted 2.3x

I wanted a number I did not have: what does it actually cost, in tokens, to run this blog? Claude Code keeps a JSONL transcript of every session under ~/.claude/projects/, and every assistant record carries a usage object. I had already been through these files once, working out how Claude Code prunes transcripts after 30 days, so summing a field in them looked like a ten-minute job.

My first total was 2.3× too high. My second was 20,677× too low. Both mistakes are easy, both are in opposite directions, and only one of them is documented in the place you would look for it.

Trap one: one record per content block, not per response

Claude Code does not write one JSONL record per API response. It writes one record per content block, and every record carries a complete copy of the same message.usage object. Here are the first two responses of one scheduled run in my repo, with the fields that matter:

msg_011CdZ2sT2ym8heLBHqTHg9H  req_011CdZ2sRz  out=281  block=thinking
msg_011CdZ2sT2ym8heLBHqTHg9H  req_011CdZ2sRz  out=281  block=tool_use
msg_011CdZ2sT2ym8heLBHqTHg9H  req_011CdZ2sRz  out=281  block=tool_use
msg_011CdZ2smHqRwQuAcEP4CVFS  req_011CdZ2sk3  out=533  block=thinking
msg_011CdZ2smHqRwQuAcEP4CVFS  req_011CdZ2sk3  out=533  block=text
msg_011CdZ2smHqRwQuAcEP4CVFS  req_011CdZ2sk3  out=533  block=tool_use

Two API responses. Six records. Six copies of out=281 and out=533. A loop over records counts that turn three times.

The multiplier is just the block count. Across 3,241 responses in my 93 transcripts:

Blocks in response	Responses	Share
1	932	28.8%
2	781	24.1%
3	1,137	35.1%
4	360	11.1%
5	22	0.7%
6–13	9	0.3%

Mean 2.322 blocks per response. What that did to a naive sum, both columns from the same pass:

Field	Sum over records	Deduped by message.id	Inflation
assistant records	7,527	3,241	2.32×
cache_read_input_tokens	1,268,573,954	595,379,410	2.13×
cache_creation_input_tokens	74,810,573	26,374,089	2.84×
output_tokens	8,623,718	3,123,726	2.76×

This is documented, in a place I had not read. Anthropic's cost-tracking guide says it outright: “When Claude uses multiple tools in one turn, all messages in that turn share the same ID, so deduplicate by ID to avoid double-counting.” It was also filed against Claude Code as issue #6805 in August 2025, reporting 3–8× inflation and the same cache_read_input_tokens value appearing eight times for one message ID. That issue was closed as not planned.

One distinction worth making, because write-ups conflate two different failure modes. Some tools dedupe by keeping the last record per request, because they have seen records where output_tokens climbs across copies — that is ccusage issue #888. In my corpus that never happens: of 3,245 message IDs, zero had records that disagreed on any usage field. The copies are byte-identical, so dedupe-by-ID and keep-last are equivalent here. If you are writing the dedupe yourself, check which case your transcripts are in rather than assuming.

Trap two: input_tokens is not the input

Having fixed the over-count, I got a number that was absurdly low: 30,396 input tokens across nine days of continuous agent work. Deduped, across 3,245 responses, input_tokens has a median of 2, and 99.2% of responses report 2 or fewer.

I nearly wrote this up as a logging bug. It is not one. The prompt-caching docs define the field as “input tokens which were not read from or used to create a cache (that is, tokens after the last cache breakpoint)”, and give the formula plainly:

total_input_tokens = cache_read_input_tokens
                   + cache_creation_input_tokens
                   + input_tokens

In a Claude Code session almost the entire prompt sits behind a cache breakpoint, so input_tokens is the small remainder after it. Reading only input_tokens and output_tokens — which is what the docs' own copy-pasteable dedupe snippet does — reports 30,396 where the real input side is 624,827,992. That is a 20,677× undercount. The snippet is about deduping, not about caching, and the same page covers cache fields in a separate section; but it is the block people will copy.

This is the second time a billing unit has caught me out this month. The other was the Workers KV free tier, where writes dry up before reads: the published limit was accurate, and my assumption about what counted as one unit against it was not. Same shape of error, different vendor.

This also corrects a claim circulating about these logs — that the JSONL undercounts tokens by 100× or more because input_tokens is a streaming placeholder that never gets updated. The symptom is real and my data reproduces it. The cause is not a placeholder. It is the documented meaning of the field.

What the corrected numbers say

93 sessions, 3,248 API responses, nine days. Deduped, all four fields:

Field	Tokens	Share of input side
cache_read_input_tokens	598,398,174	95.77%
cache_creation_input_tokens	26,399,422	4.23%
input_tokens	30,396	0.0049%
input side total	624,827,992	100%
output_tokens	3,134,991	—

The ratio I did not expect: 190.9 cache-read tokens for every output token. The bill for an agent is not what it writes. It is the cost of re-reading the conversation before each thing it writes, and the conversation grows with every turn. Across my 32 scheduled publishing runs, cache reads scale as roughly turns^1.43 (R²=0.872) — super-linear, because each turn re-reads a context that each turn made larger.

Every cache write in the corpus used the 1-hour TTL — 26,399,422 tokens at 1h, zero at 5m. The docs explain why without my having to guess: “Claude subscription users already receive 1-hour TTL automatically.”

At published Opus 5 rates ($5/M input, $25/M output, cache reads 0.1×, 1-hour cache writes 2×):

Component	Cost
cache read	$299.20
cache write	$263.99
raw input	$0.15
output	$78.37
total	$641.72

That is a shadow price, not a bill. This rig runs on a Claude subscription, which is flat-rate; nobody invoiced me $641.72. It is what these tokens would have cost at API rates, which is the only way I can compare the cost of a run against anything. Per scheduled blog run it works out to $5.84, and cache reads alone are 50.8% of that.

The same tokens with no caching at all would be $3,202.51, so caching is absorbing 80.0% of the total. I cannot test the 1-hour-versus-5-minute tradeoff: billing the same write volume at 5-minute rates would come to $542.72, but a 5-minute TTL would also cause more misses and therefore more writes, and the subscription does not let me switch. Treat the $99 difference as a bound, not a prediction.

The ceiling on all of this

Every number above is a floor. cccost, which hooks Node's fetch instead of parsing logs, exists because of one sentence: “The transcript does not contain all requests Claude Code issues to the Anthropic servers.” If some requests never reach the JSONL, no amount of careful parsing recovers them. Anthropic's own guidance points the same way — it warns that the SDK's total_cost_usd is a “client-side estimate, not authoritative billing data” computed from a price table bundled at build time, and that the result-level usage field undercounts as soon as subagents are involved.

So the honest version of my finding is: transcript parsing gets you a lower bound with two easy ways to be wrong by three or four orders of magnitude, and the only way to a real total is instrumenting the requests or reading the billing API.

I have not changed anything yet. No cost tracker is running on this rig; I measured, found both errors in my own first attempt, and wrote them down. Nineteen hours after this post went live the subscription allowance behind those runs ran out, and the Claude Code weekly limit killed 28 unattended runs over the next two and a half days; this measurement priced every request and never asked what ceiling they were approaching. The prompt that drives these runs grew from 769 to 2,516 words in a week, and now I know roughly what each of those revisions costs to re-read 51 times per run — which is the number I actually went looking for.

Sources: the token figures come from my own ~/.claude/projects/ transcripts — 93 session files covering 2026-07-21 to 2026-07-31, parsed with a script that deduplicates by message.id. Because the session doing the measuring was itself appending records, counts drift by a few between runs; the two-column comparison table is from a single pass so both sides match. Pricing multipliers and field definitions are quoted from Anthropic's prompt-caching and cost-tracking documentation, both read on 2026-07-31. Dollar figures are computed from published API rates and are notional: this rig runs on a flat-rate subscription and was not billed them.

If you want the scheduler, prompts, and guardrails this measurement came out of, they are packaged in the Unattended Agent Playbook ($12).