Estimate what an AI feature will cost you per month
Token maths, the multipliers people forget, and the two costs that dwarf inference.
Before you start
- A defined feature
- A rough estimate of monthly usage
What you will be able to do
- Convert a feature description into a defensible monthly number
- Account for the multipliers that break naive estimates
- Put a cap in place before the first invoice, not after
The arithmetic is simple and the inputs are the problem. Nobody misprices the model; they misprice how many times it gets called and how much goes in each call.
Work through it in this order and the estimate lands within a factor that will not embarrass you.
Measure one real request end to end
Actual token counts from an actual call. Estimates are wrong by multiples.
Build one representative request and read the token counts the API returns for input and output separately — they are priced differently, often by a factor of three or more.
Use a realistic input. People estimate with a tidy example and ship with documents ten times the size, which is the single largest source of error in the whole exercise.
Count what you resend every time
The system prompt and the conversation history are billed on every call.
A long system prompt is charged on every single request. In a chat feature the history is resent each turn too, so a twenty-turn conversation is not twenty short requests — it grows quadratically and the last turns cost many times the first.
This is where "it is fractions of a cent" becomes a real invoice. Check whether your provider offers caching for the fixed prefix; it is frequently the largest single saving available.
- Price the longest plausible conversation, not the average one. The tail is where the budget goes.
Multiply by the things that are not one
Retries, validation passes, and users who try again.
Almost nothing is one call per user action. Add failed calls that get retried, any second call that validates or reformats the first, and the user who was unhappy and regenerated.
A factor of 1.5 to 3 over the naive count is normal. Assuming 1.0 is how estimates come in at a third of reality.
Add the costs that are not inference
Embeddings, storage and engineering time usually exceed the model bill.
If you are doing retrieval, embedding the corpus is a one-off and re-embedding on every change is not. Vector storage is priced monthly. Monitoring and evaluation are real line items.
And the engineering time to build and maintain it is, for most features, larger than the entire model spend. An estimate that omits it is not an estimate of the feature.
Warning Set a hard cap and an alert on day one
The runaway loop is a when, not an if.
Set a spending limit at the provider and an alert at a fraction of it, before the feature is live. A bug that retries in a loop, or a script left running over a weekend, can spend a month's budget in hours.
Per-user rate limits matter too — the cost is unbounded per user by default, and one enthusiastic customer can cost more than the rest combined.
Measure one real request, multiply honestly, then add the retries and the failures. A cap and an alert are not optimisation — they are the difference between a surprise and an incident.
Common questions
Was this guide useful?
75% of readers found this useful
Read next
Write an AI usage policy your team will actually follow
A restrictive AI policy does not stop people using AI. It stops them telling you, which is considerably worse.
Run an AI pilot that produces a decision, not a demo
A pilot that cannot fail is not a pilot. Setting the success threshold before you start is what turns an interesting experiment in…
Connect two apps with an AI step in the middle
The genuinely useful automations are not the clever ones. They are a trigger, one AI step that makes a small judgement, and a writ…
Write ad variants and test them properly
AI removes the cost of writing variants, which makes it very easy to run tests that cannot teach you anything. The discipline is i…
