Ask an LLM cost model “how many characters per token,” and the tempting answer is the ~4-characters-per-token rule of thumb: divide your text by four, call it a token count, and build a budget on it. That number is a starting guess, not a measurement. The ratio that actually converts your request text into billable tokens shifts with the tokeniser, the language, whether the payload is prose or code, how whitespace is handled, and how many rare tokens show up. The only trustworthy figure for your system comes from tokenising your own traffic — not from a blog-post average. This matters because the serving path does not execute or bill characters. It executes and bills tokens. Every character-based estimate is really a bet on a conversion ratio, and if that ratio is wrong, the error propagates straight into your latency and cost projections at the same magnitude. How many characters per token? For typical English prose with a modern byte-pair-encoding tokeniser, the ratio lands somewhere around four characters per token — that is where the rule of thumb comes from, and as a first-pass sanity check it is fine. The problem is treating “roughly four” as a constant rather than the centre of a wide distribution. Here is the short version, framed as a quick-answer block you can lift out of context: Quick answer: characters per token English prose, BPE tokeniser: roughly 3.5–4.5 characters per token (observed pattern across common tokenisers; not a single fixed constant). Source code: often 2.5–3.5 characters per token — punctuation, indentation, and camelCase fragment into more tokens per character. Non-Latin scripts (e.g. Chinese, Japanese, many Cyrillic and Indic texts): frequently 1–2 characters per token, sometimes below one, because these scripts fragment heavily under tokenisers trained mostly on English. Highly structured payloads (JSON, XML, base64, long numeric strings): unpredictable — measure, do not assume. Every figure above is an observed range, not a benchmarked rate for your specific tokeniser and traffic. Use it to bound your expectations, then measure to replace it. Why does the ~4-characters-per-token rule of thumb break? The rule of thumb encodes one assumption: that your text looks like the English web prose the tokeniser’s merge table was optimised for. When your traffic diverges from that assumption, the ratio moves — sometimes by a factor of two or more. Three mechanisms drive the divergence. The first is language coverage. A tokeniser like the one behind GPT-family models or the SentencePiece vocabularies used by many open models allocates its vocabulary budget disproportionately to frequent English subwords. Text in a language that was underrepresented during vocabulary training fragments into more, shorter tokens, so the same character count costs more tokens. We see this bite hardest in multilingual products where the pricing model was calibrated on English test data. The second is content class. Code is not prose. Indentation, brackets, operators, and identifiers split into token boundaries far more often than natural-language words do. A 4,000-character English paragraph and a 4,000-character Python file can differ by 30–50% in token count under the same tokeniser (observed pattern; measure your own corpus to confirm). If your workload mixes chat, retrieval context, and code snippets, a single blended ratio hides that variance. The third is rare tokens and whitespace handling. Long numeric strings, UUIDs, base64 blobs, unusual Unicode, and leading-whitespace conventions all interact with the merge rules in ways that are hard to predict from character count alone. Two payloads with identical length can tokenise very differently. This is the same class of gap that shows up when context-window sizing collides with real inference cost — the headline number is a poor predictor of what the serving path actually processes. How token counts drive latency and cost-per-request The reason to care about all this is mechanical, not academic. In a transformer serving path, the prefill stage processes the full input sequence before the first output token is produced. Prefill cost scales with input token count, and per-request pricing on hosted APIs — as well as your own GPU-hours if you self-host — is billed in tokens. Character count is a proxy you chose; token count is what the runtime executes. That means the characters-per-token ratio is the conversion factor sitting between your request logs (which you measure in bytes or characters) and your cost model (which you must express in tokens). Get the ratio wrong by 20% and you get your prefill latency estimate, your context-window headroom, your throughput ceiling, and your projected monthly bill wrong by roughly the same 20%. It is a single number with leverage over the entire forecast. This is also why we treat tokenisation as a first-class stage when we map the serving path for performance. It sits upstream of prefill, it is cheap to instrument, and it determines the size of everything downstream. Skipping it means every capacity number rests on a constant that may not hold for your data. How do I measure the true ratio for my traffic? You do not estimate the ratio. You tokenise a representative sample of real requests with the exact tokeniser your model uses, and you look at the distribution — not just the mean. Here is a diagnostic checklist for producing a defensible ratio: Sample from production traffic, not synthetic prompts. Pull a representative window of real requests. If your traffic is seasonal or bursty, sample across the cycle, not a quiet Tuesday. Use the model’s own tokeniser. For OpenAI models that means tiktoken with the correct encoding; for open models it means the exact tokenizers/SentencePiece artifact shipped with the checkpoint. A ratio measured with the wrong tokeniser is not your ratio. Report the distribution, not the average. Record median and p95 tokens per request. The p95 is what sizes your context window and your tail latency; the median alone will underprovision. Break it down by content class. Segment tokens-per-character for chat prose, retrieval context, code, and structured payloads separately. A blended number is only useful if your mix is stable. Separate input from output tokens. Prefill (input) and decode (output) have different cost structures; a ratio that lumps them together is not actionable for either. Re-measure when the model or tokeniser changes. Swapping model families or upgrading a checkpoint can change the vocabulary and therefore the ratio. The number is not permanent. The output of this exercise is a small table — tokens-per-character and median/p95 tokens-per-request, per content class — that replaces the rule of thumb with a measured constant you can defend to finance and to procurement. How the tokenisation stage shows up in a profiler When you profile the serving path end to end, tokenisation appears as a distinct, measurable stage before prefill. Its two useful outputs are the wall-clock time it takes (usually small, but non-zero for very long inputs and worth confirming) and — more importantly — the token counts it emits, which every downstream cost attribution depends on. That token-count output is the input our cost audit uses to attribute cost per request. The [inference cost-cut pack](Inference Cost-Cut Pack) profiles the tokenisation stage explicitly so the characters-per-token distribution feeding the cost model is measured from your requests, not assumed from a constant. The token counts derived from this ratio are also the raw material a [unit-economics framework turns into cost-per-request](Inference Cost-Cut Pack) — the ratio is where the whole chain of cost reasoning starts. If you have already worked through how many characters live in a single token, this article is the companion view: that one explains the token/character relationship; this one turns the ratio into a cost and capacity forecast you can trust. For a page-oriented estimate — useful when your inputs are documents rather than chat turns — the tokens-per-page estimation walkthrough applies the same discipline to a different unit. How a wrong assumption skews your forecast Consider a worked example, with the assumptions stated so you can substitute your own. Suppose you assume 4 characters per token and forecast 250 tokens for an average 1,000-character request, at a hosted price per million input tokens. Now suppose your real traffic is 40% code and multilingual chat, and the measured ratio is closer to 3 characters per token. Your true average is ~333 tokens — a third higher. The monthly bill, the context-window headroom, and the throughput you can sustain on a fixed GPU budget are all off by that third. Nothing in the system is broken; the forecast was simply built on a constant that did not hold. That is the failure class to watch for: not a crash, but a quietly wrong budget that only surfaces when the actual bill arrives or when a context window overflows under real payloads. Routing and model-selection decisions inherit the same distortion — deciding when routing cuts cost is only sound if the token counts feeding the comparison are measured, not guessed. FAQ How many characters per token? For typical English prose with a modern BPE tokeniser, the ratio is roughly 3.5–4.5 characters per token — the source of the “~4” rule of thumb. But it is the centre of a wide distribution, not a constant: code often runs 2.5–3.5, and non-Latin scripts frequently drop to 1–2 characters per token. Treat the rule of thumb as a first sanity check and measure your own traffic for anything you will budget against. Why does the ~4-characters-per-token rule of thumb break for different languages and content types? The rule assumes your text resembles the English web prose the tokeniser’s vocabulary was optimised for. Underrepresented languages fragment into more, shorter tokens; code splits on indentation, brackets, and identifiers far more than prose does; and rare tokens, long numeric strings, and whitespace conventions all interact with the merge rules unpredictably. When your traffic diverges from English prose, the ratio can move by a factor of two or more. How do I measure the true characters-per-token ratio for my own request traffic? Tokenise a representative sample of real production requests with the exact tokeniser your model uses — tiktoken for OpenAI encodings, the shipped tokenizers/SentencePiece artifact for open models. Report the distribution rather than the mean: median and p95 tokens per request, broken down by content class, with input and output tokens separated. Re-measure whenever the model or tokeniser changes. How do token counts — not character counts — drive inference latency and cost-per-request? The serving path executes and bills tokens, not characters. Prefill cost scales with input token count, and both hosted API pricing and self-hosted GPU-hours are denominated in tokens. Character count is only a proxy you chose; the characters-per-token ratio is the conversion factor between your request logs and your cost model. How does the tokenisation stage show up in a profiler of the serving path? Tokenisation appears as a distinct stage before prefill, with two useful outputs: its wall-clock time (usually small but non-zero for long inputs) and the token counts it emits. Those token counts are the input every downstream cost-per-request attribution depends on, which is why a serving-path profiler instruments the tokenisation stage explicitly rather than assuming a constant ratio. How does a wrong characters-per-token assumption skew capacity and cost forecasts? A ratio error propagates at the same magnitude into everything it feeds. A 20% error in characters per token skews context-window sizing, throughput ceilings, and the projected monthly bill by roughly 20%. The failure is silent: nothing crashes, but the budget is quietly wrong until the actual bill arrives or a context window overflows under real payloads. The next time someone quotes you a token budget from a character count, the useful question is not “what ratio did you use” but “did you tokenise our traffic, and what did the p95 look like.” That single measured distribution is the difference between a cost forecast you can sign and a constant borrowed from someone else’s data.
