How to calculate LLM cost without guessing
Every LLM bill is two multiplications added together. That is the whole formula:
cost = (input_tokens / 1,000,000 x input_rate) + (output_tokens / 1,000,000 x output_rate)Nothing else goes into it. There is no per-request fee on the major providers, no seat charge, no minimum. If you know two token counts and two rates, you know the number to the cent.
Almost nobody uses it. What people do instead is take the monthly token count from a dashboard, multiply by one rate, and publish the result as a forecast. That number is wrong in a predictable direction, and the size of the error is not random.
https://aicomp.ai/v1).
Create one free →
The two numbers, and why one of them dominates
The consequence is arithmetic, not opinion. A workload that emits one output token for every five input tokens is spending half its money on the direction that carries a fifth of the tokens.
Here is the same 12 million monthly tokens priced three ways on Claude Sonnet 5 ($1 input, $5 output per 1M):
| Token split | Input cost | Output cost | Monthly total |
|---|---|---|---|
| 10M in / 2M out | $10 | $10 | $20 |
| 6M in / 6M out | $6 | $30 | $36 |
| 2M in / 10M out | $2 | $50 | $52 |
Same token volume. Two and a half times the bill. Every row is a real product shape: the first is a search assistant that quotes retrieved text, the second is a chat assistant, the third is a code agent that emits long patches.
If you priced all three at $1 per million because that is the number on the pricing page headline, you would have forecast $12 for each. The code agent would have cost you $52.
Workload shapes, priced with real rates
The split is the whole game, so it is worth knowing what your workload actually emits. These are the three shapes that cover most production traffic, priced at real rates from the index.
Retrieval and summarisation. Large context in, short answer out. A RAG service that sends 40,000 tokens of retrieved context and gets back 400 tokens runs at roughly 100:1. Input dominates completely, and the model choice should be made on input rate alone. DeepSeek V4 Flash at $0.15 input / $0.6 output prices one million such calls at about $6.30. A model with a cheap input rate and a punishing output rate is the right buy here even if its output rate looks alarming.
Conversational. Roughly 5:1 to 10:1, because the conversation history is re-sent every turn and grows. This is where the 4x median starts to matter. Claude Sonnet 5 at a 5:1 split puts 50% of the spend on output.
Agents and code generation. Close to 1:1, and sometimes output-heavy. An agent that reads a file and rewrites it emits about as much as it ingests. GPT-5.6 Terra at $1 / $6 puts 86% of that bill on output. Any comparison that ranks models by input rate will pick exactly the wrong model for this workload.
That last case is the one I have seen mispriced most often, because the input rate is the number vendors lead with and the number comparison tables sort by.
One reference workload, priced three ways
To make this concrete, here is the workload I use as the reference on every comparison on this site: a day of work on this page's workload is 200k input and 50k output tokens — 4M input and 1M output over a 20-day month. That is a 4:1 split, which is barely above the median model's own output multiple, so it is a conservative example rather than a stacked one.
| Model | Input rate | Output rate | Monthly total | Output share |
|---|---|---|---|---|
| DeepSeek V4 Flash | $0.15 | $0.60 | $1.20 | 50% |
| GLM-5.3 | $0.70 | $2.20 | $5.00 | 44% |
| Claude Sonnet 5 | $1.00 | $5.00 | $24.00 | 83% |
| GPT-5.6 Terra | $1.00 | $6.00 | $28.00 | 86% |
| Claude Opus 5 | $2.50 | $12.50 | $60.00 | 83% |
The spread is 50x between the cheapest and the most expensive, on identical token counts. Nothing about the workload changed.
The unit error that costs 1000x
Rates are quoted per million tokens in most current documentation, but per thousand in a lot of older material, in some academic papers, and in a few provider pages that never updated. The two differ by a factor of 1,000.
The check is quick: frontier models cost single-digit dollars per million input tokens. If a number you are reading implies $1 per thousand input tokens for a frontier model, it is per million mislabelled, or it is a rate from 2023. A monthly estimate built on the wrong unit is wrong by three orders of magnitude, which is large enough that someone usually catches it. The subtler version is a spreadsheet where input is per million and output is per thousand, which produces a plausible-looking number that is 1,000x wrong on one term only.
What the formula leaves out
The two multiplications give you the list-price answer. Four things move the real number away from it, and it is worth knowing which direction each one pulls.
Cached input. Prompt caching charges a fraction of the input rate on prefix tokens that repeat. On a workload with a stable system prompt and a long retrieved context, this is the single largest discount available, and it applies to the input term only. It never touches output.
Batch tiers. Asynchronous batch endpoints trade latency for a flat discount, typically around half. If the work does not need to be synchronous, this halves both terms.
Retries and failed generations. A 5% retry rate is a 5% surcharge that appears in no forecast. Streaming calls that the client abandons mid-generation are worse: many providers bill the tokens generated before the abort, and those tokens appear in no response log.
Reasoning tokens. Reasoning models emit thinking tokens as output. They are billed at the output rate, and they can outnumber the visible answer several times over. If you are forecasting a reasoning workload on the visible answer length, you are forecasting the smaller term.
None of these change the formula. They change the two numbers you feed into it, which is why the formula is worth writing down: it tells you exactly which input to go measure.
Doing this without a spreadsheet
The calculator on this site takes the two token counts and the model, and returns the monthly figure at both official list rates and current gateway rates, so the comparison is the same arithmetic on two sets of rates rather than two different methods.
For a rough figure in your head, the shortcut that survives contact with reality is this: take your output tokens, multiply by the output rate, and if the answer is not at least a third of your total, check whether you have actually counted output tokens. The median model charges 4x for them, so on most workloads they are the bigger term, and on agent workloads they are nearly the whole bill.
The models at the extremes make the point better than the median does. Gemma 2 9B is priced at $0.01 for both directions, which means the split does not matter at all. GPT-5.5 Pro is $15 input and $90 output, which means a single million-token output day costs $90, and a workload that emits a tenth of that still spends more on output than a full-scale input-heavy workload on a cheap model.
FAQ
FAQ
How much does 1 million tokens cost?
It depends on the split, which is the whole point. At Claude Sonnet 5 rates ($1 input, $5 output per 1M), a million input tokens is $1 and a million output tokens is $5. A million tokens of unspecified direction lands somewhere between the two, and where in that range decides the answer.
Why is my bill higher than my estimate?
Four causes cover most of it, in order of frequency: you counted total tokens and applied the input rate to all of them; you estimated the visible answer length on a reasoning model without counting thinking tokens; you have a retry rate that never entered the forecast; or the rate you used is per thousand tokens while your usage is counted in millions.
Does prompt caching change the formula?
No, it changes one of the two inputs. Cached prefix tokens are billed at a reduced input rate, so the input term drops and the output term is untouched. That makes caching less valuable than it looks on output-heavy workloads, and more valuable than it looks on retrieval-heavy ones.
How do I estimate cost per user?
Measure one representative session rather than one request. Count the tokens in a full session including the re-sent history, split them into input and output, then multiply by sessions per user per month. Per-request estimates miss the history re-send, which is usually the single largest line in a conversational bill.
Is the cheapest model per token the cheapest model for my workload?
Only if your split matches the split the comparison assumed. A model with a low input rate and a 12x output multiple wins on retrieval and loses badly on agents. Rank by the two-term total on your own ratio, not by either rate alone.