Last week North told you a new model won't save you. Today she's after the number you use to shop for one. Every rate card in this market leads with dollars per million tokens, and leaders line them up like grocery prices — $5 here, $10 there, buy the cheaper one. North Wayne has bad news about that reflex: the token isn't a fixed unit, so the sticker isn't a comparable price, and a same-price “upgrade” can be a real increase that never appears on your invoice. If model spend is on your board deck this quarter, read this before the next comparison. — Muximus
The same TypeScript file becomes 1,178 tokens on Claude's newest tokenizer and 681 on GPT's - 1.73 times as many - before a cent of price difference enters the picture. You pay per token. So the number you compare on a vendor's rate card is not the number that lands on your bill.
That gap is the whole problem with how most teams are budgeting for AI right now. Every frontier vendor leads with one figure: dollars per million tokens. You line them up in the board deck - $5 here, $10 there - and treat the cheaper sticker as the cheaper model. It's a reasonable-looking comparison. It is not a safe one, and I want to show you exactly where it breaks before you build a budget on it.
The framework: a bill is two numbers, and the card only prints one
Start with how the bill is actually assembled. It's two numbers multiplied together: how many tokens your content becomes, times the price per token. The rate card publishes the second number and quietly treats the first as a constant. It is not a constant. It's a property of the vendor's tokenizer - the software that chops your text into the billable pieces called tokens - and tokenizers differ a lot between vendors. Two models can both advertise “$5.00 per million input tokens” and hand you meaningfully different bills for the same paragraph, because one of them cuts that paragraph into more pieces.
Nobody publishes a tokens-per-content number, so Playcode went and measured it. Playcode sells access to these same models, so it has an interest in the comparison - I'll take the numbers anyway, because the method is the part that holds up. They counted 16 real fixtures - English prose, HTML, TypeScript, Rust, JSON tool schemas, Chinese text, their own agent's system prompt - using each vendor's own token-counting endpoint, then cross-checked those counts against real paid requests. The prose was AI-drafted and human-edited; the numbers are measured.
The cross-vendor result, against GPT's o200k tokenizer as a fixed 1.00x reference (chosen because it's been frozen and documented for over two years): Anthropic's newest tokenizer runs 1.36x to 1.73x more tokens on identical files. The gap is worst on code - TypeScript 1.73x, Rust 1.58x, JavaScript 1.52x, Python 1.50x - against 1.40x for English prose. Grok 4.5 sits near 1.03x and Gemini 3 Flash near 1.09x. Code is most of what a coding agent reads all day, so for that workload the 1.50x-to-1.73x band is the one that hits your budget.
The trade-off you're not being shown: a price rise with no line item
Here's the part that should change how you read a launch announcement. Anthropic's newer models - Sonnet 5, Opus 4.8, Fable 5 - use a new tokenizer. The older ones - Sonnet 4.6, Opus 4.6 - use the previous one. Counted on Anthropic's own endpoint, the new tokenizer produces roughly 30% more tokens from the same content than the old one did: English prose up 34%, TypeScript up 31%, Rust up 29%, a real agent system prompt up 39%. Weight those the way an actual request is composed - mostly English instructions, tool schemas, code, and JSON - and it lands around 32% more tokens per request.
Now hold that against the rate card. Opus 4.6 and Opus 4.8 carry the same $5.00 / $25.00 list price. The list price did not move; the token count did. And this was verified against real invoices, not just a counter: one content sample billed 2,541 input tokens on Opus 4.6 and 3,191 on Opus 4.8 - same words, same rate card, each number matching its prediction. Across a full, realistically composed request, the gap averages about 32%.
Read that slowly, because it's the decision hiding inside a routine “we upgraded to the latest model” note. In cost terms, a same-price upgrade was a price increase of roughly a third - and it appears on no invoice as a rate change, because the rate genuinely didn't change. The tokenizer did. (Measured the other way, against GPT's reference tokenizer, Playcode models Opus 4.8's advertised $5 / $25 as behaving like an effective $7.50 / $37.50 on a typical coding request. That's a modeled figure - list price times the roughly 1.50x cross-vendor divergence, not a number off an invoice. Same story, different yardstick.)
This is the same trap I flagged last week when I told you a new model won't save you: the sticker price is not the invoice. There it was your workflow multiplying the bill. Here it's the tokenizer, moving underneath a number you thought was fixed.
The one that catches the planners: the “intro price”
Sonnet 5 is where this bites the people who actually plan ahead - which, if you're reading a First Opinion, is you. It launched at $2.00 / $10.00, down from Sonnet 4.6's $3.00 / $15.00. Reads like a price cut. Two things are true about that number, and you need both. First, it's an introductory price, and it ends on August 31, 2026. Second, the new denser tokenizer is sitting underneath it. While the intro rate lasts, the lower price slightly more than absorbs the extra tokens, so Sonnet 5 does come out a little cheaper than 4.6 for the same code - a genuine deal, with an expiry date.
From September 1, the price returns to $3.00 / $15.00, the denser tokenizer stays, and the same work costs about a third more than it did on Sonnet 4.6 at the very same list price. A budget built today on the $2 / $10 sticker isn't just optimistic - it's wrong on a date you can already write in the calendar. Fable 5, for completeness, lists $10 / $50 and runs the same new tokenizer, so its effective price models out near $15 / $75. There's no hidden markup behind the higher sticker; it's the same tokenizer, priced higher. Fair, once you know to look.
Where it compounds, and where it stops mattering
Two honest extensions, one in each direction, because I'm not going to hand you a scare without its limits.
It compounds through caching. Cache reads and writes are billed per token like everything else, so a tokenizer that produces 32% more tokens makes every cache read about 32% more expensive too - and on long agent sessions, cache reads are most of the bill, not a rounding error.
And it stops mattering sooner than a tokenizer obsessive would like. Input tokenization is exactly one layer of the cost. How verbose the model is, how many thinking tokens it burns to reach the same answer, how much context the harness reloads each step, how often it calls tools or spawns sub-agents, and - the big one - how the caching is configured: all of that can move a whole-task bill far more than 1.73x, in either direction.
The cautionary tale here is Ploy, a website-building agent company that moved its production agent from Opus 4.8 to a competitor's model, GPT-5.6 Sol, and published the numbers - so, like Playcode, an interested party whose method you can check. On the same builds, Claude ran 2.60 million input tokens to GPT's 1.70 million, about 35% fewer for GPT, directionally in line with the tokenizer gap, though these are whole-task numbers that fold in verbosity too. But Ploy's sharper lesson was about a trap, not a winner. Before they fixed a cold-cache misconfiguration, GPT-5.6 looked about 50% more expensive than Opus. The model pricing was fine the entire time; their cache setup wasn't. Only after the fix did GPT-5.6 come out 27% cheaper. Their words: cost comparisons between models are useless when one model starts with a cold cache. The tokenizer is real. It is not the largest term in your bill.
One more thing, plainly, because the numbers invite the wrong conclusion: a denser tokenizer says nothing about model quality. GPT and Claude land roughly even on output quality despite the token-count gap, and plenty of teams keep paying the Claude premium precisely because the result is worth it. This is not “Claude is worse.” It's “the price you compared is not the price you'll pay.”
The verdict
Don't budget on dollars per million tokens. It's a fine opening line and a bad basis for a decision, because it isn't comparable across vendors and it quietly changes underneath a fixed rate card. I've watched teams pick the cheaper sticker and get the larger invoice; it's an avoidable mistake, and here's how you avoid it.
Four moves for the operator holding this decision:
- Compare on your own content. Your languages and file types set your multiplier - TypeScript is the worst case, Chinese barely moves - so run a representative sample through each vendor's token counter before you trust a rate card.
- Treat any same-price upgrade as a suspected price change. When a vendor ships a new model at the same list price, check whether the tokenizer moved. Opus 4.6 to 4.8 was roughly a 32% increase with nothing on the invoice to show for it.
- Budget on dollars per completed task, not dollars per token. That one number folds in tokenization, verbosity, thinking, and caching at once, and the provider's own
usagefield gives you the ground truth to compute it. - If you run on Sonnet 5, put September 1, 2026 in the forecast now. The intro price ends; the token count doesn't.
None of this makes one vendor the answer - that's not the call today. It makes the sticker the wrong place to look. The number you can actually compare is the one you compute yourself, on your own work, after the tokenizer has had its say.
