LLM Token Cost Calculator
What a model call costs — input and output tokens priced separately, per request and across a month of traffic.
Providers price input and output tokens differently, and output is usually three to five times dearer.
How the llm token cost calculator works
Providers price input and output tokens differently, and output is usually three to five times dearer. That asymmetry is the whole cost model: a request with a long prompt and a short answer costs very little, and one with a short prompt and a long answer can cost many times more.
So the lever is rarely the prompt. Capping output length, or asking for structured rather than prose answers, moves the bill far more than trimming the system prompt does.
Formula: cost = (input ÷ 1M × input price) + (output ÷ 1M × output price)
Worked examples
| Inputs | Cost per request | Note |
|---|---|---|
| 2,500 in, 600 out | 0.0165 | output is most of the cost |
| A long answer | 0.0675 | the bill multiplies |
| With prompt caching | 0.0111 | input cost nearly disappears |
FAQFrequently asked questions
Why is output more expensive than input?
Because it is generated one token at a time and cannot be batched the way a prompt can. Three to five times the input price is typical.
What is the cheapest thing to change?
Output length, almost always. Capping it, or asking for structured output instead of prose, moves the bill more than shortening the prompt does.
How many tokens is my prompt?
Roughly words divided by 0.75 for English. Code, other languages and unusual formatting all tokenize less efficiently.
Does prompt caching help?
Enormously when a long system prompt repeats across requests — cached input is often billed at a tenth. It does nothing for varied prompts.
Why does this page not list prices?
Because they change monthly and any figure printed here would be wrong before you read it. Enter your provider's current price.
Where these figures come from
- Vaswani et al. (2017) — Attention Is All You Need — the transformer architecture the memory arithmetic follows
- Kaplan et al. (2020) — Scaling Laws for Neural Language Models — the compute relationship used for training estimates
- Hoffmann et al. (2022) — Training Compute-Optimal Large Language Models — the tokens-per-parameter guidance ("Chinchilla")
- IEEE 754 — Standard for Floating-Point Arithmetic — the numeric formats behind bytes per parameter
- NIST AI Risk Management Framework — the US federal AI framework
Last checked: September 2026. The relationships here are architectural, not vendor-specific: bytes per parameter follow the numeric format, KV-cache size follows the transformer definition, and token-per-word ratios come from published tokeniser behaviour.