Understanding LLM Token Economics: Inputs, Outputs, and Context Windows

Every large language model API bills the same way: you pay per token, with separate meters for what you send (input) and what the model writes back (output). A token is a chunk of text roughly 4 characters long, so 1,000 tokens is about 750 English words. That system prompt you carefully engineered, the chat history you replay on every turn, the documents you stuff into context: all of it is metered input, billed on every single request.

Why output costs more than input

Output tokens are the expensive ones. Because a model must run a full forward pass to generate each new token, providers price output above input, and usually well above. Across the 40 models we price, output costs a median of 5 times input, reaching 8.3 times at the far end. The rule has real exceptions worth knowing about: 8 of them charge less than three times, and 4 charge the same rate in both directions, which changes the arithmetic entirely if your work writes more than it reads. This asymmetry means the shape of your workload matters as much as its size: a summarization pipeline that reads 10,000 tokens and writes 200 has a completely different cost profile than a content generator that reads 200 and writes 10,000.

Four characters per token is an English prose estimate, not a rule

The 4-characters heuristic holds for ordinary English writing and drifts everywhere else, always in the expensive direction. Code, deeply nested JSON, long identifiers, tables of numbers and non-English text all pack fewer characters into each token, sometimes far fewer. A page of dense JSON can cost noticeably more than the same page of information as plain rows.

There is a cheap saving in that. If you are sending structured data to a model, the format is a budget decision, not just a style one: the same records as compact rows rather than verbose JSON carry the same meaning for fewer tokens, on every request, forever. Count it rather than assume it. Paste the real thing into the token counter and compare the two formats before you standardise on one.

A scanned page is not text, and it is priced nothing like it

This one catches almost everybody who processes documents. If you send a photograph or a scan rather than extracted text, the model is not reading characters, it is reading an image, and every provider tokenises images by its own rule. In our published estimator assumptions, one US Letter page at 200 DPI works out at roughly 1,032 tokens under Google's tiling rule and about 4,758 on Anthropic's high-resolution tier. The same page as extracted text is a small fraction of either.

So the answer to "how much does it cost to process this document" depends on a question nobody asks first: does it arrive as text or as an image? A PDF can be either, and most people do not know which theirs is. Open one and try to select a sentence. If the text highlights, it has a text layer and is priced as text. If nothing highlights, it is a picture of a page and costs several times more.

The context window trap

Context windows have grown from a few thousand tokens to over a million, and that creates two separate hazards.

The budget one. A chat application that resends the full conversation history pays for it again on every turn. Turn two carries turn one, turn ten carries the previous nine, and the cost of a session grows with the square of its length rather than in proportion to it. A long support conversation can cost several times what the same number of questions would cost as separate exchanges. Trimming old turns, summarizing them, or retrieving only what is relevant addresses it directly.

The hard one. A workload whose input does not fit a model's window cannot run on that model at any price. This is a capability limit, not a cost one, and it bites hardest on documents: a hundred-page scanned package can run to hundreds of thousands of tokens, which rules out a good part of the market before price is even considered. Long context is a capability, not an obligation, but the ceiling is real and worth checking before you plan around a model.

What to measure before you choose a model

The practical takeaway: measure your average input and output tokens per request before choosing a model, then multiply by realistic monthly volume. That is exactly what the cost calculator does, and the ranking often surprises teams who assumed the sticker price per million tokens told the whole story.