The price of a token has stopped meaning what you think it means

A number that used to be simple

For a while, comparing model costs was almost embarrassingly easy: look at the per-token rate, multiply by roughly how much text you send, and you had a number worth trusting. That number is still published, still accurate as far as it goes, and still not nearly enough on its own anymore. The per-token rate answers "what does a token cost." It doesn't answer "how many tokens does my request actually turn into," and that second question has quietly become the one that actually decides your bill.

The unit of measurement moved, and the price tag didn't say so

Treating a sticker price as the whole story rests on an unstated assumption: that a token is a consistent, portable unit you can carry from one comparison to the next. That assumption is what's actually broken, not the arithmetic built on top of it. Two models can carry the exact same advertised rate and still bill differently for identical input, because the thing being priced — a token — isn't the same-sized unit on both of them. A sticker price is a rate attached to a unit that quietly changed size, and the price tag has no way to tell you that happened.

Why you can't fix this by padding your estimate

The natural instinct once you know about this gap is to build in a safety margin — add a percentage on top of whatever number you're working with and move on. That instinct assumes the gap is a constant, and treating it that way is itself the mistake: the size of the mismatch shifts with content type and with which specific model generation is doing the counting, which means a margin wide enough to cover your worst case on one kind of request is needlessly wasteful on another, and a margin sized for your typical request can still fall short exactly where being wrong costs the most.

Thinking tokens are the other half of what the sticker price doesn't show

On models where extended reasoning runs by default, the tokens spent thinking before an answer is produced are billed as output, even though they never appear anywhere in the visible response. A request that looks, from its input and its answer, like it should have cost a specific amount can cost meaningfully more once thinking overhead is accounted for — and higher effort settings widen that gap further, since they're specifically designed to think longer. None of this shows up in a sticker-price comparison, because a sticker price describes a rate, not a request.

What actually replaces the old mental model

The fix isn't a better rule of thumb — every rule of thumb we've tried publishing internally while building this site's own tools has eventually broken on some combination of model, content type, and effort level that didn't fit the pattern. The fix is treating "what will this actually cost" as a question that has to be computed against your real text and your real model, not estimated from a published rate. That's the entire premise this site's tools are built on: paste your actual content, pick your actual model, and get the actual number rather than an approximation of one.

Why this matters even if you're not actively budgeting today

The teams most exposed to this shift are the ones who built a cost model once, when a sticker-price comparison was still close enough to reality to be useful, and haven't revisited it since. Every model generation since has moved the ground under that original comparison a little further, and none of those individual moves announced itself as a reason to redo the math. If your current cost understanding predates the model you're actually running today, it's worth re-deriving from scratch rather than trusting that whatever adjustment you made last time still covers the gap.

The comparison this breaks most badly: shopping across model generations

The place this gap does the most damage is a team comparing an older model generation against a newer one purely on sticker price, concluding the older one is cheaper, and never re-running the comparison against actual counted tokens for their real workload. Depending on the specific text involved, the newer, "more expensive per token" model can land close to cost-neutral, or even cheaper in practice, once the actual token count is accounted for rather than assumed proportional to the sticker price alone. A comparison run on rates alone, without a real count behind it, isn't a comparison — it's a guess wearing a spreadsheet.

See the token & cost estimator to see this gap directly on your own text, and why two models with the same sticker price can bill differently for the fuller breakdown of every mechanism that drives this apart.