What LLM tokens actually cost, and how to pay for fewer of them

Every API bill for a language model is a bill for tokens, and almost nobody has an intuition for how many tokens a given piece of text is. The result is the same surprise twice a month: a feature that felt cheap in testing costs forty times more in production, or a context window that "should fit" rejects the request. Both are arithmetic problems, and the arithmetic is worth learning once.

A token is not a word

Models do not read characters or words. They read tokens — chunks produced by a byte-pair encoder that learned, during training, which sequences occur often enough to deserve their own symbol. Common English words are one token. Rare ones split. So token is one and tokenization is three, while a random string like x7Qp2 can cost five.

The rules of thumb worth carrying:

• English prose: roughly four characters per token, or about 0.75 tokens per word. A thousand-word article is around 1,300 tokens.
• Code: considerably worse. Indentation, punctuation and camelCase identifiers all fragment. Budget closer to three characters per token, and treat minified code as its own disaster — it tokenizes badly precisely because it is unusual.
• Non-Latin scripts: much worse again. Chinese, Japanese and Korean commonly land near one token per one or two characters, so the same content in Japanese can cost several times what the English version does. Cyrillic and Greek sit in between.
• JSON: the punctuation is real money. Every quote, brace, colon and comma is at least part of a token, and deeply nested structures with long key names can spend more on syntax than on values.

Rules of thumb are for estimating. When it matters, count: the LLM token and cost calculator tokenizes what you paste and prints the count, and it can also show the text with the token boundaries marked, which is the fastest way to understand why one of your prompts is unexpectedly expensive. Seeing your own identifier names shatter into four pieces each explains a lot.

Output costs several times more than input

The pricing detail people miss: providers charge separately for tokens you send and tokens the model generates, and output is typically four to eight times the input rate. A prompt with 10,000 tokens of context and a 200-token answer is dominated by the input. A prompt with 500 tokens of instruction that produces a 4,000-token essay is dominated — heavily — by the output.

This inverts a lot of optimisation instincts. Trimming a system prompt from 900 to 600 tokens saves very little if the model is writing long answers every call. Telling the model to answer in three sentences instead of three paragraphs saves a great deal. Ask which side of the transaction your workload actually lives on before you optimise the wrong one.

The calculator prices the same text against every model in its table at both input and output rates, so you can compare a cheap model doing the whole job against an expensive one doing part of it. The reference prices are stored locally and checked against provider pages periodically — treat them as a planning aid and confirm against the provider's own pricing page before you commit to a budget, because rates move.

Chat is quadratic, and that is where budgets die

A one-shot API call costs what it costs. A conversation re-sends the entire history on every turn, so a twenty-turn chat does not cost twenty times one turn — it costs roughly the sum of a growing series. Turn twenty pays for turns one through nineteen again.

Two consequences. First, long-running agent loops are the most expensive shape of LLM use and the one most likely to be prototyped without measurement. Second, prompt caching matters more than any wording change: providers discount tokens that repeat a prefix they have already seen, which means putting your stable content — the system prompt, the schema, the examples — at the very front and the variable part at the end. Reorder the same prompt so a changing timestamp sits at the top, and you have invalidated the cache on every call while changing nothing else.

Shrinking a prompt before you send it

Most oversized prompts are oversized for boring reasons: someone pasted a whole file when three functions were relevant, and the file is half comments and blank lines. The LLM context compressor targets exactly that — it strips code comments, collapses runs of blank lines, dedents, and removes filler words from prose, then reports how many tokens the trim saved. On a real source file that routinely runs 20–40% without touching anything the model needs.

The manual cuts worth making before that:

1. Send excerpts, not files. Model attention is not free either; irrelevant context measurably degrades answers as well as costing money.
2. Strip logs to the failing region. Ten thousand lines of successful startup output contribute nothing to a diagnosis.
3. Drop repeated boilerplate. Licence headers, generated imports, the same disclaimer on every record.
4. Summarise instead of re-sending. In a long conversation, replacing turns one through fifteen with a paragraph of state is the single biggest saving available.

When the input genuinely does not fit

Context windows are large now, but "large" is still finite, and a book, a year of logs or a full transcript will exceed one. Splitting is the standard answer, and where you split matters: cutting mid-sentence or mid-function produces chunks the model has to guess at. The prompt splitter divides text into chunks at a size you choose while respecting boundaries, and numbers the parts so you can feed them in sequence with a consistent instruction attached to each.

A note on units: tokens are not bytes. The UTF-8 byte counter answers a different question — how much space the text takes on the wire or in a database column — and the two numbers diverge sharply for non-Latin text, where bytes per character rise at the same time as characters per token fall. Use bytes for storage limits and tokens for model limits, and never substitute one for the other.

A worked example

Suppose you answer twenty questions against a thirty-page document. Thirty pages is around 15,000 words, so roughly 20,000 tokens. Naively, you send the document with each question: 20 × 20,000 = 400,000 input tokens, plus maybe 20 × 300 output tokens.

Put the document first and keep it byte-identical across calls, and most providers serve the repeated prefix from cache at a fraction of the rate. Trim the document of boilerplate first and the base shrinks too. Batch five questions per call instead of one and you send the document four times instead of twenty. The same task, the same model, and an order of magnitude between the careless version and the careful one — which is the whole point of counting before you send.

Both the counter and the compressor run entirely in your browser: the prompt you are pricing is not uploaded anywhere to be measured.