The real prices of frontier models

Why $/MTok Is a Nominal Price, Not a Real Price

The rate card you see on an AI provider's pricing page is the nominal price — and like the nominal price of oil or gold, it can mislead without an adjustment for the underlying unit of measurement. A recent analysis published by the PlayCode team sets out to quantify how far the real prices of frontier models can diverge from their sticker costs. According to that analysis, the gap can be large enough to change how competing models rank against one another. The figures below are drawn from PlayCode's write-up; we have not independently reproduced its token counts, and readers should treat them as the analysis's own measurements rather than settled fact.

The mechanism is the tokenizer: every vendor converts your text into tokens before billing, but no two tokenizers necessarily produce the same token count from the same content. That hidden variable means developers comparing $/MTok across providers may be comparing figures that aren't on the same scale. In PlayCode's worst-case fixtures, the effective cost gap approached — but did not exceed — roughly 1.7x versus a fixed reference tokenizer.

In macroeconomics, the distinction between nominal and real prices is foundational. The nominal price of oil might hold steady at $80 per barrel, but if the barrel quietly shrank, the real price would have risen. Analysts who adjust the real prices of gold or oil for inflation before drawing conclusions apply the same logic developers can apply to API billing. Here, the "barrel" is a token, and every vendor defines it differently.

A token produced by OpenAI's o200k_base tokenizer is not necessarily the same quantity of text as a token produced by Anthropic's or Google's tokenizer. When you send identical source code to two APIs priced at the same $/MTok, they may bill you for different numbers of tokens, producing different invoices. The list price is the nominal price. What you actually pay per byte of content is closer to a real price — and that figure requires a multiplier providers generally don't publish.

Why it matters: Two models can list the same "$5.00 / 1M input tokens" and still produce different bills for the same paragraph if one of them turns that paragraph into more tokens. The rate card is only half the equation; the tokenizer multiplier is the other half.

To make model prices comparable, PlayCode used OpenAI's o200k_base tokenizer as a fixed reference baseline — publicly documented and stable — and measured how many more or fewer tokens each other vendor's tokenizer produces from identical content. The resulting multiplier converts list prices into effective prices: an estimate of the real cost to process the same text.

The Methodology: Real-World Fixtures Run Through Each Tokenizer

Rather than relying on synthetic benchmarks, the analysis ran a set of real content fixtures through each provider's tokenizer. Per PlayCode, the fixture set was deliberately diverse, spanning content types common in production AI applications:

• English prose
• HTML pages
• JavaScript, Python, TypeScript, and Rust source files
• JSON tool schemas and tool result payloads
• An agent system prompt (reported at 42,661 characters)
• Chinese chat messages and Chinese prose
• Symbol-heavy text

PlayCode reports that token counts came from primary tokenization sources rather than approximations. For Anthropic, it used the official count_tokens API endpoint; for OpenAI, the open-source tiktoken library with the o200k_base vocabulary; and for Google and xAI, each provider's own token-counting endpoints. We were unable to independently verify these counts or any cross-checks against live billing, so the numbers below should be read as PlayCode's reported results.

The analysis notes that some open-weight and Chinese-lab models were excluded because only rough token estimates — not auditable counts — were readily available for them. That opacity around tokenization is itself a form of pricing opacity, and it warrants caution when evaluating cost claims for any provider whose tokenizer cannot be inspected directly.

The Reported Anthropic Tokenizer Change

The most striking finding in the analysis concerns Anthropic. PlayCode reports that between an older Claude tokenizer and a newer one, identical English and code content generates roughly 30–32% more tokens, with no change to the published $/MTok list price. The effect is said to concentrate in English text and code, while Chinese text is essentially unchanged. Because model naming and availability change quickly, we describe the affected models using the analysis's own labels; readers should confirm current model names and prices against Anthropic's live pricing page before budgeting.

Content Type	Old Tokenizer (tokens)	New Tokenizer (tokens)	Increase
English prose (2,115 chars)	476	636	+34%
HTML page (3,195 chars)	1,131	1,302	+15%
JavaScript (1,933 chars)	659	794	+20%
Python (2,251 chars)	831	1,022	+23%
TypeScript (2,888 chars)	898	1,178	+31%
Rust (2,924 chars)	1,019	1,312	+29%
JSON tool schema (9,948 chars)	2,631	3,306	+26%
Agent system prompt (42,661 chars)	10,761	14,953	+39%
Chinese prose (379 chars)	435	433	~0%

