What an LLM Actually Costs You

The price you are quoted for a language model is a rate per million tokens. The bill you receive is that rate multiplied by four unquoted factors: tokenisation penalties for non-English text, conversation history re-sent on every turn, re-embedding of unchanged documents, and charges for failed attempts. Only the first number appears on the pricing page.

This guide is about the other four, because they are where the money is and because they are the parts you control. It ends with a post-mortem on one of our own tools, which was getting the first one wrong badly enough to hand Chinese-language users a budget they could not meet.

It does assume you know what a token is, what the difference between an input and an output token is, and what a context window holds. If any of that is fuzzy — and it is fuzzy for most people paying these bills — read tokens and context windows explained from zero first. It takes ten minutes and the rest of this will make considerably more sense.

The tokenisation tax is real, and it is not where people think

A token is not a word and not a character. It is a fragment the model's tokeniser learned to treat as a unit, and the tokeniser learned it from a training corpus that was mostly English. Text in other languages fragments into more pieces, so the same meaning costs more.

This is widely known. It is not, however, widely measured. Here are our numbers.

The corpus. This site's own About page exists in nine languages. Those files — lang/{locale}/about.php — hold 102 strings under identical keys, professionally translated, saying the same thing in each language. This gives us a parallel corpus: 6,456 characters of English and its equivalents. Ordinary product prose, not legal boilerplate or scripture, which is what most published comparisons use.

The method. Every string was run through both tokenisers we ship in our token counter — cl100k_base, the GPT-4 generation, and o200k_base, the current one — and the totals compared against English.

The table shows three things, two of which contradict the folklore.

The tax roughly halved between tokeniser generations. Thai went from 4.19× to 1.77×. A Thai business running text through a GPT-4-era model was paying over four times as much per unit of meaning as an English-language competitor doing identical work. This is not a rounding difference; it is a structural disadvantage, now largely engineered away. It also means cost advice written before this tokeniser generation is not slightly stale — it is wrong by a factor of two.

It closed for nobody. Every language in the table still pays. Simplified Chinese, the best of them, is 1.18×. The gap narrowed; it did not disappear, and anyone claiming parity has not measured it.

Density and cost pull against each other. English gets 4.94 characters per token; Chinese gets 1.49. Chinese says far more per character — which is why the Chinese files are a third the size — but each character costs more to process. The intuition that compact scripts are therefore cheap is backwards.

Traditional Chinese costs about 21% more than Simplified

The finding in that table I did not expect, and have not seen reported: the same content in Traditional characters costs materially more than in Simplified.

The mechanism is vocabulary allocation. A tokeniser's vocabulary is finite and is spent on what appeared most in training. Simplified forms dominate the digital Chinese corpus, so more of them earned a slot; Traditional forms fall back to being assembled from smaller pieces. Nothing about the writing system is less efficient — it is a question of what the tokeniser was shown.

The practical consequence is narrow but real. If you serve Taiwan or Hong Kong and you localise properly, that operation carries a fifth more model cost than the Simplified one for the same catalogue, the same support macros, the same documents. It will not appear in any planning document, because nobody costs a translation memory in tokens. You can check your own content in the tokenization visualizer, which shows the actual split rather than a number.

Our own tool was getting this wrong

We measured this because our own assumptions were costing accuracy in a live tool.

Our token counter gives an exact count for OpenAI models, because their tokenisers are public and we ship them. Anthropic and Google publish none, so those two figures have always been estimates, clearly labelled. The problem was the estimate itself: a flat characters ÷ 3.5.

A constant divisor assumes every script packs the same number of characters into a token. The corpus above says they range from 4.94 to 1.25. Measured against a real tokeniser, the old estimate came out like this.

Note which way the errors run. Latin scripts were over-estimated, which is merely annoying. Every CJK and Thai user was under-estimated, one of them by nearly three times. An over-estimate is a budget with slack in it. An under-estimate is a budget that fails in month one, and it was falling entirely on the readers least likely to find an English-language article warning them about it.

