Why two models with the same sticker price can bill differently

The assumption that quietly breaks a migration

Two models with an identical advertised per-token rate look, on paper, like they should bill identically for the same task — and that assumption is wrong often enough to be worth calling out directly, because the sticker price is only half of what determines an actual bill. The other half is how many tokens the same input and output actually turns into, and that number is not guaranteed to match across models sharing a headline price.

Different tokenizers mean different token counts for the same text

The current lineup isn't running one shared counting scheme underneath its pricing — different generations within the same tier can carve up identical text into a different number of pieces, which means the sticker price and the actual bill are answering two different questions. A price cut, or even a price held flat between two generations, tells you nothing about whether the bill went up or down once you account for how many billable units that unchanged price is now being multiplied against. See why your token-count estimate was wrong for exactly how large that shift can be between two specific generations.

Thinking defaults are not consistent across models either

Beyond tokenizer differences, whether thinking runs by default — and how much of it runs — varies by model, independent of sticker price. Two models at the same advertised rate, one with thinking off by default and one with it on, will bill differently for the identical prompt purely because one of them is spending billable tokens on a reasoning step the other isn't running at all. This compounds with the tokenizer difference rather than replacing it — both effects can be present on the same migration simultaneously.

Cache minimums differ too, and that changes effective cost at scale

A prompt that caches cleanly on one model can fall below another model's minimum cacheable prefix length even at an identical sticker price, meaning the same request pattern earns caching savings on one and pays full price on the other. At any real request volume, that gap compounds into a meaningful difference in effective cost per request, entirely independent of the two models' identical headline rate.

Fast-mode availability adds a further variable at an identical base price

Even setting tokenizer and thinking differences aside, two models sharing a headline rate don't necessarily share the same fast-mode situation — one might support a faster response tier at its own separate premium, while the other doesn't offer that option at all, or offers it at a different premium. For a latency-sensitive integration comparing two same-priced models, that gap can matter as much as anything else on this list, and it's easy to miss specifically because it doesn't show up unless you go looking for it on each model's own page rather than assuming it's symmetric.

Why this matters most right at a migration boundary

All of these gaps matter most in the narrow window right after a model swap, before anyone's had a chance to notice the bill moved for reasons that weren't in the release notes' headline pricing section. Re-baselining actual cost immediately after any model change — not just checking that the sticker price looks the same — is the single habit that catches this category of surprise before it's had a chance to compound across a full billing cycle.

The only reliable way to know

Sticker price comparison is a starting point, not a conclusion — the only way to know what two models actually cost for your specific workload is to run your real prompts through both and compare actual token counts and cache behaviour, not just quoted rates. The token & cost estimator does exactly this, pricing the same text across every current model side by side, and the minimum-cacheable-prefix table covers the caching half of this gap specifically.