A Claude Code log sum doubled after message ID dedupe

I had a 65.5 billion-token Claude Code claim queued for publication. Then I tried to reproduce it.

The old note called its result “30-day,” but its July 18 to August 19 dates cover 33 calendar days. The extractor and daily inclusion list are gone. In the files still on this machine, only two of the claimed 13 profiles have usage rows in that date filter. I cannot recover the estate-wide total from this archive.

What I could check was the row count. The retained two-profile slice contains 116,158 assistant usage rows and 53,231 distinct message.id values. Summing every row's four top-level usage fields gives 16.58 billion tokens. Selecting one final row per ID gives 8.29 billion. The raw-row tally is 2.0004 times the deduplicated tally for this slice.

That is not a rounding problem. Many IDs appear several times. In sampled groups, output_tokens rises as Claude Code emits the message while the other buckets stay constant. I kept the row with the largest output count for each ID, using the latest timestamp to break ties; choosing the latest row gave the same aggregate here.

For the next usage export, I would keep the audit small enough to inspect:

1. State the time filter and count which profiles still have records inside it.
2. Group assistant usage rows by message.id. Open a sample of repeated groups before deciding which row is final.
3. Sum input_tokens, cache_creation_input_tokens, cache_read_input_tokens and output_tokens once per selected ID. The nested cache-creation detail is already inside its parent bucket.
4. Keep request times if you plan to size a server from the result. A token sum cannot describe the busy hour.

Cache reads account for 7.995 billion of the 8.287 billion deduplicated tokens, or 96.47% of this retained slice's token volume. Anthropic's usage documentation explains the input fields. The percentage is not a spend share, and it says nothing about another user's workload.

The aggregate-only audit publishes the method and counts without private message content. It cannot tell whether the old 13-profile note used logs that have since disappeared or made an extraction error. Before a build-versus-buy calculation, I would need the deduplicated request trace and the contract that actually governs the buy side.