About four characters per token, for English prose, with a common tokeniser. That is the number most people are looking for, and it is close enough to start a spreadsheet with. It is also a starting estimate rather than a property of your workload — the ratio moves with the tokeniser’s vocabulary, the language, and whether the text is prose, code, JSON, or log lines.

So use 4.0 to sketch, then replace it. The difference matters: applying English-prose averages to code, JSON, or non-Latin-script text typically puts per-request token estimates 20–40% off (observed pattern across our cost-audit work; not a benchmarked rate). A measured ratio for your own content class usually lands within a few percent, which is the difference between a forecast you can plan against and one that is merely indicative.

Quick answer: what the ratio is, and where it holds

Text class	Rough characters per token	Note
English prose	~4	Where the rule of thumb comes from
English words → tokens	~0.75 words per token	So 1,000 tokens ≈ 750 words, ~1.5 pages
Source code	Lower than prose	Punctuation, indentation and identifiers fragment
JSON / structured payloads	Lower still	Braces, quotes and keys each cost tokens
Non-Latin scripts	Substantially lower	Often 1–2 characters per token

A 128K context window, read through the prose figure, is on the order of 90,000–100,000 words — roughly a short book. Read through a JSON payload’s ratio, the same window holds far less content than that estimate suggests, which is exactly where context-sizing plans go wrong.

How do I get a real ratio for my own traffic?

Under an hour of work, and it does not need a research project:

1. Pull a sample of real requests — a few hundred is enough if they represent your content mix, not just the happy path.
2. Tokenise them with the tokeniser your model family actually uses (tiktoken for OpenAI models, the Hugging Face transformers tokeniser for open-weight models). Online character-to-token calculators are fine for a sanity check and unreliable for budgeting, because they rarely tell you which vocabulary they used.
3. Divide total characters by total tokens per content class — prose, code, JSON — separately. A single blended ratio hides the class that is costing you.
4. Look at the distribution, not only the mean. Size the context window against p95 tokens per request; size monthly spend against the mean.

That last point is where naive and practised readers diverge. One multiplies a character count by 4 and stops; the other looks at the spread and discovers that a small tail of long requests drives both truncation incidents and a disproportionate share of prefill cost.

Switching tokeniser or model family shifts the ratio, usually modestly for English prose and more noticeably for code and non-Latin text — enough to re-measure on migration, rarely enough to invalidate a rough plan. Across provider tokenisers, the prose figure stays near 4; treat differences as a re-measurement task, not a reason to distrust the estimate.

Where this ratio feeds into cost-per-request attribution and profiler output, we cover it in the parent discussion of inference cost structure and where token spend actually accumulates. The measured ratio is also a direct input to the inference cost cut pack audit, which consumes it when attributing spend across prefill and decode.

The rule of thumb is good enough for a first-pass budget and for explaining scale to a non-technical stakeholder. It stops being good enough the moment the answer changes a decision — a context-window size, a model choice, a committed spend. At that point, what is the p95 tokens per request for your actual traffic, and do you know it or are you still multiplying by four?