Two providers, two cache conventions, one wrong number

A post published on dev.to argues that most teams running LLMs in production hold two numbers for last month's spend, the one in their tracking tool and the one on the provider's invoice, and that the reasons they diverge are already documented in the tools' own docs ^[1]. The specific mechanism worth your attention is a reporting convention: OpenAI folds cache reads into the reported input token count, while Anthropic reports cache fields separately from regular input ^[2][3].

Both choices are documented and both are defensible, according to the author, but any tool that computes cost through a single code path across both providers will be wrong on one of them ^[4]. Work through it and the failure is mechanical. A path that adds reported cache-read tokens to reported input tokens is correct under Anthropic's separated reporting and counts cache reads twice under OpenAI's folded reporting; a path that trusts the input field alone inverts the error ^[5]. There is no ordering of those two operations that satisfies both providers.

The post cites Langfuse issue #12306, opened February 2026, in which Anthropic cache tokens were double-counted and cost was inflated roughly 2x, and says LiteLLM has its own family of cache accounting issues ^[6][7]. That matters against the only published drift figure the author could find: LiteLLM's cost-discrepancy doc says deltas under roughly 10% between tracked spend and the bill are commonly explained by rounding and boundary effects, and bigger gaps usually mean something was miscounted, dropped or categorized differently ^[8]. The author is explicit that this is a heuristic in a troubleshooting doc rather than a measurement, and still the best public number available ^[9]. A 2x inflation is a 100% delta, about ten times that tolerance band ^[10], which is to say a single misread cache field puts you far outside the range anyone would call noise.

Underneath sits the pricing data. Pydantic maintains genai-prices, a community pricing registry of the kind estimation tools depend on, and its README carries a warning section titled "these prices will not be 100% accurate" ^[11]. The registry exists because providers do not publish exact pricing for the direct OpenAI, Anthropic and Gemini APIs in any reliably machine-readable format, though Azure, AWS and GCP do publish machine-readable SKU prices for their hosted variants ^[12][13].

Then there is coverage. Tracking shows the calls it saw; the invoice shows everything, including the one-off script, the teammate's experiment and the leaked key ^[14]. The author notes that a gateway's figure is authoritative for traffic that passes through it, because the gateway is the party charging you, and useless for traffic that does not ^[15]. Spend management and cloud cost platforms mostly read the provider's billing APIs, which returns the provider's number back to you, organized, and you cannot check a number against itself ^[16].

The disclosed conflict: the author is building Kenda, a reconciliation tool at kenda.app that puts logged costs and billed dollars side by side with the delta per billing period, and says to discount the argument accordingly ^[17][18].

At small scale the honest fix is manual. OpenAI exposes an organization costs endpoint and Anthropic a cost report; pull both, export tracked spend, join by hand, and if they match within noise you are done ^[19]. The author says the pain arrives when you want that answer per key, per feature, per customer, across billing-cycle boundaries rather than calendar months, every month ^[20].

What to watch: whether Langfuse #12306 and the LiteLLM cache issues close with per-provider token normalization rather than a patched multiplier ^[6][7], and whether any dashboard starts labelling how far its evidence goes, the way the author says Kenda distinguishes reconciled from priced from allocated figures and shows unattributable spend as its own line ^[21].