How to Count Tokens (and Why It Affects Your Bill)

Tokens are the unit every model provider bills you in, and almost nobody has an intuition for them. That would be a minor annoyance if the relationship between what you type and what you pay were simple. It is not. In a twenty turn conversation, the text your user actually typed might come to 2,400 tokens while the bill is calculated on 117,200. Nothing is broken when that happens. It is how the pricing works, and this article explains why.

If you only want the number for a specific prompt, our Token Counter gives it to you exactly. If you want to understand the bill, keep reading.

TL;DR

A token is a frequent chunk of characters, not a word. Common words are one token; rare words split into several.
Output tokens typically cost three to five times what input tokens cost, so a chatty model is expensive twice over.
Chat is quadratic. Every turn resends the entire history, so billed input grows with the square of the turn count.
Twenty turns of a modest conversation bills around 117,200 input tokens even though the user only typed 2,400. That is a factor of 49.
Prompt caching is the single biggest lever, because the repeated prefix is exactly what caching was designed for.

What a token actually is

Models do not read characters and they do not read words. They read tokens, which are produced by an algorithm called byte pair encoding. BPE starts from raw bytes and repeatedly merges the most frequent adjacent pair into a new symbol, a few tens of thousands of times. What survives is a vocabulary in which common sequences became single units and rare ones did not.

The practical consequence is that token cost tracks familiarity, not length. The word "the" is one token. A rare surname, an SKU, a base64 blob or a UUID is many, because the merges that would have compressed them never happened. This is why a 40 character UUID can cost more tokens than a 40 character English sentence.

It also means the popular rule of "one token is four characters" is a folk memory rather than a fact. Measured on the modern o200k tokenizer, English prose runs closer to 5.4 characters per token, while Python source is nearer 2.8 and a JSON payload about 2.7. Structure is expensive. Braces, quotes and indentation are all tokens, and they carry no meaning for your user.

The cost model

Every provider bills the same shape of formula. Input and output are metered separately, at different prices, per million tokens:

C = \frac{T _{in} \cdot p _{in} + T _{out} \cdot p _{out}}{1 0 ^{6}}

The asymmetry is the part people miss: $p_{out}$ is usually three to five times $p_{in}$ . Output tokens are generated one at a time, each requiring a full forward pass through the model, whereas input tokens are processed in parallel during prefill. You are paying for a real difference in compute, not an arbitrary markup.

So the cheapest available optimization is often just asking the model to be brief. "Answer in one sentence" is not a style preference. It is a line item.

Why chat gets expensive: the quadratic trap

Here is the thing that surprises people on their first invoice. The API is stateless. The model remembers nothing between calls, so to continue a conversation your client must resend the entire history every single turn. The system prompt, every previous question, and every previous answer, all of it, re-billed as input.

Let $S$ be the system prompt, $u$ the average user message and $a$ the average assistant reply. On turn $i$ you send:

T_{i} = S + (i - 1) (u + a) + u

Summing that over $N$ turns gives the total input you are billed for:

T_{total} = N \cdot S + N \cdot u + (u + a) \cdot \frac{N ( N - 1 )}{2}

That last term is the one that hurts. It grows with $N^{2}$ . Doubling the length of a conversation does not double its cost, it roughly quadruples it. Take a realistic case: an 800 token system prompt, 120 token questions and 400 token answers.

Cumulative input tokens billed across a 20 turn conversation, with an 800 token system prompt, 120 token questions and 400 token answers. The user typed 2,400 tokens. The bill is computed on 117,200, because turn 20 alone resends everything that came before it.

Forty nine times more than the user typed, and none of it is waste in any obvious sense: the model genuinely needs that context to answer coherently. But it explains why a chat product's cost per conversation is dominated by its length, not its traffic, and why an agent that loops thirty times over a long transcript can burn a startling amount of money doing very little.

What to do about it

Cache the prefix. Look again at $T_{i}$ : the beginning of every request is identical to the last one. That is precisely the pattern prompt caching exists for. Cached input is typically billed at around a tenth of the normal rate, so if a fraction $f$ of your input hits the cache, your effective input price becomes:

p_{eff} = p_{in} ((1 - f) + f \cdot r)

with $r \approx 0.1$ . In a long conversation $f$ tends towards 1, which turns a 90% discount on the dominant term into the single most valuable change you can make. Keep the stable material (system prompt, tool definitions, retrieved documents) at the front of the prompt and the variable material at the end, because caching works on a shared prefix and one changed token near the top invalidates everything after it.

Truncate or summarize the history. Capping the conversation at the last $k$ turns turns the quadratic back into a linear cost. Summarizing older turns into a compact digest keeps more of the meaning for the same ceiling.

Cap the output. Since $p_{out}$ dominates per token, max_tokens and an explicit instruction to be concise pay for themselves immediately, and they also shrink the next turn's input, because today's answer is tomorrow's history.

Stop sending structure nobody reads. Raw HTML, giant JSON blobs and re-pasted logs are token-dense and meaning-sparse. Converting a page with Web to Markdown before it reaches the prompt routinely removes most of the tokens while keeping all of the content, and Free OCR does the same job for PDFs and scans.

Count, do not estimate

Every rule of thumb in this article is a rule of thumb. The tokenizer is the only authority, and different model families use different ones, so the same text can carry different prices depending on where you send it. Before you ship a prompt template that will run a million times, put it through our Token Counter and read the real number. A template that is 200 tokens heavier than it needs to be costs you 200 tokens on every call, forever.

If you self host rather than call an API, tokens stop being a line item and become a memory problem instead: every token in the context occupies KV cache on the GPU. The arithmetic for that is in how much VRAM you need to run an LLM, and our LLM VRAM Calculator will size it for you.

FAQ

How many tokens is a word? For English, roughly 1.1 to 1.3 tokens per word. For code, closer to 2.5. For languages that are less well represented in the tokenizer's training data, considerably more, which means the same meaning can cost more to express.

Why did my bill grow faster than my usage? Almost always the quadratic above. Your conversations got longer, not more numerous, and cost scales with the square of length.

Do I pay for the system prompt every turn? Yes, on every single call, unless it is being served from a prompt cache. This is why a bloated system prompt is one of the most expensive things you can own.

Are whitespace and punctuation billed? Yes. They are tokens like anything else. Pretty-printed JSON costs meaningfully more than the same JSON minified.

Free tools from Netra

All of these run in your browser. No signup, and your text is not uploaded to us.

Token Counter: count a prompt exactly, under the GPT, Claude and Llama tokenizers.
LLM VRAM Calculator: if you self host, tokens become KV cache, and this sizes the GPU.
Fine-Tuning Memory Calculator: the memory cost of training rather than serving.
Free OCR: turn scans and PDFs into text you can actually count.
Web to Markdown: strip a web page down to clean Markdown before it reaches a prompt. Raw HTML can cost several times more tokens than the text it carries.
Limbus: local-first image segmentation.
sam3.c: SAM3 inference in pure C.

References

Sennrich et al., Neural Machine Translation of Rare Words with Subword Units, the paper that brought BPE to language models.
OpenAI, Prompt caching.
Anthropic, Prompt caching with Claude.
tiktoken, the reference BPE tokenizer for the GPT family.

Blog / Guides