How to Forecast Your AI Bill for Next Month

Most people forecast their AI bill by looking at last month's invoice and adding a bit. That works until something changes, and something always changes, usually in the direction of costing more.

A better method takes about twenty minutes and needs three numbers you can measure today.

The three numbers

**One: tokens per operation.** Not per month. Per single unit of work, measured from real traffic rather than estimated from the prompt's length. Input and output separately, because they are priced differently and the gap is usually four to one or worse.

**Two: operations per day.** How many times the thing happens. If you have several distinct operations, which most products do, each one gets its own line.

**Three: the price per million tokens**, input and output, for the model each operation actually uses. Check the current page rather than working from memory, because these change.

Then the arithmetic, per operation:

daily cost = ops_per_day
           x ((input_tokens  / 1,000,000) x input_price
           +  (output_tokens / 1,000,000) x output_price)

monthly cost = daily cost x 30

A worked example

A support assistant. Measured from a week of real traffic: 3,200 input tokens and 450 output tokens per conversation, 240 conversations a day, running a model at $1.00 per million input and $5.00 per million output.

Input: 3,200 / 1,000,000 x $1.00 = $0.0032 per conversation.

Output: 450 / 1,000,000 x $5.00 = $0.00225 per conversation.

Total: $0.00545 per conversation.

At 240 a day that is $1.31 daily, or roughly **$39 a month**.

Note what the shape tells you. Input is 7.1 times the output in volume and only 1.4 times the cost. If you want this bill lower, the output price is where the leverage is, which usually means a cheaper model rather than a shorter prompt.

The honest multiplier

Now multiply by 1.3.

That is not padding, it is the gap between what your code intends and what your account is billed for, and it is remarkably consistent. If you have your own retry and error figures, use them. If you do not, 1.3 is closer than 1.0.

The example becomes **about $51 a month**. Four things make up that difference.

1. Retries

Every timeout, rate limit and malformed response that triggers a retry bills again. A 5% failure rate with one retry is 5% more tokens. An agent retrying three times on a persistently failing step is far worse, and that is the case that produces surprise invoices.

2. Context grows and nobody notices

Your prompt today is not your prompt in three months. Someone adds an instruction after a bad output. Someone adds three examples. Someone adds a retrieved document to improve accuracy.

Each change is small, justified, and permanent. Input tokens per operation drift upward all year and nobody re-measures, because the feature still works. Re-measure quarterly, and compare against the number you forecast with.

3. Cache assumptions that do not hold

If your estimate assumes cached input pricing, check the actual hit rate rather than the theoretical one. Caches miss on the first request, after expiry, and whenever anything in the cached prefix changes, which includes the small prompt edits above. A forecast built on a 90% hit rate against a real 55% is wrong by a lot. Prompt caching covers when it applies.

4. Agents multiply steps, not tokens

This is the one that breaks forecasts entirely.

A single call is one unit. An agent is a loop, and the loop length varies with the task. If an agent averages eight steps and each carries the growing conversation as input, your cost per task is not eight times a single call, it is closer to the sum of a growing series. Doubling average steps more than doubles the bill.

Forecast agents by measured cost per completed task, taken from real runs, and never by multiplying a single call. If you cannot measure it, that gap is itself the finding, and agent observability is what closes it.

Build the table

Three lines tell you more than one total. In this table the background job is the largest line and the least visible one, which is typical, and it is also the one most likely to be shiftable to cheaper hours. Off-peak API pricing applies to exactly that row and to none of the others.

Checking yourself

Forecast one month, then compare against the invoice. Being wrong is expected. Being wrong in a direction you cannot explain is the problem, and the explanation is nearly always one of the four effects above.

After two cycles the estimate gets good, and a good estimate is what lets you price a product, quote a client or decide whether a feature is worth shipping. Estimating tokens for a task is the measurement step underneath all of this, and reducing API costs is what you do once the table shows you where the money goes.

Sources: current per-token rates should be read from provider pricing pages directly, such as Anthropic's published pricing, since they change without notice.