LLM token cost calculator

What this calculator computes

It multiplies your token volume by the price you were quoted for a million tokens, splits input from output, and projects the result across a month and a year. The comparison table runs the same volume against five model presets so you can see how much of your spend is driven by the model tier rather than by usage.

Every price field is editable. The starting values are list prices captured in October 2026, and they exist so the calculator produces a plausible number before you touch anything — not so you can budget from them without checking. Vendor pages change, regional pricing differs, and negotiated rates are common above modest volumes.

The arithmetic, plainly

For a single request:

• Input cost = input tokens ÷ 1,000,000 × input price
• Output cost = output tokens ÷ 1,000,000 × output price
• Request cost = (input cost + output cost) × (1 − batch discount)

Then:

• Monthly cost = request cost × requests per month
• Annual cost = monthly cost × 12

Output tokens almost always cost more per token than input tokens — often four to five times more for frontier models. That asymmetry is why a prompt-heavy workload and a generation-heavy workload can have very different bills even at the same total token count.

Where token estimates come from

Three practical methods, in increasing order of accuracy:

1. Character rule of thumb. English text is roughly four characters per token. Divide your prompt length in characters by four and you are usually within 20%.
2. Word rule of thumb. Roughly 0.75 tokens per word for English prose, higher for code, URLs, and non-English text.
3. The tokenizer itself. OpenAI publishes a tokenizer tool, and the major providers expose token counting endpoints or SDK helpers. If a quote matters, count with the same tokenizer the model uses.

Fill prompt templates with your own data before measuring. A support-reply prompt with a 2,000-token knowledge-base excerpt behaves nothing like a 200-token classification prompt.

Assumptions baked into the output

• No prompt caching. Several providers discount repeated input prefixes substantially. If most of your prompt is a fixed instruction block, your real input cost can be a fraction of the modeled figure.
• No retries, no failed requests. Production error rates add spend.
• No image, audio, or file input. Those are priced per unit or per token differently and are not modeled here.
• No long-context surcharge. Some providers raise the per-token price once a request passes a context threshold. Split such workloads into two scenarios rather than averaging.
• Uniform request size. Real traffic is a distribution. Model your median case and your p95 case separately.
• Straight multiplication of a monthly figure. Seasonal traffic will not match an annual projection.

When batch pricing applies

Asynchronous batch endpoints trade latency for a discount — commonly around half the synchronous price, with a completion window measured in hours. That is a good fit for overnight classification, bulk summarization, and content generation you schedule. It is a poor fit for anything a user is waiting on, and some providers limit which models and features are available in batch mode.

The discount field is editable rather than fixed precisely because the percentage is a vendor policy, not a constant. If you are unsure whether a given model supports batch, check the provider's documentation before you build the estimate into a plan.

Reading the comparison table

The cheapest row is highlighted, and that highlight is the least interesting part of the output. Two cautions:

• A 90% cheaper model is not a 90% cheaper workflow. If the cheap model needs retries, longer prompts, or human review, the savings shrink or invert. Cost per successful task is the number you want.
• The presets are not equivalent products. Pricing tiers track capability, rate limits, context windows, and support terms. A row that wins on price may lose on output length limits or on the data-processing terms your legal reviewer requires.

Treat the table as a sensitivity check: it tells you how much the model choice moves the bill relative to your usage volume. If the model choice changes monthly spend by $40 and your engineering time to switch costs two weeks, the switch is not a pricing decision.

A short action list

1. Instrument one real workflow and log actual input and output tokens for a week.
2. Enter the median request size and real monthly volume.
3. Toggle batch on to see the ceiling of what scheduling could save.
4. Compare two models at the same volume, then re-check your output quality assumption on a sample.
5. Re-run the model when you change prompt length materially — a longer system prompt can double input spend.
6. Budget a contingency for retries and evaluation traffic.

Related tools

• AI seat cost calculator for per-seat subscription spend rather than usage-based API spend.
• AI automation ROI calculator to weigh token cost against labor hours saved.
• Prompt variable filler to draft and estimate the length of prompt templates before you measure tokens.

What this calculator cannot do

It cannot tell you what a model will cost with caching, retries, or negotiated pricing, and it cannot tell you whether the output is good enough. It does not model embeddings, fine-tuning, image generation, or storage. It assumes USD list pricing and a fixed exchange rate of one. For a real budget, reconcile the model against an invoice after one month of production traffic — the gap between the two is usually the most useful number you will get.