The agent system-prompt case is notable in the reported data: a 42,661-character prompt is said to rise from 10,761 to 14,953 tokens — a 39% increase. For a developer running long agentic sessions where a large system prompt accompanies every API call, a change of that size would be a meaningful hidden cost increase. Because cache traffic is billed per token too, a tokenizer that inflates token counts would make cache writes and cache reads proportionally more expensive at the same time. On long agent sessions where cache reads dominate the bill, that compounding effect could be significant.

Per PlayCode's framing, shipping a new model at the same $/MTok while its tokenizer produces materially more tokens per byte is, in accounting terms, an effective price increase that never appears as a line item on an invoice.

We could not find an Anthropic announcement characterizing this as a price change, and we make no claim about Anthropic's intent. What we can say is narrower and arithmetic: if a new model uses a tokenizer that produces ~32% more tokens from the same content at an unchanged $/MTok list price, then the effective (real) cost to process that content rises by roughly the same proportion. That is precisely the dynamic that separates nominal from real prices in commodity markets, and buyers should account for it directly by measuring tokens on their own content rather than assuming a stable list price means stable cost.

Cross-Vendor Real Prices: The Reported Multiplier Table

Normalizing all models to the same reference baseline (OpenAI o200k_base = 1.00x) is how PlayCode illustrates the divergence between real and nominal prices. The multiplier is content-dependent: in the reported fixtures, TypeScript is the worst case for Claude's newer tokenizer (1.73x), while Chinese text tokenizes more efficiently on Google's and xAI's tokenizers than on OpenAI's, giving those providers a relative real-price advantage for Chinese-language workloads. The table below reproduces PlayCode's reported multipliers and uses the analysis's own model labels.

Content Type	Claude (new tokenizer)	Claude (old tokenizer)	Gemini Flash	Grok
TypeScript	1.73x	1.32x	1.16x	1.05x
Rust	1.58x	1.22x	1.19x	1.05x
JavaScript	1.52x	1.26x	1.23x	1.11x
Python	1.50x	1.22x	1.20x	1.09x
JSON tool schema	1.46x	1.17x	1.11x	1.06x
Agent system prompt	1.54x	1.11x	1.07x	1.04x
HTML page	1.36x	1.18x	1.08x	1.04x
English prose	1.40x	1.05x	1.01x	1.00x
Chinese prose	1.44x	1.45x	0.85x	0.86x
Chinese chat	1.53x	1.55x	0.91x	0.92x

For a developer building primarily in TypeScript — a dominant language of web back-ends and a common target for AI coding agents — Claude's newer tokenizer would, on these fixtures, bill for about 73% more tokens than OpenAI's reference for identical files. In the reported data, xAI's Grok tracks closest to OpenAI's reference across the code types tested, while Google's Gemini Flash sits in the middle of the distribution for code but shows a relative real-price advantage for Chinese-language content.

Real Effective Prices: The Reported Frontier Model Comparison

To turn multipliers into dollars, PlayCode applies each model's measured multiplier (using a blended figure in the ~1.5x range for typical English coding-agent workloads on Claude's newer models) to publicly listed prices, producing the effective-price comparison in the source analysis. Prices are expressed as a dollar-equivalent per million tokens at the reference tokenizer scale — the estimated cost to process the same volume of text. Important caveat: the list prices and model names in the table below are as reported by the analysis at the time it was written; model lineups and pricing change frequently, so verify each figure against the vendor's live pricing page before relying on it. Where the table applies a single ~1.5x factor to a Claude row, note that the per-content multipliers above range from roughly 1.36x to 1.73x, so the true figure depends on your content mix.

