A product manager proposes a new feature: a summary of each support ticket, a draft reply, a search that answers in sentences. The developers say it is a small piece of work. Finance asks the obvious question: what will it cost every month once people use it?
Often nobody can answer, and the feature is either blocked or built and then watched nervously. You can do better. A usable estimate takes an hour and needs only a spreadsheet, a few sample prompts and the current price list of the provider. This article shows the method.
The formula
For an AI feature that calls a model through an API, the monthly cost is:
requests per month × (input tokens × input price + output tokens × output price)
A token is a piece of text, roughly three quarters of an English word. Providers charge separately for the tokens you send (input) and the tokens the model writes back (output). Output tokens are usually priced higher than input tokens, so never merge them into one average.
If you want the developer view of how API calls work, see how to use AI via API: a practical guide for developers.
Step 1: count the requests
Start from users and behaviour, not from the technology.
- How many people can use the feature in a month?
- How many of them will actually use it, and how often?
- Does one user action cause one model call, or several (for example a search, then a summary, then a check)?
Write down a low, expected and high number. If you have no data, take a similar feature that exists today, such as how often people open a ticket or run a search, and assume that a share of those actions will use the new feature.
Step 2: count the tokens in one request
Take three to five realistic examples and measure them. Most providers publish a tokenizer or return token counts in the response, so a short test with a few prompts is enough. Split each request into parts:
- Fixed instructions: the system prompt, the format rules. Same every time.
- Context: the document, ticket or search results you add. This varies the most and is often the largest part.
- User message: usually short.
- Output: the length of the answer. You control it with the instructions and a maximum length.
Context is where costs hide. Sending the whole ticket history when the last three messages are enough can double the input for no gain in quality.
Step 3: add retries and the heavy-user effect
Two corrections are often forgotten.
Retries and repeated calls. Some calls fail, some answers are rejected by a validation step and generated again, and some features call the model twice. A margin of 10 percent is a reasonable first guess until you see real logs.
Heavy users. Usage is rarely even. A small group of people, often power users or one busy team, may make several times more requests than the average. If you estimate with the average only, you will be low. Model a scenario in which about one tenth of users make five times more requests.
Step 4: take the price from the price list, on the day you decide
Prices change, and models differ a lot in price. For this reason, do not copy a number from an article, including this one. Open the current price list of the provider you plan to use, write the two prices (input and output, per million tokens) into two separate cells, and let the rest of the sheet calculate from them. When the price or the model changes, you change one cell.
A worked example (illustrative, not a client case)
To keep the example honest, it uses price units instead of real prices. Let p be the price of one million input tokens. Assume, for illustration only, that output tokens cost four times as much as input tokens. Check this ratio against your provider; it differs between models.
Imagine an invented feature: a draft reply for support tickets.
- 2,000 support agents can use it; each makes about 10 requests a month. That is 20,000 requests.
- One request: 1,500 input tokens (400 fixed instructions, 900 context, 200 user message) and 300 output tokens.
- Retries: add 10 percent, so 22,000 calls.
Expected case
- Input: 22,000 × 1,500 = 33 million tokens, which is 33 p.
- Output: 22,000 × 300 = 6.6 million tokens, which at four times the price is 26.4 p.
- Total: 59.4 p per month.
Heavy-user case. Suppose 10 percent of the agents (200 people) make 50 requests instead of 10.
- Requests: 1,800 × 10 + 200 × 50 = 28,000. With 10 percent retries, 30,800 calls.
- Input: 46.2 p. Output: 9.24 million tokens × 4 = 36.96 p.
- Total: about 83.2 p per month, roughly 40 percent more than the expected case, from only a tenth of the users.
Now put a real price into p from today's price list and you have two euro figures. The method matters more than the numbers: the answer to "what will it cost?" is a range with a stated assumption behind each number.
Step 5: add a buffer and find the cheap levers
Take the heavy-user figure and add a buffer for what you did not think of, 20 to 30 percent at the start. In the example, a monthly cap of about 100 p leaves room above the heavy case and is less than twice the expected case.
Before you accept the figure, check the levers that reduce it without hurting the result:
- Shorter context: send only the part of the document the model needs. In the example, cutting the context from 900 to 600 tokens reduces the input by 300 tokens per call.
- Shorter output: ask for the length you need and set a maximum.
- A smaller model for easy cases: use a cheaper model for simple requests and the stronger one only when needed. Test the quality on your own samples first.
- Reusing answers: if many users ask the same thing, store the answer for a limited time.
Step 6: set the cap before launch
An estimate is a guess, and the first month with real users will correct it. What protects you in the meantime is a limit.
- Set a monthly cap at your provider or in your own gateway, at the figure from step 5.
- Set an alert at about 50 and 80 percent of the cap, sent to a named person.
- Decide what happens at the cap: the feature slows down, switches to a cheaper model, or turns off with a clear message to users.
- Log the tokens per request from day one, so that next month you replace assumptions with measurements.
For how to set these rules for a spending plan, see a monthly AI spend plan: credits, alerts, owner and what happens at the cap and AI agent cost controls: budgets and loop limits. If your tools are moving from flat subscriptions to credits, this budget guide explains how that changes planning.
Do not forget the rest of the bill
The API charge is only part of the cost. The same feature also needs engineering time, testing, monitoring and someone who owns it after launch. For the full picture over a year, read AI agent total cost of ownership: annual budget planning. Treat the API estimate as the variable part of a larger budget.
What to do this week
Pick the feature you are considering and take five real sample inputs. Measure their tokens, fill in the five steps in a spreadsheet with the price as a separate cell, and write down the low, expected and heavy case. Then agree on the cap and the person who receives the alerts. If the heavy case is unacceptable, you have found it before building, which is exactly when a change is cheap.
