How LLM Pricing Works: Every Line on the Bill

Almost every price list shows two numbers, input and output, per million tokens. A real bill has five or six lines, and the ones that are missing from the headline are usually the ones that decide what you pay.

What is actually being metered

Not words, not characters, not requests. Tokens — the sub-word units the model’s tokenizer splits text into. English prose runs somewhere around 0.75 words per token, which makes “about four characters” a serviceable estimate for a back-of-envelope and a bad one for a budget. Code, JSON, non-Latin scripts and long identifiers all tokenize worse than prose, sometimes much worse, and a tokenizer differs between model families. If a number matters, count it with the tokenizer for the model you are actually calling.

Prices are quoted per million tokens because per-token prices would be all zeros. That unit is worth internalising: a price of $3.00 per million is $0.000003 per token, and the whole of cost engineering is arithmetic at that scale. It is also why storing these amounts as floats goes wrong.

One thing the billing model does not care about is whether you meant to send a token. There is no distinction between a token that contributed to the answer and one that sat unread in the middle of a retrieved document, no distinction between the system prompt you wrote and the tool schemas your framework appended, and no allowance for the fact that the same 3,000 tokens of instructions are re-sent on every turn of a conversation. Everything in the request array is input, and input is billed. The single most common cause of a bill that is larger than expected is not an expensive model; it is a prompt that grew.

The lines you can be billed on

Not every provider has all of these, and none of them are optional once they exist — they appear because you sent something that triggered them.

The formula for one request

With prices P in dollars per million tokens and counts T in tokens, the cost of a single request is:

cost = ( P_in    * T_in_uncached
       + P_cache * T_in_cached
       + P_write * T_cache_written
       + P_out   * (T_visible_out + T_reasoning) ) / 1e6

Every technique in this cluster is an attack on one term. Prompt caching moves tokens from the first term to the second. Shortening the answer shrinks the fourth. Cascading changes which P you are using. A retry duplicates the whole expression. Nothing else is going on.

A worked example, with all four prices stated as assumptions rather than quotes — substitute the current numbers from the provider’s own pricing page. Assume P_in = $1.00/M, P_out = $5.00/M, a request with a 2,000 token system prompt, a 400 token user turn and a 300 token answer, no caching and no reasoning:

input : 2400 * 1.00 / 1e6 = $0.00240
output:  300 * 5.00 / 1e6 = $0.00150
                     total = $0.00390   (3,900 micro-dollars)

Under four tenths of a cent, which sounds like nothing until it is multiplied by the number of requests a real product makes. That multiplication is the whole of building a forecast, and it is where the interesting decisions live.

Why output costs more than input

The ratio between the two prices is commonly somewhere between two and five, and it is not a margin decision. Reading the prompt is a single parallel pass over the whole sequence, bounded by how much arithmetic the hardware can do. Generating is one forward pass per token, each of which must move the model’s weights through memory, and it cannot be parallelised because each token depends on the last.

The practical consequence is that intuitions from other kinds of API are backwards here. Sending more is cheap; asking for more is expensive. A 10,000 token prompt with a 100 token answer usually costs less than a 1,000 token prompt with a 1,000 token answer, and it is faster too. Keep the ratio in your head — it is the reason output length is the lever people ignore.

Reading a price list without being fooled

• Compute a blended price, not a headline one. With an input:output token ratio of r, the effective per-token price is (r * P_in + P_out) / (r + 1). Two models whose input prices differ by 2× can land within a few percent of each other once your actual ratio is applied.
• Check whether reasoning tokens are billed. A model that is cheaper per output token and emits five times as many of them is not cheaper.
• Find the cached-read multiplier before anything else. If a large fraction of your input is a stable prefix, that one number moves your bill more than the choice of model does.
• Watch the unit. Per million is standard but not universal; per thousand still appears, and a 1000× error in a forecast is an easy one to make and an embarrassing one to explain.
• Price the request, not the token. The only number that means anything is the cost of one of your requests, computed with your token counts.

A last caution about where these numbers come from. Every provider publishes prices on a page, and every one of those pages is a snapshot — prices for a given capability level have moved repeatedly and usually downward, models are superseded, and the price of the model you integrated against last year may no longer be the price of the model your alias now resolves to. Anything you write down should record the date and the source it came from, and any figure quoted in a document more than a quarter old should be treated as an estimate. That is why the pages in this cluster are built as formulas rather than as tables: the formula is still correct in a year, and the number you substituted into it will not be.