The Real Prices of Frontier Models: Tokens × Price, Right?

The formula on every pricing page – input tokens × rate + output tokens × rate – is correct as arithmetic. As a bill predictor, it’s broken. Three hidden multipliers sit on top of that number, and a recent Playcode benchmark made the core problem impossible to ignore: the same TypeScript file becomes 1,178 tokens on Claude’s newest tokenizer versus 681 on GPT-5.x’s o200k – 1.73x more, before a single cent of price difference. Same code. Different vendor. You’re charged nearly double the token count.

Why “tokens × price” quietly lies

“Token” is not a fixed unit. Each model’s tokenizer cuts the same file into a different number of pieces, and you pay per piece. Put two pricing pages side by side and one looks 20% cheaper – you might actually be looking at a model that costs you 50% more on your specific content, because its tokenizer produces more slices from the same input.

Anthropic demonstrated this on themselves. Per Anthropic’s official pricing docs, Claude Opus 4.7 and later models – including Opus 4.8, Fable 5, Mythos 5, and Sonnet 5 – use a newer tokenizer that produces approximately 30% more tokens for the same text. The exact increase depends on content and workload shape. The per-MTok sticker price is unchanged. Same rate card as Opus 4.6. Same text. About 30% more tokens on the invoice.

The three multipliers most tutorials skip

1. Tokenizer inflation

If you migrated from Opus 4.6 to Opus 4.8, the sticker didn’t change but the token count did. Developer Abhishek Ray measured it on real Claude Code content and found a weighted ratio of 1.325x across seven samples (8,254 → 10,937 tokens). Some file types were worse: CLAUDE.md at 1.445x, technical docs at 1.473x. A community analysis of 483+ submissions found a 37.4% jump.

Cross-vendor comparisons are messier still. Anthropic never promised token parity with GPT. A raw $/MTok comparison between the two is essentially fiction on code-heavy workloads – the units don’t match.

2. Reasoning tokens (the invisible line item)

Reasoning-enabled models – OpenAI’s o-series, GPT-5.x with reasoning on, Claude extended thinking, Gemini thinking modes – generate an internal draft before writing the visible answer. Those drafts are billed at the output rate. They don’t appear in the response body. A complex request can generate 3-10x the reasoning tokens of its visible answer.

Pro tip: Always check the usage object in the API response, not just the visible completion. The reasoning token count sits there. If you’re not logging it, you’re paying for tokens you can’t see and can’t audit.

How bad does it get? An OpenAI community post laid it out: the developer logged 1M tokens on GPT-5 mini/nano, expected ~$5, actual bill was $20. Reasoning tokens billed at the output rate, unaccounted for in the naive formula. Not a bug. Just math nobody showed them.

3. Routing and residency multipliers

Buried in the fine print. For Claude Opus 4.6, Claude Sonnet 4.6, and later models, specifying US-only inference through the inference_geo parameter incurs a 1.1x multiplier on all token pricing categories – input tokens, output tokens, cache writes, and cache reads. Global routing (the default) uses standard pricing. If your compliance team turned that flag on and nobody flagged it to finance, your whole invoice is 10% higher than the pricing page suggests.

The corrected formula

Replace tokens × price with this:

real_cost = (
 (input_tokens_your_tokenizer × input_rate)
 + (output_tokens × output_rate)
 + (reasoning_tokens × output_rate) // if reasoning is on
) × geo_multiplier // 1.0 default, 1.1 for US-only on Claude
- cache_discount // 90% off input on cache hits
- batch_discount // 50% off if using Batch API

Reasoning tokens are billed at the output rate – that’s where most bill shock comes from. And because reasoning is generated fresh on every call, neither caching nor batch discounts meaningfully reduce it. The only lever that cuts reasoning costs is generating less reasoning.

A worked example that would blow up your budget

You’re building a code review agent. You expect about 10,000 input tokens (the diff plus context) and a 500-token review back. You pick Claude Sonnet 4.6 at $3/$15 per million tokens (as of early 2026, per Anthropic’s pricing docs – verify current rates before budgeting).

Naive math: (10,000 × $3 + 500 × $15) / 1,000,000 = $0.0375 per review. Run it 1,000 times a day, that’s $37.50/day. Budgeted.

Real math after migrating to Sonnet 5 with extended thinking on:

Same code. Same task. 2.4x the bill. Nobody warned you because nobody wrote it as a line item.

How to actually measure it before you commit

Anthropic ships a free token counting endpoint – /v1/messages/count_tokens – that returns the token count under whichever model ID you pass, before any real traffic is sent. Use it as a pricing oracle:

1. Take a real sample of your workload – a system prompt, a typical user turn, a representative document.
2. POST it to /v1/messages/count_tokens with your current model ID.
3. POST the exact same content with your target model ID (e.g., claude-opus-4-8 or claude-fable-5).
4. Divide. That ratio is your workload’s actual tokenizer multiplier – not the docs’ average. Yours.

For OpenAI: run your content through tiktoken for both old and new model. GPT-5.x uses o200k; older GPT-4 uses cl100k. Same input, different counts.

What this changes about model selection

Sticker prices are directional, not literal. As of February 2026 (IntuitionLabs API pricing comparison): Grok 4.1 at $0.20 input / $0.50 output, GPT-5.4 at $2.50/$15, Gemini 3.1 Pro at $2/$12, Claude Opus 4.8 at $5/$25 – verify current rates before committing. These numbers are real. The problem is they assume token units match across providers. They don’t.

Grok at $0.20 input is still far cheaper than Opus at $5, even accounting for tokenizer differences. The gap is too big to close. But two similarly priced models – Sonnet at $3/$15 versus GPT-5.4 at $2.50/$15 – can flip depending on workload. On TypeScript-heavy code, Sonnet may bill nearly 2x the tokens of GPT-5.4 for identical files, which more than eats the headline advantage.

The honest cost ranking of frontier models isn’t a table. It’s a function of your content shape.

FAQ

Does prompt caching fix the tokenizer inflation problem?

Partly – but there’s a migration trap people keep hitting. A cache hit costs 10% of the standard input price, which is substantial. The catch: caches are keyed to a specific model version, and a cached prompt sequence from Claude Opus 4.8 does not carry over to Claude Fable 5, because the underlying token IDs differ between tokenizer versions. So the first wave of Fable 5 traffic – even for system prompts you’ve been caching for months – starts cold. Budget for a burn-in period on every model migration. The savings come back, but not on day one.

Is Batch API worth it for reasoning-heavy workloads?

Mostly no. Batch API gives a flat 50% off for async work with results within 24 hours – great for input and visible output. But reasoning tokens are generated fresh per call; the batch discount doesn’t touch them. If 80% of your bill is invisible reasoning (common for agent tasks), Batch API trims only the remaining 20%.

What’s the fastest way to see if I have a hidden-cost problem right now?

Pull one week of API invoices. Divide total spend by total visible tokens (what your app logged). Compare that effective per-token rate to the model’s list rate. If the effective rate is higher than the list rate, the delta is coming from reasoning tokens, tokenizer inflation, or a routing multiplier – in that order of likelihood. One honest caveat: this method only works if your logging is capturing visible tokens accurately. If your app logs completion length rather than the usage object, you’ll undercount and the gap will look worse than it is. Fix the logging first, then run the check.

Next action: Grab your last three days of API logs, pick your top three most-called endpoints, and run each through the token-counting endpoint against both your current model and the next version up. The ratio you get back is the real price change hiding in your next invoice.