Two things had to be right in the repair, and the first attempt got one of them wrong. Tokens partition across a text — the total is the sum of what each script's characters cost — so the combined ratio is harmonic, not an average of the per-script ratios. Averaging them arithmetically still under-counted Chinese by 1.6×. The second is that the per-script constants are fitted to the worst case rather than the typical one: Traditional Han at 1.02 characters per token rather than Simplified at 1.24, so mixed text never lands short. Worst case is now 1.21× and on the safe side.

The tool still labels these as estimates, because they are. What changed is that a Han-script document is no longer costed as though it were English.

The other defect was duplication, not omission

The second problem is smaller and more instructive. Our LLM cost calculator keeps its own hardcoded list of models and prices. Most of the other cost tools on this site read a shared dataset instead, which carries a dated asOf stamp and a separate, explicitly provisional list for China-region pricing.

The calculator, holding its own copy, had drifted: it had no DeepSeek entry at all, so the cheapest option it could show was $0.10 / $0.40 per million tokens. A reader budgeting from it would never have learned that the floor sits well below the proprietary tier. Its figures now match the shared dataset exactly.

I will admit the sequel, because it is the more useful half. Having found that, I assumed the same gap ran through the other tools and said so. It does not. The price comparison tool reads the shared dataset correctly and ranks DeepSeek V4-Flash as the cheapest option on the page — it has done all along. I had searched each tool's own script file, found no model names in a file that was never going to contain any, and drew a conclusion from the absence. The tool was fine; the check was not.

Both faults have the same root, one that will outlive these tools. A duplicated dataset drifts, and a check that looks in the wrong place produces confident nonsense. The calculator went stale because it kept its own copy of something shared. The false accusation happened because I read the copy rather than the source.

What the sticker price leaves out

Three costs do not appear on the rate card.

Conversation is re-sent, every turn. Models are stateless. A ten-turn conversation does not send ten messages; it sends the entire history back on each turn, so the model can see it. If each turn adds 500 tokens, turn one sends 500, turn two sends 1,000, turn ten sends 5,000 — and the total input across the conversation is 27,500 tokens, not the 5,000 you wrote. That is 5.5×, and it grows with the square of the conversation length. A support assistant that holds long conversations has a cost curve that bends sharply upward with a metric nobody is watching.

Embeddings are paid for on write, then paid for again. Retrieval systems embed your documents once, which is cheap and widely understood. What is not budgeted is re-embedding: change your chunking strategy, switch embedding model, or edit documents at scale, and you pay for the entire corpus again. Teams that tune their chunk size four times during development have paid for their corpus five times. The embedding cost calculator takes a corpus size; multiply its answer by the number of times you expect to change your mind.

Failures are billable. A request that returns malformed JSON, trips a content filter, or times out after generating 800 tokens has still consumed input and usually output. Retries multiply that. A pipeline with a 5% failure rate and automatic single retry is running about 5% over its nominal cost — modest — but a pipeline that retries three times on a 20% failure rate is a different business.

Put a month of realistic traffic through the monthly spend projector with those multipliers applied rather than the raw token count, and the figure usually stops looking like the one on the pricing page.

What follows from all this

The sticker price is the number you can do least about. It is set by someone else, it changes without your involvement, and — as the capital war between the labs makes clear — it is being driven by a contest whose outcome is not yours to determine.

The other four are yours. Which language your prompts and documents are in, and whether you have measured what that costs. Whether you truncate or summarise conversation history instead of re-sending it whole. Whether your chunking is settled before you embed a corpus. Whether you know your failure rate. None of these requires predicting who wins anything.

The whole argument is in Sun Tzu: 不可勝在己，可勝在敵. What makes you unbeatable rests with you; what makes the other beatable rests with them. The rate card is 在敵. Everything above it is 在己.