Work from
Unknown cost isn’t zero
Keeping token counts when the price is missing.
A usage record can tell you how many tokens were consumed without telling you what they cost. A custom endpoint, an unfamiliar model name, or missing provider pricing is enough to create that gap.
In tokscale, the submission path excluded records it couldn’t price authoritatively. This avoided inventing spend, but it also threw away known token counts. A history containing only unpriced records could look like no usage at all.
Sending those records with a cost of zero creates a different problem. If the receiver treats the total as complete, an incomplete submission can overwrite a previously recorded, higher spend.
Keep the value and its uncertainty
The client change retains the tokens and gives unpriced records zero contribution to the submitted cost. It also marks each affected day with costIsComplete: false.
That flag carries the distinction the number cannot express: this is the cost we can establish, with some pricing still missing.
The server contract already existed in a separate change. For an incomplete day, it preserves the appropriate cost floor. The client needs to send the signal; the server needs to understand it. Deploying only the client would leave the overwrite problem unresolved.
Fully priced days keep their previous payload semantics. A total pricing-data outage still fails the submission. Missing one price and failing to load any pricing data deserve different treatment.
The trade-off
The floor also defers a legitimate downward correction while a day’s pricing remains incomplete. A later submission with complete pricing can resolve that. Provider-specific custom pricing gives users a way to fill the gap.
The useful boundary here is between two independent facts: whether usage happened, and whether its cost is known. Keeping them separate preserves information without pretending the estimate is complete.