How to estimate LLM API costs before launch

Most LLM features are billed by the token, not by the user or the seat. That makes the bill easy to work out once you know your traffic, and hard to predict before you have any. The good news is that you do not need production data to land within a useful range. You need four things: a clear definition of a request, a handful of measured samples, an honest traffic model and the current price list. This guide walks through each step, with worked examples priced from the same dataset our calculator uses.

The workload numbers below (requests, token counts, users) are illustrative. The prices are not: each one comes from the provider's own published price list, with a link and a check date on our methodology page.

Step 1: Define the unit you are paying for

The billable unit is a single API call. A user action and an API call are often not the same thing. A simple chat turn may be one call. A retrieval-augmented answer may be a query rewrite, a retrieval step and a generation call. An agent that plans, calls tools and checks its own work may make several calls per user action, and sometimes dozens.

Before you count anything, sketch the call graph for each user-facing feature: which model is called, how many times, and with what kind of prompt. Many teams route cheap work (classification, routing, extraction) to a small model and send only the hard step to a large one. If you do that, estimate each call type separately and add them up at the end. Averaging a small-model call and a large-model call into one "typical request" hides the fact that one of them drives almost all of the cost.

Step 2: Measure input tokens instead of guessing

Input tokens are everything you send: the system prompt, few-shot examples, conversation history, retrieved documents, tool definitions, tool results and, finally, the user's message. In most applications the user's own text is the smallest part. Teams that estimate from the user's message alone routinely underestimate input by a wide margin.

Conversation history deserves special attention. Unless you summarize or trim it, every turn re-sends all the earlier turns, so the tenth message in a conversation carries far more input than the first. Work out the average input across a realistic conversation length, not the input of the opening message.

The reliable way to get these numbers is to build the real prompt template, fill it with 20 to 50 realistic samples, and count them with the provider's own token counter or tokenizer. Tokenizers differ between providers and between model generations, so the same text can produce different counts. Our calculator applies one token count to every model, which is a fair simplification for a first estimate but worth remembering when two models are close in price.

Step 3: Measure output tokens, including the ones you never see

Output is where many estimates go wrong, because output tokens cost more. Across the 13 models in our data, the output price is between 3× and 8.3× the input price. Three things push output up:

• Reasoning tokens. Models that think before answering may generate tokens you never display, and providers bill them as output. Check the usage data in real responses rather than counting the visible answer.
• Verbose answers. A model asked an open question will often write more than you need. Ask for the format and length you want, and set a maximum output length so one runaway answer cannot cost ten times the average.
• Retries. If you validate output (for example, parse JSON) and retry on failure, every retry is a full extra call. Track the retry rate in testing and include it.

Step 4: Model traffic from the product, not the servers

Requests per day comes from product assumptions you can write down and argue about:

requests per day = daily active users × sessions per user per day × API calls per session

Suppose a new feature reaches 4,000 daily active users, each starting one session a day that makes five API calls. That is 20,000 requests a day. Write the assumptions down next to the number; when the real traffic arrives, you will want to know which one was wrong.

Cost depends on total volume, so average daily traffic is the right input for the bill. Peaks matter for rate limits and latency, not for the monthly total. Do remember the traffic nobody plans for: internal testing, evaluation runs, free-trial accounts and scripted abuse of an unauthenticated endpoint.

Step 5: Price it

With requests and tokens in hand, the arithmetic is short. Prices are quoted per million tokens:

cost per request = (input tokens × input price + output tokens × output price) ÷ 1,000,000 monthly cost = cost per request × requests per day × 365 ÷ 12

Here is the example workload, 20,000 requests a day with 2,000 input tokens and 500 output tokens each, priced on every model in our data with no caching or batch discounts:

The cheapest model here, Claude Haiku 5.5, comes to $273.75 a month. The most expensive, GPT-6 Astra, comes to $27,375: 100 times as much for exactly the same traffic. No other decision in your estimate moves the number that far, which is why it pays to test whether a smaller model meets your quality bar before you commit to a large one.

Notice also where the money goes. For GPT-6.1 Terra (OpenAI), output is 20% of the tokens but 56% of the cost, about $50.00 of the $90.00 spent each day. Trimming output length is often the cheapest optimization available.

Step 6: Check for long-prompt price tiers

Some models charge a higher rate once a prompt passes a size threshold, and the higher rate applies to the whole request, not just the tokens above the line. GPT-6 Astra switches tier above 272,000 input tokens. A request with 272,000 input tokens and 1,000 output tokens costs $2.77; one more input token moves it to $5.52.

If your retrieval step can stuff the context window, cap the amount it sends. The calculator applies tiers automatically based on your average prompt length, but averages hide outliers: if a tenth of your requests are very long, price those separately.

Step 7: Treat caching and batch as a second pass

Prompt caching and batch processing can cut a bill substantially, but only for the parts of your traffic that qualify. Start your estimate with both set to zero, then add them as a separate line once you know how much of your prompt is identical from call to call and how much of your work can wait for an asynchronous job. Our guide to what prompt caching and batch APIs actually save shows how to work out a realistic figure.

Step 8: Turn the point estimate into a range

A single number invites false confidence. Instead, vary the two inputs you are least sure of, traffic and tokens per request, and price a low, expected and high case. On GPT-6.1 Terra:

The high case is 12 times the low case. That spread is normal before launch, and it is the honest answer to "what will this cost?". Budget for the high case, plan around the expected case, and set a spending alert well below the high figure so you hear about a surprise in days rather than at the end of the month.

What this estimate leaves out

The token formula covers the core of an LLM bill, not all of it. Add a margin for, or measure separately:

• Fees for writing to a prompt cache and for keeping it, where the provider charges them.
• Tool, web search, image and audio charges, which are priced per call or per unit, not per token.
• Embedding calls and the vector database behind retrieval.
• Failed calls, retries and timeouts that still consume tokens.
• Evaluation runs, prompt experiments and development traffic.
• Price changes. Providers change prices and launch new models often, so recheck before you commit a budget.

A pre-launch checklist

1. List every API call each feature makes, with the model for each.
2. Build the real prompts and count input tokens on 20 to 50 samples.
3. Measure output tokens from real responses, including reasoning tokens, and set a maximum.
4. Write down users, sessions and calls per session, and multiply them out.
5. Price each call type on two or three candidate models.
6. Check whether any requests cross a long-prompt price tier.
7. Add caching and batch savings only for traffic you know qualifies.
8. Produce a low, expected and high figure, and set a spending alert.
9. After launch, compare real usage data against each assumption and update the estimate.

An estimate built this way will not be exact, but every number in it is traceable to an assumption you can test. That is what makes it useful: when the first invoice arrives, you will know which assumption to fix.