Why the same text gets different counts
Each model family ships its own tokenizer. GPT-4 uses cl100k_base, a vocabulary of roughly 100k tokens. GPT-4o and the o-series use o200k_base at about 200k, which packs English into fewer pieces. Anthropic does not publish Claude's tokenizer at all, so the only exact source is the API's count_tokens endpoint.
The gaps are wide enough to matter. One Spanish passage cost 30% more tokens under o200k and 56% more under cl100k than its English original. English prose runs near 0.75 words per token. Code drops toward 0.5, and numbers or non-Latin scripts pack denser still.
So read the number above as a range. Four characters per token is close for English prose and loose for code, JSON or Chinese. When a hard context limit or a real bill depends on the figure, call the provider's own tokenizer.
What an estimate is enough for
Two questions, mostly. Will this prompt fit, and roughly what will it cost.
Context ceilings are large in 2026. Claude's Opus class and Sonnet 4.6 reach 1M tokens, GPT-5.5 takes 1M input, Gemini 3.1 Pro handles just over 1M. Advertised ceilings are not working ceilings: independent testing found recall slipping somewhere past 600K to 700K tokens. An estimate tells you whether the prompt fits at all. Whether it fits comfortably is your call.
Cost is the other one. APIs bill per token on input and output both, so a long system prompt or a pasted-in codebase runs the bill up quietly.
On a Mac the same four counts sit under every copy in Klipto's paste preview, which saves the round trip through a browser tab.