Model (as labeled by the analysis)	List Price (in / out, $/MTok)	Tokenizer Multiplier	Effective Price (in / out, $/MTok equivalent)
Gemini Flash tier	$0.50 / $3.00	1.09x	$0.55 / $3.27
GPT (reference tokenizer, lower tier)	$1.25 / $10.00	1.00x	$1.25 / $10.00
Grok tier	$2.00 / $6.00	1.03x	$2.06 / $6.18
Claude Sonnet (new, introductory)	$2.00 / $10.00	~1.5x	~$3.00 / ~$15.00
Claude Sonnet (previous generation)	$3.00 / $15.00	1.14x	$3.42 / $17.10
Claude Sonnet (new, post-introductory)	$3.00 / $15.00	~1.5x	~$4.50 / ~$22.50
GPT (reference tokenizer, higher tier)	$5.00 / $30.00	1.00x	$5.00 / $30.00
Claude Opus (previous generation)	$5.00 / $25.00	1.14x	$5.70 / $28.50
Claude Opus (new)	$5.00 / $25.00	~1.5x	~$7.50 / ~$37.50
Claude premium tier (new)	$10.00 / $50.00	~1.5x	~$15.00 / ~$75.00

The point the analysis draws out is that some rankings invert once real prices are computed. In the reported data, a new Claude Opus that lists at the same $/MTok as the previous generation carries a materially higher effective input price once the tokenizer multiplier is applied. A new Claude Sonnet's introductory pricing looks aggressive on paper, but the multiplier can bring its real input cost close to what the prior Sonnet costs after its own, smaller multiplier — and once introductory pricing lapses and the list price rises, its real effective price can exceed its predecessor's. These are conditional, arithmetic conclusions that follow from PlayCode's multipliers; they are only as accurate as the underlying token counts, which we have not independently reproduced.

In the same reported comparison, Google's Gemini Flash tier stands out as the real-price leader for English and code content: a $0.50/$3.00 list price becomes roughly $0.55/$3.27 after adjustment. For workloads where that model's quality is sufficient, the effective real-price gap versus Claude's newer models is large — on the order of several-fold cheaper on input in effective terms.

Independent Production Signal

PlayCode also cites a real-world migration report from a company it identifies as Ploy, which moved a production workload from a newer Claude Opus to a GPT model. For identical builds, the report is said to record roughly 1.70M input tokens on the GPT model versus 2.60M on Claude — about 35% fewer tokens on GPT. As PlayCode itself notes, this figure folds in model output verbosity differences, not just tokenization efficiency, so it cannot be attributed purely to the tokenizer. We were unable to verify this third-party report independently; we present it as corroborating direction rather than as a precise, confirmed measurement of tokenizer divergence.

What the Real Prices Miss: Output, Thinking, and Whole-Task Cost

The tokenizer analysis covers input tokens only. Output token counts — how many tokens a model generates to answer the same prompt — are determined by model behavior, not tokenizer design, and they vary significantly across providers. Extended thinking or reasoning modes add another layer: a model that reasons before answering spends tokens on that internal reasoning, and you may or may not be billed for those tokens depending on the provider's configuration.

A Companion Per-Task Benchmark

The analysis references a companion benchmark it calls a "pelican" drawing benchmark that measures per-task costs end to end, including both input and output tokens. In that benchmark, PlayCode reports that the same drawing task ranged from roughly $0.004 to $0.80 per completion depending on the model and reasoning configuration — a span it characterizes as large enough to make tokenizer differences look modest by comparison. We have not independently reproduced this benchmark; it is presented as the analysis's own result. The broader point stands on its own logic: whole-task cost, expressed as dollars per completed task rather than dollars per token, is the metric that most fully captures the real trade-offs between models.

As the analysis puts it, reports that one model "uses 2–4x the tokens" of another on agent work can be true for a given setup even though the pure input-tokenization gap in these fixtures never exceeded about 1.73x — because the two numbers measure different layers of cost.

This distinction matters when engineering teams evaluate and budget for models. A model that is verbosely correct — producing thorough, well-structured output — may spend more output tokens but require fewer retries, which could lower the cost per successful task even when raw token counts are higher. These interactions are invisible in any rate card and can't be inferred from $/MTok alone.

How to Compare Frontier Model Prices Properly

The analysis closes with a practical framework developers can apply now to estimate real prices from nominal ones:

