How to Estimate LLM API Costs in 2026: Formula & Worked Example

Before you ship an LLM feature, you should be able to estimate what it will cost — and the math is simpler than it looks. LLM pricing is just two numbers (input and output price per million tokens) multiplied by how many tokens you send and receive. This guide gives you the formula, explains how token counting works, walks a real monthly estimate end to end, shows a modeled cost table across models, and flags the assumptions that make estimates wrong.

The cost formula

LLM pricing is two numbers — an input price and an output price per million tokens — multiplied by how many tokens you send and receive:

cost = (input_tokens  / 1,000,000) × input_price
     + (output_tokens / 1,000,000) × output_price

That's the whole model. Everything else — monthly bills, comparisons, optimization — is this formula applied at scale. The two prices are separate because output usually costs 2-8x more than input, so a workload's shape (input-heavy vs output-heavy) matters as much as its size.

How token counting works

Tokens are sub-word chunks produced by the model's tokenizer. Useful rules of thumb for English:

• ~4 characters ≈ 1 token (so ~750 words ≈ 1,000 tokens).
• Both directions count — your prompt, system message, and any retrieved context are input tokens; the model's reply is output tokens.
• It varies — code, rare words, and non-English text use more tokens per character; run the actual tokenizer on representative samples when you need precision.

From per-request to per-month

Scale the formula by volume:

1. Estimate a typical request: input tokens (system + context + user) and expected output tokens.
2. Multiply each by your monthly request count to get monthly input and output token totals.
3. Apply the model's two prices. Add a margin (10-30%) for retries, longer-than-average requests, and accumulating multi-turn history.

A worked estimate

A support chatbot handling 200,000 conversations/month, each ~6 turns:

• Per conversation: ~200 input tokens/turn × 6 + a 1,000-token system prompt resent each turn ≈ ~7,200 input; ~150 output tokens/turn × 6 ≈ ~900 output.
• Monthly totals: ~7,200 × 200,000 ≈ 1.44B input; ~900 × 200,000 ≈ 180M output.
• On GPT-5 mini ($0.25/$2): 1,440 × $0.25 + 180 × $2 ≈ $360 + $360 = ~$720/month.
• On DeepSeek V3.2 ($0.23/$0.34): 1,440 × $0.23 + 180 × $0.34 ≈ $331 + $61 = ~$392/month.

Notice the system prompt resent every turn dominates input — caching it (see cost-cutting) would slash this estimate. That's the value of estimating before building: you spot the cost driver early.

Modeled cost across models

For reference, here are five standard workloads priced across four models with the formula — useful as a sanity-check anchor for your own estimates:

Assumptions that matter

• Workload shape — RAG is input-heavy (cheap-input models win); content generation is output-heavy (output price dominates). Estimate per workload, not as one average.
• Context reuse — a resent system prompt or retrieved context inflates input fast; decide early whether you'll cache it.
• Output length — the easiest thing to underestimate; cap max_tokens and measure real completions.
• Multi-turn growth — chat history accumulates; summarize or truncate or your per-turn input grows every turn.

Common estimation mistakes

• Forgetting input is most of RAG — retrieved context, not the answer, is the cost.
• Pricing all traffic at the flagship rate — route by difficulty and estimate the blend.
• Ignoring retries — failures and re-asks add real tokens; budget a margin.
• Treating input = output price — they differ 2-8x; use both numbers.

FAQ