How to estimate your monthly LLM bill before you build

Most cost surprises are not pricing surprises. The per-token rate was published, correct, and read in advance. What went wrong was the model of how many tokens a real request actually consumes.

Here is a forecast method that holds up, and the three omissions that break the ones that don't.

The four numbers#

You need:

1. Tokens in, per request — your system prompt, plus the user's input, plus anything you retrieve and inject.
2. Tokens out, per request — the answer's length, not its limit.
3. Requests per month.
4. The model's input and output prices.

Then:

monthly = requests × (
    tokens_in  × input_price_per_million  / 1_000_000 +
    tokens_out × output_price_per_million / 1_000_000
)

Measure the first two rather than guessing. Take five or ten representative prompts, paste each into the calculator, and take the median instead of the mean — one enormous outlier will drag a mean somewhere unhelpful.

A worked example on GPT-4o at $2.50 in and $10 out, with 2,000 tokens in and 500 out across 100,000 requests: input is $500, output is $500, total $1,000 a month.

The three things forecasts miss#

Your system prompt is charged on every single call. This is the most common omission because the system prompt feels like configuration rather than payload. A 600-token instruction block across 100,000 requests is 60 million input tokens a month — on GPT-4o, $150 before any user has typed anything. If you are iterating on prompt wording, you are iterating on a recurring line item.

Multi-turn conversations resend their history. In a chat interface, every prior turn goes back as input on the next request. A ten-turn conversation does not cost ten times turn one; it costs roughly the sum of a growing sequence, because turn ten carries all nine before it. Estimate a conversation, not a request, or your forecast will be low by a multiple rather than a margin.

Retries are billed in full. A response that fails to parse and triggers a second attempt costs twice. So does a client timeout that retries, and so does a validation loop that asks the model to correct itself. If your error path retries twice, your worst case is three times your estimate, and worst cases are not rare at scale.

Sanity checks before you commit#

• Recompute at 10x volume. A number that is comfortable at your launch estimate and alarming at ten times it is worth knowing about now, while the model choice is still cheap to change.
• Check the output ratio. Every model charges four to five times more for output than input. If your forecast has output as a small share of the total, either your responses are genuinely short or you have underestimated them — and the second is far more common.
• Price the fallback too. If you fail over to a second provider during an outage, that provider's rate applies for the duration. A fallback on a frontier model is a fine reliability decision and an expensive default.
• Set a budget alert, not just a forecast. Every provider offers one. A forecast tells you what should happen; an alert tells you when it didn't.

Then measure the real thing#

A forecast is a hypothesis. Once traffic is real, compare it against the provider's own usage reporting — which is authoritative in a way that any estimate, including this calculator's, is not.

Where they disagree, the gap is usually one of the three items above. It is almost never the price.