How to Estimate LLM API Token Cost Before the Bill Arrives

The first time an LLM feature goes from demo to production, the surprise is rarely the model quality. It is the invoice. A prototype that cost a few dollars a week during testing can turn into a four-figure monthly line item the moment real traffic shows up, and the jump usually has nothing to do with switching models. It is the same model, the same prompt, just multiplied by volume nobody priced out in advance.

This guide walks through how LLM API billing actually works, why input and output tokens are charged at different rates, and how to forecast the cost of a chatbot or a batch job before you commit to it. If you want to plug your own numbers in while you read, the LLM Pricing Calculator does the arithmetic and shows the input/output split for you.

The core formula

Almost every provider prices the same way, and the formula is short enough to memorize:

cost = (input tokens × input rate) + (output tokens × output rate)

Rates are quoted per million tokens. So if a model lists input at $0.50 per million and output at $1.50 per million, a request that sends 500 input tokens and generates 300 output tokens costs:

Input: 500 / 1,000,000 × $0.50 = $0.00025
Output: 300 / 1,000,000 × $1.50 = $0.00045
Total: $0.0007 per request

That fraction of a cent is why per-request math feels safe and why production math surprises people. The number is tiny until you multiply it by request volume, and request volume is the variable that moves the budget faster than anything else.

Why output tokens cost more

Look again at that example. The request had more input tokens than output tokens (500 versus 300), yet the output side of the bill was larger. That is not a quirk. Most providers price generated output two to four times higher than input, because generating tokens one at a time is more compute-intensive than reading a prompt that is already written.

The practical consequence: two workflows with identical total token counts can have very different costs. A retrieval-augmented chatbot that stuffs 4,000 tokens of context into the prompt and returns a 200-token answer is cheap on the output side. A drafting assistant that takes a one-line instruction and writes 1,500 tokens of prose is expensive, even though its total token count is smaller. When you estimate, never collapse input and output into a single "tokens per request" figure. Split them, or the cheap-looking workflow and the expensive one will read the same on paper.

A worked example: pricing a chatbot at scale

Here is the calculation I run before greenlighting any production feature. Suppose a support chatbot handles 10,000 requests per day, each averaging 500 input tokens and 300 output tokens, on a model priced at $0.50 / million input and $1.50 / million output.

Per request, from the formula above, that is $0.0007. Now scale it:

Daily: 10,000 × $0.0007 = $7.00 per day
Monthly (30 days): $7.00 × 30 = $210 per month

Break the monthly figure down by side and the output dominance shows up clearly:

Input per month: 10,000 × 30 × 500 / 1,000,000 × $0.50 = $75
Output per month: 10,000 × 30 × 300 / 1,000,000 × $1.50 = $135

Output is 64% of the bill while being only 37.5% of the tokens. If this number needs to come down, trimming the system prompt barely helps. Capping or shortening the generated answer does. That is the kind of decision the split makes obvious, and it is invisible if you only track a blended cost.

The mistake that doubles every estimate

The single biggest forecasting error is counting one user action as one model request. Modern LLM features rarely call the model once. A single "send" in a chat box might trigger a routing call to pick an intent, a retrieval-ranking call, a drafting call, and a final scoring or guardrail call. That is four model requests dressed up as one user message.

When I first sized an internal agent, I budgeted from the user-facing action count and was off by nearly 3x within the first week of real usage. The fix was boring but reliable: count model calls, not user actions. Multiply your expected user actions by the number of model calls each action makes, and use that product as your requests-per-day input. The number feels uncomfortably large, which is exactly why it is the right one.

Budgeting a batch job

Batch jobs flip the risk profile. There are no concurrent users to worry about, but there is a fixed quantity of work and often a deadline. The math is the same formula applied to a total instead of a daily rate.

Say you need to summarize 2 million documents, each averaging 1,200 input tokens and 250 output tokens of summary, at the same rates:

Input: 2,000,000 × 1,200 / 1,000,000 × $0.50 = $1,200
Output: 2,000,000 × 250 / 1,000,000 × $1.50 = $750
Total: $1,950 for the run

Two things matter here. First, many providers offer a discounted batch tier (often around half price) for non-real-time work, so a job like this is one of the few places a single billing decision can cut the bill in half. Second, retries count. If 5% of documents fail validation and get reprocessed, that is another $97 you did not plan for. Build a retry margin into the estimate rather than discovering it in the reconciliation.

A checklist before you ship

A few habits keep estimates honest:

Measure real token counts, do not guess them. Run a representative sample of prompts and responses through a counter rather than eyeballing word counts. A quick pass through the AI Token Counter will tell you whether your "short" prompt is actually 400 tokens or 1,100.
Forecast at production volume, not prototype volume. A feature that costs $2 a day at 100 requests costs $200 a day at 10,000. Run the number you expect to hit, not the one you have today.
Price the spikes. Launch days, background jobs, and reprocessing all push real volume above the average. Budget for the peak you can reasonably foresee.
Treat preset prices as planning values. Vendor rates, cache discounts, regional pricing, and enterprise contracts all move. Confirm the live rate before procurement signs anything.

The point of estimating is not to predict the bill to the cent. It is to catch order-of-magnitude surprises while they are still hypotheticals. The formula is simple, the input/output split is where the cost actually lives, and request volume is the multiplier that turns a rounding error into a budget meeting. Get those three things on paper before you promote a feature, and the invoice stops being a surprise.

Made by Toolora · Updated 2026-06-13