How to build an AI budget that survives launch day

The first AI budget in a product spreadsheet usually looks beautifully tidy. Requests times tokens, tokens times a published rate, and a total lands in a cell that looks reassuringly precise. Launch day is less polite. People write longer prompts than your test team did, one popular account sends a burst of work, and a flaky tool quietly turns one task into three calls.

A useful budget isn't the number you're hoping for. It's a description of how the product behaves once real people show up.

Start with one whole thing a user does

Pick the action customers actually care about - answering a support question, reviewing a contract, writing a product description, finishing a piece of research - and follow it from the first click to the final result. Count every call to the AI, not just the one that produces the visible answer.

This little exercise almost always turns up calls that hid inside the diagram: a quick sort, a rewrite of the question, a safety check, a search, a formatting pass. Note how much text went in and came back for the whole thing. Include the attempts that fail, too - you pay for those even when the customer gets nothing useful.

Swap the "average user" for a few real ones

A single average hides how differently people behave. Sketch a few you'd recognise: someone who tried it once and never returned, someone who pokes at the feature now and then, someone who comes back through the week, and someone who's wired it into an automation. Their monthly costs can differ by a factor of ten or more.

Give each type a share of your customers and work them out separately. That shows whether a small group is quietly driving most of the cost. It also gives your team something real to argue about - people are far better at challenging "the power user" than a single blended number.

Budget for the messy bits

Give retries, timeouts, abandoned answers and human review their own lines. Then add the things around the model: storage, queues, logging, testing and any minimum charges. You don't need to nail these to the cent. You just need them on the page, so nobody mistakes the API subtotal for the real cost of running the feature.

Build an expected month and a busy month. A busy month should bump up both the traffic and how heavily people use it, because launches and promotions usually move both at once. Resist the comforting shortcut of raising the headcount while leaving everything else the same.

Decide what you'll do before the alarm goes off

A spending alert with no plan attached is just a notification. Write down what you'll do, in order, while everyone's calm - pause free accounts, shorten answers, move a background job to a cheaper model, switch off an expensive optional tool. Each of those has a cost to the product, so it's a launch-day conversation, not an emergency one.

After launch, compare your forecast against the real cost per finished action every week, and update those user types as behaviour shifts. The budget then becomes a living model of the product - not a document that was right for one afternoon before release.

Related reading and tools