One historical run had 317,935 in one column and 623 in another. That does not make either figure wrong. Calling both total would make the explanation wrong. I went back to the recorded components to show how the two quantities were actually calculated.
Cached input is already inside input
The recorded input was 317,540, including 317,312 cached input tokens. Cache is a subset, not additional usage alongside input. Adding output of 395 yields total 317,935. Adding cache once more would count part of the input twice.
In this contract, reasoning is likewise a subset of output. A separate reasoning field does not justify another addition. The reviewed measuredUsage accepts valid nonnegative integers and leaves invalid cache-above-input or reasoning-above-output detail null. It does not repair an invalid figure into a reassuring zero. These relationships belong to the stated accounting contract, not an assumption about every service's arbitrary usage schema.
The 623 figure is uncached input plus output
Subtracting cached input leaves 228, and adding output of 395 yields 623. The accurate name is uncached input plus output. The total of 317,935 has not disappeared. Emphasizing only the smaller figure in a cache-heavy run could imply that the entire conversation contained that many tokens.
The two measures can answer different questions, but renaming one as the other breaks comparison. The historical report kept both columns. I prefer headings that state the unit and calculations that remain reproducible. The issue is not choosing whichever number looks better; it is letting the reader identify the denominator and included components.
An unavailable value is different from zero
The original schema represents missing details such as inputTokens as null. TotalUsage adds known values while retaining unknownCalls and unknownCacheCalls. A known subtotal with unavailable calls cannot establish a fully known aggregate. Historical tasks with only a legacy total do not acquire invented component detail retroactively.
The synthetic ledger makes this explicit for each metric through known_sum, unknown_calls and complete. It also separates a reported total lacking component detail from a total derived from known input and output. Completeness in one column does not remove missing values in another. This is an independent teaching implementation rather than a complete copy of the original, designed to make the gaps in an aggregate readable.
Keep failed calls when their actual usage is known
Failure to parse a response does not mean the model used no tokens. An original unit case retains known usage from a parse failure and charges an identical measured failure only once when redelivered. A network error without returned usage remains unknown.
Cancellation and task switching must preserve attribution as well. Another case avoids charging a late old-task response to the newly selected task. These are historical accounting designs and tests from the retired internal-model path, not a claim that the current app runs that CLI. Which status and task own a measured call are part of the usage explanation, not incidental metadata.
Do not turn a token table into a bill or allowance claim
This article compares retained sources, tests and arithmetic from a historical measurement. It makes no new model request and queries no current billing account. I do not label 623 billable tokens by assuming subscription cache treatment or a pricing schedule. Linking usage to money needs separate current contractual evidence.
The public ledger lets readers change synthetic values and test subset accounting, unavailable values and duplicate receipts. Provider authentication and currency calculation remain False. I retain both the large and small figures under their actual names rather than hiding one or relabelling the other. Different perspectives on an execution should preserve the meaning of its arithmetic.