A finance leader hands you a spreadsheet ranking three LLM providers by published $ per million output tokens. Explain why the ranking is misleading even when the prices are accurate, and describe the comparison you would run instead. Cover the role of tokenizer family, the typical magnitude of the gap, and the unit that actually matters to a buyer.
Each provider's tokenizer turns the same text into a different number of tokens. $/M-token rates compare only within a family; across providers, normalize to a shared source corpus.
Imagine three coffee shops all charging $5 per cup. Sounds equal, until you notice their cups hold different amounts: 8 oz, 12 oz, and 16 oz. The dollar per cup price tells you nothing about who is cheapest per ounce of coffee. LLM tokens work the same way. Each provider has its own cup size, that is what a tokenizer is, and the same paragraph of text needs more or fewer cups depending on whose cup you use. To compare honestly you have to convert back to ounces, which is to say, to the actual amount of text. Tokenize the same paragraph through each provider's tokenizer, count the cups you got, multiply by the per-cup price, and only then can you say who is cheaper.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Token-based pricing is the standard for LLM APIs because it maps naturally to the cost the provider actually incurs (each token is roughly one forward pass through the decoder). For a single provider the unit is internally consistent: the input token you are billed for is the same token the model processes.
The trap appears when you put two providers next to each other on a spreadsheet. A token at provider A is not a token at provider B. They were defined by different BPE training runs on different corpora with different vocabulary sizes. The same sentence, the same response, the same document fragments into different counts of tokens at each provider. A $/M-token price is honest within a tokenizer family and meaningless across families until you normalize.
This question is testing whether you can name the mechanism (tokenizers differ across providers), quantify the gap (typically 10 to 30 percent on English, larger on code and non-English), and describe the honest comparison workflow (tokenize a shared corpus through each tokenizer, multiply by rate, compare dollars). The teaching opportunity is to translate this into a concrete procurement process that the finance team can actually run.
Why tokenizers differ at all
A BPE tokenizer is trained, not designed. The training procedure starts with bytes (or unicode characters) and iteratively merges the most frequent adjacent pairs until the vocabulary reaches a target size (typically 50k to 200k tokens). The output is a deterministic segmentation function from text to integers.
Two things vary across providers:
-
Training corpus. OpenAI's tiktoken was trained on a corpus heavy in English web text and code. Llama-3's 128k vocabulary was trained with more multilingual coverage. Anthropic's tokenizer has its own training mix. Different corpora produce different merge frequencies and therefore different vocabularies.
-
Vocabulary size. Larger vocabularies (200k+) can encode common phrases as single tokens, reducing token count on familiar text but bloating the embedding table. Smaller vocabularies (50k) keep the embedding small but split common phrases into more tokens. Llama-3 moved from Llama-2's 32k to 128k specifically to shrink token count on long contexts.
The consequence is that 'tokenize the same sentence' produces different integers and different counts across providers. The same Wikipedia paragraph might be 200 tokens on OpenAI, 230 on Llama-3, 250 on an older provider. The same JSON response might be 80 tokens on Anthropic and 100 on a different provider. These differences are deterministic and measurable; the procurement question is whether you bother to measure.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Comparison unit | Tokenizer-independent? | What it tells you | When to use |
|---|---|---|---|
| $/M tokens (headline) | No, family-specific | Provider's pricing within its own unit | Within-family rate changes only |
| $/M characters input + $/M characters output | Yes | Honest cross-provider total cost | Procurement decisions |
| $ per representative request | Yes (corpus-fixed) | Practical real-traffic cost | Pre-purchase load testing |
| $ per delivered useful answer | Yes (semantic) | What the buyer actually cares about | Production cost dashboards |
Real products, models, and research that use this idea.
- OpenAI's tiktoken library is published precisely so procurement teams can count tokens for their corpus before signing a contract.
- Anthropic publishes a count_tokens endpoint for the same purpose; treat 'we estimated' as a procurement red flag.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat workloads see the largest tokenizer-driven cost variance across providers?
Non-English text (especially CJK and morphologically rich scripts), source code with many novel identifier patterns, and structured JSON outputs. Tokenizers trained predominantly on English web text fragment those domains more heavily, sometimes 2x to 3x. Always benchmark on your actual workload.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating $/M tokens as a universal price unit across providers. Tokens are vocabulary-specific; the same sentence is a different number of tokens at each provider. Always normalize to a tokenizer-independent unit before comparing.
60 second bullets to scan on the way to the call.
Why different providers have different tokenizers (different training corpora and vocabulary sizes)
Typical magnitude of the tokenizer gap on English (10-30 percent) and where it widens (code, non-English)
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.