AI API costs: how to calculate them

AI model APIs are paid for per consumption, measured in tokens. It is a different price model from what companies are used to: there is no fee per user, you pay for the work actually done. This means that the cost scale with the success of the system, and it is the voice that should be estimated first and monitored later.

The good news is that for most SME projects this entry is marginal compared to development. The bad news is that some design choices can multiply it by ten without anyone noticing until the invoice.

What Tokens Are and Why They Matter

A token is the unit in which models measure text: roughly a short word is a token, a long one can be worth two or three. The concept is explained in detail in AI tokens: what they are and why they matter.

For the purpose of cost, two rules are sufficient:

• Pay Everything you send: instructions, attached documents, conversation history
• Pay Everything you receive: the response generated, usually at a higher rate

The first rule is the one that surprises. Many companies think they pay for the answer and instead the dominant voice is often the input: if you send twenty pages of context to each question, you pay twenty pages each time.

The Three Mistakes That Multiply Your Bill

Excessive background. Giving the model the entire manual for each request instead of the three relevant paragraphs. It costs a lot more and contro counterintuitively — makes the answers worse, because it increases the noise. The correct way to select only useful parts is the one described in RAG: what is it.

Conversation relaunched in full. In a long chat, if all the history is sent back to each message, the cost increases in a quadratic way: message number fifty carries the previous forty-nine. The solution is to summarize periodically and send the summary.

Oversized model. Using the most powerful model to classify an email into three categories is like using a truck to carry a letter. It works, costs ten times as much, and the quality doesn't change.

How to estimate consumption before leaving

The estimate is made with three numbers and does not require any particular tools. For a decision system the estimate must be linked to the number of useful requests and revisions: the guide to JEV API Pricing and Costs applies this calculation to a specific service.

1. How many requests per month Will it run the system?
2. How much text enters on average per request: instructions, context, documents?
3. How much text comes out On average as an answer?

Multiplying by the published rates of the chosen model results in a reasonable estimate. Add a margin, because the actual text is always longer than imagined and because there will be attempts.

Those who give you a serious estimate should provide you with this estimate, not a "depends". If they do not provide it, ask for it: it is the voice that will accompany you for years.

The Mixed Strategy

This distribution, applied to a real system, often reduces consumption sensitively compared to using only one powerful model for everything. The criterion of choice between models is deepened in how to choose an AI model and in best AI models for companies.

Practical examples

Internal assistant for summaries, study of ten people. Fifty requests a day, documents of a few pages. Monthly consumption remains in the order of a few tens of euros. Optimizing here doesn't make sense: the time spent filing would cost more than saving.

Chatbot on e-commerce with good traffic. Thousands of conversations a month, each with multiple messages. Here, usage becomes a real cost line item and design choices matter: summarising conversations, limiting context to relevant documents, and using a lightweight model for initial routing.

Massive document processing. Thousands of documents to process each month, each long. This is the case where consumption can exceed the share of development distributed over time, and where it is also worth evaluating the internal execution with Local AI Models, which shifts the cost from variable to fixed.

What changes between paying on consumption and paying on a fee

The distinction also applies to Moonshot: the Kimi app plans and the Kimi API prices have different counters. For an integration, the quote must be built on the actual calls and the categories of tokens billed.

The token model disorients companies accustomed to software licenses, and it is worth understanding why the difference is not just accounting but strategic.

With a user license the cost is predictable and grows with people. With consumption the cost is variable and grows with the work done. The practical consequence is counterintuitive: a system that works well and is used a lot costs more than one that no one uses. It is the opposite of what you are used to, and it needs to be explained to those who control the budget before the first bill arrives above expectations.

However, there is one important advantage that one loses sight of: You only pay what you really need. A system used by three people intensively and by twenty occasionally, with licenses would cost twenty-three seats; to consumption it costs the actual work. For many SMEs, where use is concentrated in a few people, this makes the token model significantly more convenient.

The complete comparison between the two models is in AI by subscription or customized.

An order of magnitude to orient yourself

Without reference to specific price lists, which change continuously, it is useful to have a reference on how consumption is distributed between types of use.

An internal assistant used by a few people for summaries and drafts generates a consumption that in most cases remains negligible compared to any other corporate voice. A system that responds to customers with significant volumes generates consumption that becomes a recognizable but rarely dominant balance sheet item. Massive document processing, with thousands of long documents per month, is the only scenario where consumption can compete with the cost of development distributed over time.

The practical rule: if your case looks like the first two, estimate and move on; if it looks like the third, plan carefully from the beginning and also evaluates alternatives such as internal execution.

Mistakes to Avoid

• Not estimating usage during project design. It is the only voice that grows with use.
• Not enabling limits and monitoring. Surprises are discovered at the end of the month.
• Using only one model for everything. Almost always it means paying too much for simple tasks.
• Sending too much context. It costs more and makes the answers worse.
• Optimizing too soon. On low volumes saving does not pay back the time spent.
• Trusting price lists reported by third parties. They change often: check the official source.

How to apply it in the company

Always ask three things who offers you a system: the estimate of monthly consumption with the numbers used to calculate it, which model is used for which task, and what limits are provided to avoid unexpected consumption.

After release, look at the actual consumption for the first two months and compare it to the estimate. If it is much higher, almost always the cause is one of the three listed above and corrects itself. The monitoring of recurring costs is part of the ordinary maintenance, treated in how much it costs to maintain an AI system.

A final recommendation concerns monitoring over time. Consumption is not an item you estimate once and forget: it changes when volumes change, when functions are added, and when you replace the model. Watching it once a month for the first six months allows you to intercept drifts when they are still small, instead of discovering them from an oversized bill.

For updated numbers and model by model comparison, Cost per task or price per token, Price per million tokens explained and How much you save with a lightweight model.

Conclusion

AI APIs are paid for on consumption, and for most business projects this entry is secondary to development. It becomes dominant only in high-volume scenarios, and almost always for correctable design choices.

The practical rule: estimate first, activate the limits from the first day, use the light model where enough. Three devices that keep your voice in check without touching the quality of what the system does.

If you want to understand what processes in your company can be automated with AI, Giallo Studio can help you turn the problem into a real workflow.