1. Measure on your own content. Your specific language mix and file types determine your tokenizer multiplier. A JavaScript-heavy codebase has a very different multiplier profile than a Chinese-language chatbot. Run a representative sample of your actual production content through each provider's tokenizer endpoint — count_tokens for Anthropic, tiktoken for OpenAI, and each vendor's counting endpoint for others — before trusting any rate-card comparison.
2. Treat a tokenizer change as a potential price change. When a vendor ships a new model at the same list price, check whether the tokenizer vocabulary changed. If it produces more tokens per byte, the effective cost has risen even though the list price hasn't. Treating a nominal price as stable when the tokenizer has changed is analogous to treating the nominal price of oil as stable when barrel sizes have changed.
3. Measure dollars per completed task, not dollars per token. This single metric folds in tokenization multipliers, output verbosity, thinking-token overhead, and caching costs simultaneously. The usage field in most API responses gives you the raw numbers to compute it per call; aggregate across a representative sample of real tasks to get a reliable figure.
4. Use $/MTok as a starting point, not a conclusion. It's a useful signal for rough order-of-magnitude comparisons but insufficient for budget planning, and it's structurally incomparable across providers with different tokenizers.
5. Advocate for per-byte pricing. Vendors could reduce this class of opacity by publishing prices per kilobyte of input text — a figure that would be immediately comparable across providers and require no tokenizer archaeology. Until one does, the adjustment work falls on the developer.

The Case for Per-Byte Pricing

The per-byte pricing point is worth sitting with as a policy observation. There's no obvious technical barrier preventing AI providers from quoting prices in dollars per kilobyte of input text. That convention would be immediately comparable across vendors, would eliminate the need for developers to reverse-engineer tokenizer ratios, and would surface tokenizer changes as explicit price changes rather than leaving them to be inferred from model release notes. To our knowledge, no major provider has adopted it as its headline pricing unit — despite the apparent benefit to buyers — and that's worth noting when evaluating the transparency of the AI infrastructure market. The real-prices-vs-nominal-prices problem in frontier AI billing is, at the level of pricing design, straightforward to solve; it persists largely as a disclosure choice.

---

Key Takeaways

• $/MTok is a nominal price. Estimating the real price of a frontier model requires multiplying by a tokenizer-divergence factor — the ratio of tokens generated from identical content relative to a fixed reference baseline (OpenAI's o200k_base). The analogy to real prices of oil or gold is apt: the unit must be held constant before prices are comparable.
• PlayCode reports a large tokenizer shift at Anthropic. A newer Claude tokenizer is said to generate roughly 30–32% more tokens than the previous one for English and code, at unchanged list prices — which, arithmetically, raises the effective cost by a similar proportion. We could not independently verify these counts or confirm any Anthropic statement about the change.
• The reported worst case is about 1.73x for Claude's newer tokenizer on TypeScript — the most extreme single-content-type divergence in the fixture set, per the analysis.
• Google's Gemini Flash tier is the reported real-price leader for English and code content, with a modest ~1.09x multiplier on top of a low $0.50/$3.00 list price, for an effective input price near $0.55/MTok equivalent.
• xAI's Grok tracks closest to OpenAI in tokenizer efficiency in the reported data, with a multiplier that rarely exceeds ~1.11x across tested content types.
• Cache costs scale with the tokenizer multiplier too, which would make any real cost increase particularly acute for long agentic sessions where cache reads dominate the bill.
• Introductory Claude pricing eventually lapses. When it does, per the analysis, the real effective input price can rise by roughly a third — potentially making a newer Sonnet more expensive in real terms than its predecessor.
• Output tokens and model verbosity are not captured by the tokenizer analysis and can drive whole-task cost divergence well beyond the ~1.73x tokenizer ceiling — up to the wide range seen in the referenced per-task benchmark.
• A third-party production migration points the same direction: one company's move to a GPT model reportedly recorded roughly 35% fewer input tokens for identical work, though that figure also reflects output-verbosity differences.
• The fix exists in principle: providers could publish prices per byte of input text, largely eliminating the problem. To our knowledge, no major provider has adopted it as its headline unit.

Pressure for cleaner pricing disclosure will likely grow as AI infrastructure becomes a line item that engineering-finance teams scrutinize seriously. Developers who instrument their applications to track cost-per-task rather than cost-per-token will be better positioned to make vendor decisions on real evidence — and to notice quickly when a tokenizer change quietly rewrites their budget. Until AI providers adopt per-byte pricing or another transparent standard, much of the burden of computing real prices of frontier models from nominal ones falls on the buyer. Just as analysts adjust the real prices of oil and gold for inflation and unit changes before drawing conclusions, developers can adjust API prices for tokenizer divergence before drawing budget conclusions — ideally by measuring on their own content rather than trusting any single third-party table, this one included.