How to calculate AI API costs

The second most common question in AI projects is "what will it cost?" and it is actually answerable. This piece explains how the calculation is done.

What is a token?

Language models process text not word by word but in units called tokens. Roughly, one token is about four characters in English. The ratio is worse in other languages: the same text in Turkish takes noticeably more tokens than its English equivalent.

That detail matters, because an application working in a non-English language costs more than one doing the same job in English.

Cost has two components

Input. Everything you send to the model: the system instruction, the user's question, and any document content you attach.

Output. What the model produces. It is usually priced higher than input.

The key point: in systems that answer from your own documents, most of the cost comes from input. Every question also carries the relevant document excerpts along with it.

What does one request cost? A worked example

Say you are building an assistant that answers customer questions from your own documentation:

• System instruction: about 400 tokens
• The user's question: about 60 tokens
• Attached document excerpts: about 2,000 tokens
• Generated answer: about 300 tokens

That is roughly 2,460 input tokens plus 300 output tokens.

You multiply those figures by the per-token price of the model you are using. Then by daily request volume, then by 30.

That is all there is to it. And because almost nobody does it, the bill comes as a surprise.

Four ways to bring the cost down

Choose the right model. Not every job needs the most capable model. Classification, tagging, and short summarisation work well on small, cheap models. Move to a stronger model where genuine reasoning is required.

Shorten the context you send. Send the excerpts genuinely relevant to the question, not the whole document. This is usually the largest cost line and the biggest saving.

Cache repeated input. If the system instruction is identical on every request, the caching features providers offer cut that portion of the cost substantially.

Limit answer length. Output tokens are expensive. Do not ask the model for longer answers than you need.

Budget controls

Set up two things before going to production.

A monthly ceiling. Define a spending limit in the provider's console. It acts as a brake against an unexpected loop or abuse.

Per-request measurement. Record how many tokens each request consumes. That way you can see where the cost comes from instead of guessing.

Measure during a pilot

The method we recommend: run a 50-example pilot with your real data, measure average token consumption, and multiply by your expected volume.

That gives you a real number before you go to production. If accuracy is insufficient or the cost does not make sense, the project stops there and you have lost nothing.

Prices are falling, but you still need the arithmetic

Model prices have fallen steadily in recent years and continue to fall. That is not a reason to assume it will be cheap.

For two reasons. First, as prices fall usage rises, and the total bill tends to stay where it was. Second, you need to know whether a project is economically sensible at today's prices.

And the real value of the calculation is not the bill estimate. The calculation tells you whether the project makes sense at all. If a request costs more than it earns the business, the project should stop before any code is written.

Hidden cost items

Token charges are not the only line. These also reach the bill:

Retries. The model occasionally responds in a malformed way and the request is repeated. Every retry is charged in full. In a well-built system the retry rate is low, but it is not zero.

Abuse. A publicly accessible assistant becomes a target. An assistant published without rate limiting and user verification can run up a bill overnight.

Testing and development. The hundreds of trial calls made during development are billable too. It is a small line, but it belongs in the budget.

Embedding costs. Systems that answer from your own documents have to process those documents once. Every time the documents are updated, that processing repeats.

When not to use AI

Some jobs do not need a language model, and using one is both expensive and unnecessary.

Calling a model for a classification that fixed rules could handle, a simple search, or a calculation is like driving a screw with a hammer. You get a result, expensively and unreliably.

A practical test: if the output has to be identical every time and a rule can be written, conventional code is cheaper and gives a definite answer. Language models earn their keep where the rule cannot be written.

We cover that distinction and the typical first-project mistakes in five mistakes when building an AI agent.

---

If you have a specific use case in mind, we can work out its cost together. See AI integration.