Estimate an AI feature's LLM bill before you ship it

Answer first: you can forecast an AI feature's monthly LLM bill to within roughly 20 percent before you write a line of code. You need four inputs - requests per month, input tokens per request, output tokens per request, and a per-model price - plus a buffer for the line items most estimates forget.

• Monthly cost is approximately (requests x input tokens x input price) plus (requests x output tokens x output price), divided by 1,000,000.
• The naive number is almost always low. It forgets retries, system-prompt overhead, retrieved context, and conversation history that grows across a session.
• Run the math before you build. A call that costs 3 cents is fine at 10,000 requests a month and a budget problem at 5,000,000.

The formula that gets you within 20 percent

Token pricing is quoted per million tokens, split into input (what you send) and output (what the model generates). Output usually costs 4x to 8x more than input, so the shape of your feature matters as much as the volume.

A useful conversion: 1 token is about 4 characters of English, or about 0.75 words. So 1,000 tokens is roughly 750 words, or about a page and a half of text. Estimate your prompt and expected answer in words, divide by 0.75, and you have token counts good enough to plan with.

Representative published list prices in mid-2026, per million tokens (always check the current rate before you commit a number): GPT-5 around 0.63 dollars input and 5 dollars output; GPT-5.4 around 2.50 input and 15 output; Claude Sonnet 4.6 around 3 input and 15 output. Cheaper small models sit well under a dollar per million on both sides. The spread between a frontier model and a small one is often 10x to 40x, which is why model choice is the single biggest lever on the bill.

Plug in a concrete request. Say a feature sends 1,500 input tokens and gets back 400 output tokens on Claude Sonnet 4.6. That is (1,500 x 3 + 400 x 15) / 1,000,000 = 0.0105 dollars per request, about 1 cent. At 200,000 requests a month that is roughly 2,100 dollars. Change the model to a small one at 0.20 input and 0.80 output and the same feature drops near 250 dollars. Same product, very different infrastructure decision.

The four costs teams leave out of the estimate

The formula above is the floor, not the bill. Four line items routinely push the real number 30 to 80 percent higher than the first estimate.

Retries and timeouts

LLM providers run around 99 to 99.5 percent uptime, noticeably worse than the cloud underneath them. Any production feature retries on 429s and 5xxs, and every retry re-sends the full input tokens. A modest 8 to 12 percent retry rate is a direct 8 to 12 percent add to input spend, and a naive retry loop with no budget can multiply it. Budget for retries explicitly and cap them, the same way you would stop an agent from burning tokens in a loop.

System prompt and few-shot overhead

Your instructions, tool definitions, and few-shot examples ride along on every single call. A 900-token system prompt on a feature that only needs 200 tokens of real user input means 80 percent of your input cost is fixed overhead you pay per request. That is exactly the overhead that prompt caching is built to reduce, so if your prefix is stable, price the cached rate, not the full one.

Retrieval tokens in a RAG feature

If the feature does retrieval, the chunks you inject are input tokens too. Pulling 6 chunks of 500 tokens each adds 3,000 input tokens to every question, often dwarfing the user's actual query. Reranking down to the 2 or 3 chunks that matter is a cost lever, not just a quality one. This is one reason the model and platform you pick changes the math so much at RAG volumes.

Conversation history growth

Chat features re-send the running transcript on every turn. Turn 1 might be 500 tokens; turn 10 can be 6,000 as history accumulates. Cost per conversation grows faster than linearly with length. If you do not cap context or summarize old turns, a chatty power user costs many times what your average-request estimate assumed.

A worked example: a support copilot

Suppose you are pricing a support copilot for a B2B SaaS product. Assumptions: 120,000 questions a month, a 700-token system prompt, 4 retrieved chunks at 400 tokens each, a 150-token user question, and a 450-token answer, on a mid-tier model at 3 dollars input and 15 dollars output.

Input per call is 700 + 1,600 + 150 = 2,450 tokens. Output is 450. So (2,450 x 3 + 450 x 15) / 1,000,000 = 0.0141 dollars per call. At 120,000 calls that is about 1,690 dollars. Add a 10 percent retry buffer (169 dollars) and the honest forecast is roughly 1,860 dollars a month, not the 800 dollars you would get from counting the user question and answer alone. The overhead - system prompt plus retrieved context - is the majority of the bill, which tells you exactly where to optimize.

When the forecast says too expensive

A forecast is useful precisely when it comes back red. Before you cut the feature, work the levers in order of impact. Route easy requests to a cheaper model and reserve the frontier model for hard ones, which is the core idea behind model routing. Cache the stable prompt prefix. Trim retrieved context with reranking. Cap conversation history. Teams routinely walk a feature from unaffordable to shippable this way, as in this walk from 48k to 19k a month. If you sell the feature per seat, also model the worst case per customer with per-tenant cost caps so one heavy account cannot erase the margin on the rest.

If you want a faster first pass on the numbers, our savings calculator and a look at what we build can frame the estimate against a real delivery plan.

Frequently asked questions

How accurate is a pre-build LLM cost estimate?

Within about 20 percent if you include the four overhead costs and use real token counts rather than word guesses. The biggest source of error is forgetting that system prompts and retrieved context ride on every call.

Why is output priced higher than input?

Generating tokens one at a time is more compute-intensive than reading the prompt, so providers price output 4x to 8x higher. Features that produce long answers are far more sensitive to volume than features that classify or extract.

Should I forecast on the frontier model or a cheap one?

Forecast both. The gap is often 10x to 40x. Many features only need the frontier model for a minority of hard cases, so a routing strategy lets you quote the cheap model for most traffic and keep quality where it counts.

What is the single most common estimating mistake?

Counting only the user's message and the model's answer. In most real features the system prompt plus retrieved context is the majority of input tokens, and retries add a steady tax on top.