Usually, the cost of a language model API call is estimated very simply: open the pricing page, look at the input and output cost per million tokens, multiply by expected volumes, and close the spreadsheet. Then the actual bill arrives, and it differs from the initial estimate by a factor of several times. Sometimes the amount turns out to be lower if someone accidentally hit the cache, but more often than not, budgets burst at the seams due to hidden pricing factors. Developers and product owners discover that the unit economics of requests diverge radically from the base provider pricing.
As noted by the author of the breakdown, all baseline rates and terms rely on official documentation from OpenAI, Anthropic, and Google. Providers charge for tokens rather than requests or characters, so the call cost consists of several components with their own price tags. This structure includes uncached input, input read from the cache, input written to the cache, visible model output, and user-hidden reasoning tokens.
The output almost always costs more than the input. In the current pricing of the three major providers, the difference for most models ranges from four to eightfold, meaning a long response is guaranteed to cost more than a long prompt. Reasoning sits inside output tokens, making it the most expensive component, while the cache multiplies only the largest input component by a small coefficient, and only under the condition of an exact prefix match down to the last token. Meanwhile, the multiplier $r$ is typically 0.1 or lower for some newer models, showing how much cheaper cache reads are. At the same time, the write multiplier $w$ is 1.25 for Anthropic's five-minute cache and for OpenAI models with paid writes, while for Anthropic's hourly cache, this coefficient is 2.
Let's break down the actual mechanics using a production example. Imagine a typical enterprise pipeline for analyzing long documents: the system sends a 100,000-token context (of which 80,000 are successfully retrieved from the cache) and requests a detailed report with reasoning of 2,000 tokens on the output from the model. If the provider uses a base write multiplier $w = 1.25$ for new cacheable blocks and a read coefficient $r = 0.1$, the costs of writing the missing 20,000 tokens and reading 80,000 tokens from the cache begin to dominate simple linear multiplication. Moreover, when scaling such a request to 10,000 calls per day, any minor error in prefix accounting causes the cache to drop, forcing the system to pay the full price for every token at the maximum input rate instead of cheap reads. In practice, this turns predictable monthly inference costs into an unstable expense line where a single failed session with frequent context updates can completely burn through the daily budget.
API pitfalls and cache reading rules
All token volumes are recorded in the API response within the usage object, but providers name the fields differently and calculate them under distinct rules. The most treacherous discrepancy emerges specifically on the input side. For OpenAI and Gemini, the total input already includes cached tokens, and to get the portion you pay full price for, you must subtract the cache. For Anthropic, it is the exact opposite: input_tokens represents only the tail after the final caching point. If you write a universal handler and try to subtract the cache from Anthropic's input when a long context is present, the response will return a negative number.
For OpenAI and Anthropic, reasoning is already included in output tokens, whereas for Gemini, it must be added separately.
Models behave similarly with outputs, but in a mirror image. For OpenAI and Anthropic, reasoning is already included in output tokens, whereas for Gemini, the reasoning token must be added to the output tokens separately. If you overlook this architectural quirk, Google's model will look noticeably cheaper in reports than it actually is.
Tokenization growth and tiered tariffs
An additional surprise for developers comes from the shifting internal algorithms of the providers themselves. On top of that, some providers use tiered pricing: if the total input volume together with the cached part exceeds a set threshold, all prices in the formula automatically switch to higher rates. This introduces additional risks for developers trying to optimize costs by expanding context, only to end up in a more expensive pricing tier.
In our view, such opacity in calculations is not an accidental documentation bug, but a deliberate architectural trap for business. While companies build long-term product strategies around LLMs, providers shift all inference volatility onto their shoulders, turning scaling into a game of budget Russian roulette.