LLM API Cost Calculator

Every major provider bills the same way: two meters, priced per one million tokens. The input meter counts everything you send — system instructions, conversation history, retrieved documents, the user’s question. The output meter counts everything the model writes back. There is no per-request fee and no per-keystroke fee, which is why a short question with a long answer can cost more than a long question with a short answer.

• Input tokens are processed in a single parallel pass, which is comparatively cheap per token.
• Output tokens are produced one at a time, each requiring a read of the model’s memory, so providers price them several times higher than input — usually 3× to 5×.
• Cached input is a discount on the part of the prompt the provider still has in memory from the previous request. It is the largest single lever on a repetitive workload.
• Reasoning tokens on o1/o3/R1-class models are billed as output even though you may never see them, which can multiply the output meter unexpectedly.

1. 1Average input tokens per request. Use the token counter on the text you really send, not on the user’s question alone — long system prompts dominate this number in practice.
2. 2Average output tokens per request. Typical chat answers are 200–600 tokens; summaries and generated documents are far longer.
3. 3Requests per day. Traffic at the top of your expectation, so the answer is a ceiling rather than an average.
4. 4Days per month. 30 is the usual accounting convention; use 22 for a weekday-only internal tool.
5. 5Cached input share. The fraction of the prompt that repeats between calls — a fixed system prompt can be 100% cached, a fresh document 0%.

The table then shows cost per request, per day, per month and per year for every model with a published per-token price. Models without one — open-weight releases you host yourself — are listed separately rather than shown as free, because "no API bill" and "no cost" are not the same thing: with self-hosting you pay for GPU hours instead, and the cost moves from the invoice to the infrastructure.

Take a support assistant that receives 2,000 input tokens (a long system prompt plus history) and writes 500 output tokens, at 1,000 requests per day. With GPT-4o mini at $0.15 per million input and $0.60 per million output: input costs 2,000 ÷ 1,000,000 × 0.15 = $0.0003, output costs 500 ÷ 1,000,000 × 0.60 = $0.0003, so a request is $0.0006 — a little over half a thousandth of a cent. A day of traffic is $0.60 and a 30-day month is about $18.

Run the identical workload through Claude 3.5 Sonnet at $3.00 per million input and $15.00 per million output instead: input becomes $0.006 and output $0.0075, so a request is $0.0135, a day is $13.50 and the month lands near $405. Nothing changed except the model name — a 22× difference on the same product. That gap is the entire reason this page exists: model choice is a product decision with a price tag, and it is better seen before launch than after.

Most prompts repeat themselves. A fixed system prompt, a style guide, a long document the user is asking about — the same tokens arrive on every request. Providers noticed, and now keep part of that prefix in memory so the second request can skip recomputing it. A cache hit is billed far below fresh input: OpenAI charges half the input rate, Anthropic about a tenth, DeepSeek a similar fraction, and the calculator applies whichever figure the provider publishes.

The effect on the worked example is easy to feel. If 80% of those 2,000 input tokens are a stable system prompt and therefore cached, GPT-4o mini input drops from $0.0003 to $0.00018 per request — a 40% cut in the total request cost, achieved by reordering the prompt so the constant part comes first. That ordering matters: a cache only matches a prefix, so one changing word near the beginning invalidates everything after it.

• Put the stable text first — system instructions and reference documents — and the volatile text last.
• Caches expire, and providers enforce minimum sizes, so short prompts may not benefit at all.
• Only some providers price cache writes separately; where they do, the first request of a session costs slightly more.

• Retries and validation loops. A failed JSON parse that triggers a second call is a 100% cost increase on that request, not a 0% one.
• Agent steps. A tool-using loop of eight steps sends the transcript again on every step, so input tokens grow roughly quadratically through the conversation.
• Unbounded output. Asking for "a full report" can produce 4,000 tokens where 400 would have done — and output is the expensive meter.
• Context creep. History that is never trimmed keeps billing the same stale turns over and over.
• Long-context tiers. Some providers charge a higher rate once the prompt passes a threshold — 128K tokens, for example — so a prompt that just crosses the line can cost more than one twice its size.
• Development and evaluation. Benchmarking a feature against fifty test prompts on a frontier model can cost more than a week of production traffic on a small one.

1. 1Sort by monthly cost and note the cheapest three that plausibly pass your quality bar.
2. 2Check the context window column against your real prompt size — the cheapest model is useless if your document does not fit, or if the prompt must be truncated to make it fit.
3. 3Check the max-output column before you design a feature that generates long documents.
4. 4Prototype on the cheapest candidate first. Most tasks that feel like they need a frontier model are solved by a small one with a better prompt.
5. 5Re-run the numbers whenever you change the system prompt: a few hundred extra tokens per request multiplies by your traffic, not by your effort.

One caveat worth stating plainly: this page compares list prices. It cannot see your traffic mix, your quality thresholds or the engineering cost of switching providers. Treat the output as a shortlist to argue about, not a decision — and re-check the figures against each provider’s pricing page, which is the link printed next to every model.