What an LLM token actually is
A token is the unit a model reads and bills for. Byte-pair encoding (BPE) merges the most frequent byte sequences into single vocabulary entries, so a token is usually a word fragment: everyday words are one token, rare ones are several. Measured here, “Hello world” is two tokens — ids 13225 and 2375 — because the leading space belongs to the second one.
Two GPT vocabularies matter. o200k_base (about 200,000 entries) is used by GPT-4o, GPT-5 and later; cl100k_base (about 100,000) by GPT-4 and GPT-3.5. This page runs the real encoder in your browser, so the GPT figure is an exact count, not a heuristic.
Vocabulary size is why the encoding matters so much outside English. “빠른 갈색 여우가 게으른 개를 뛰어넘습니다.” is 17 tokens under o200k_base and 23 under cl100k_base — 35% more for exactly the same sentence.
Tokens per word, tokens per character
For plain English prose the familiar rule holds: roughly 4 characters or 0.75 words per token. “The quick brown fox jumps over the lazy dog.” is 44 characters and 9 words for 10 tokens — 4.4 characters per token, 1.1 tokens per word. A 158-character, 28-word paragraph of ordinary technical writing came to 30 tokens.
Korean is denser. A 24-character Korean sentence took 17 tokens (1.4 characters per token) and a 72-character paragraph took 42. Per character that is about three times the English rate; for the same meaning, expect Korean to need roughly 1.3–1.6× the tokens of its English equivalent.
- Plain English prose: 1 token ≈ 4 characters ≈ 0.75 words
- Code, URLs, IDs and numbers: 1.2–1.5 tokens per “word”, because identifiers rarely sit in the vocabulary whole
- Korean, Japanese, Chinese: 1 token ≈ 1–1.7 characters, so a character count badly under-estimates the bill
Turning a token count into a price
API prices are quoted per million tokens, and input and output are billed separately: cost = input ÷ 1,000,000 × input price + output ÷ 1,000,000 × output price. This page divides before it multiplies, so a million-token prompt does not lose precision.
A 1,000-token prompt with a 500-token answer, at list prices as of 2026-09-02: $0.0100 on GPT-5.4 ($2.50 / $15 per 1M), $0.0070 on Claude Sonnet 5 ($2 / $10) and $0.00155 on Gemini 2.5 Flash ($0.30 / $2.50). The same request, a 6.5× spread.
The table on this page spans three orders of magnitude, from GPT-5 nano at $0.05 / $0.40 per 1M to GPT-5.5 Pro at $30 / $180. Before optimising a prompt, check whether a smaller model in the same family already handles the task.
Input, output, cache and batch are four different prices
- Output costs 4–8× input on almost every model listed (GPT-5.4 $2.50 vs $15; Claude Sonnet 5 $2 vs $10). A summariser that reads a lot and writes a little is cheap; a generator of long answers is not.
- A cache read costs 0.1×, 0.25× or 0.5× the input price depending on the family; this page uses each provider’s published cache price instead of assuming 0.1×.
- Writing to an Anthropic cache costs 1.25× (5-minute TTL) or 2× (1-hour TTL) the input price, so caching pays off only when the prefix is genuinely reused.
- The batch APIs halve both prices (0.5×) in exchange for a delayed response — the single largest saving available for offline classification or bulk generation.
- Tool definitions are billed as input: switching the tool-overhead option on adds the measured per-model figure, 286–675 tokens on the Claude models listed here, to every request.
Why a ten-turn chat costs four times the naive estimate
Chat APIs are stateless. Each turn re-sends the whole transcript, so the input billed over N turns is N·S + N·U + (U+A)·N(N−1)/2, where S is the system prompt, U the user message and A the reply. The quadratic term is the one that hurts.
With S = 500, U = 100 and A = 300, ten turns bill 24,000 input tokens, not the 6,000 that “one turn × ten” suggests — four times as much. On GPT-5.4 that conversation costs $0.105; with the prefix cache hitting every turn it drops to $0.061, a 42% saving.
Two practical consequences: cap the history you re-send (a rolling window or a running summary), and put everything static — system prompt, few-shot examples, fixed context — at the very front, where a prefix cache can match it.
Exact counts versus estimates
OpenAI publishes its tokenizer, so GPT rows here carry an “exact” badge. Anthropic and Google do not, so their rows are scaled from the o200k anchor by a per-character-class family ratio (1.18 for Latin text on Claude) and, for Claude 4.7 and newer, a 1.3 tokenizer-generation factor.
That puts Claude within about ±20% and Gemini within ±25% — fine for a budget, not for a hard quota. When you need the exact number, call Anthropic’s messages.count_tokens or Google’s countTokens endpoint; both are free and neither charges for the text you measure.
Common mistakes when budgeting tokens
- Dividing characters by four for Korean, Japanese or Chinese. The real rate is nearer 1–1.7 characters per token, so the estimate can be three times too low.
- Counting only the prompt. Reasoning tokens are billed at the output price even when they are never displayed, and on most models long answers dominate the bill.
- Forgetting the scaffolding. Chat role markers, tool schemas and retrieved passages are all input tokens, and a RAG prompt is usually 80% retrieved text.
- Treating the context window as a budget. Fitting 200,000 tokens is possible; paying for them on every turn of every session is a different question, and latency grows with the prompt too.
Where the number gets used
Prompt engineering: measure the system prompt and the few-shot block once and you know the fixed cost of every request before writing any code. Trimming 500 tokens from a prefix that ships a million times a month saves $1,250 on a $2.50/1M model.
RAG and fine-tuning: chunk sizes are specified in tokens, and embedding models have hard limits — 8,191 tokens for OpenAI’s text-embedding-3 family, 512 for many BERT-based encoders. Fine-tuning datasets are billed per token as well.
Once the per-request figure is settled, the monthly bill becomes a traffic question: daily active users × requests per user × days. The LLM cost calculator on this site takes it from there, prefix caching and multi-turn growth included.