How to estimate a monthly LLM bill

The estimate is requests times tokens times rate

To estimate a monthly LLM bill, multiply requests per month by average input tokens per request, divide by a million and multiply by the input rate; do the same for output with the output rate; then add the two. Every other refinement, such as cached input or a batch tier, adjusts one of those terms. Most of the work goes into honest averages for your own traffic.

The rates are the easy input. The token price table holds them, each with the page it was read from (models priced: 467; providers: 16). The other two numbers have to come from you.

Fix the period first. A month here means the billing month the seller uses, so count requests over the same days. Estimates built on a week and multiplied up miss end-of-month reporting jobs and the quiet weekends that pull the average down.

Getting the request count right

Start from users, not from calls. Active users per day, times the actions per user that hit a model, times the days in a month. Then ask how many model calls one action really makes, because a single click often triggers several: a rewrite of the query, a retrieval step, the answer, a safety check.

Background calls go on top. Scheduled summaries, evaluation runs, re-processing when a prompt changes. These have no user attached and are easy to leave out of a spreadsheet built from the product's front end.

Count the people building the product too. Engineers testing prompts, a staging environment running the full pipeline and a demo account left open for sales all spend tokens on the same rates. Some teams give these a separate key so they show up as their own line.

Measuring tokens per request

Guessing tokens from word counts is the step that makes estimates wrong. Every API response reports the input and output tokens it billed. Run a few hundred realistic requests against the model, log those two numbers, and take the average of each.

Look at the spread as well as the mean. A chat feature where most conversations are short and a few run very long will have an average dragged up by the long tail, and that tail is real money. Where the data allows, keep separate averages for the short and long cases and multiply each by its own request count.

Before a product exists, prototype the prompt and measure that. A prompt built in an afternoon with the real system message, a realistic retrieved context and a sample question gives a better number than any rule of thumb about characters per token.

A worked estimate for a meeting-notes feature

Each meeting produces a transcript and the feature returns notes and actions. Requests per month are meetings per user per month times users. Input per request is the transcript plus the instructions, which you measure from a sample of real recordings. Output per request is the notes, measured the same way.

Input tokens for the month are requests times average transcript tokens. Output tokens are requests times average note length. Each is divided by a million and multiplied by its rate. Where users can ask follow-up questions about a meeting, add those as a second line, with the transcript counted again as input on every follow-up unless the seller prices cached input.

Put the two monthly token totals into the LLM cost calculator and it prices them at every seller of the models you pick, cheapest first. The sliders set input tokens per month, output tokens per month and the cached share.

What to add before you show anyone the number

Retries are billed. Calls that time out, return malformed output or get regenerated by the user all count. Development and testing traffic counts. For a growing product, the month you budget for is not the month you measured.

Give the estimate as a range. Run it once with your measured averages and once with the long-tail averages, and present both. A single figure invites the question of why the invoice was different.

The calculator uses list rates at most 21 days old and does not model negotiated discounts, so a real bill under a contract may be lower. The page states that beside the result.

Keeping the estimate honest after launch

An estimate is a forecast, and a forecast needs checking against what happened. At the end of the first month, set the invoice beside the estimate line by line: requests, input tokens, output tokens. The term that missed most is the one to model more carefully next time.

The request count is a frequent miss, because a feature meant to be occasional can become something users run on every page. Token averages measured from real prompts have a firmer basis.

Rerun the estimate whenever the product changes a prompt, adds a retrieval step or switches model. Each of those changes one term of the formula, and it is cheaper to see the new month on a calculator than on the following invoice.

Write the estimate down with its inputs: requests, average tokens on each side, cached share, tier and the date the rates were read. A total on its own cannot be checked. A total with its inputs can be rerun by anyone, including whoever inherits the budget next quarter.