How to Estimate the Running Cost of an AI Feature Before You Build It

The assistant that did the work of 700 people

In February 2024, the Swedish payments company Klarna launched an AI customer service assistant and published results that went around the world. In its first month, the company said, the assistant handled 2.3 million conversations — two-thirds of all its customer service chats — doing work equivalent to 700 full-time agents. Resolution times fell from eleven minutes to under two. Klarna projected a $40 million improvement in profit that year.

Klarna wanted what every company with a busy support desk wants: faster answers, lower cost, and service that scales without hiring in step with growth. The external problem was volume. The internal pressure was just as real — to show that AI investment was paying off, quickly and visibly. And beneath both sat a belief most customers would share: people deserve fast help, and a human when it really matters.

The estimate that justified the programme was, above all, a cost estimate. It counted conversations handled and agents' work avoided. What it weighed less heavily was the cost of an answer that is fast but not good enough.

By May 2025, chief executive Sebastian Siemiatkowski was telling Bloomberg that the company had focused too much on efficiency and cost, and that the result had been lower quality. Klarna began recruiting human agents again and committed to giving customers the option of reaching a person.

The story didn't end there, and that is the useful part. Once the human layer was designed back in, the economics still worked. By late 2025 Klarna reported that the assistant was doing work equivalent to 853 full-time staff, with around $60 million in savings. The AI was never the problem. The estimate was incomplete. It priced the tokens and the labour saved, but not the escalations, the repeat contacts and the cost of getting an answer wrong.

That is the most important lesson for anyone about to commission an AI feature. The model bill is usually the easiest line to calculate and, surprisingly often, the smallest. A reliable estimate prices everything else as well.

Why most estimates miss

Search for how to estimate AI running costs and you will find the same formula in almost every guide: tokens in multiplied by the input price, plus tokens out multiplied by the output price, multiplied by the number of requests. The formula is correct. It is also a fraction of the answer.

It leaves out the text you send with every request without thinking about it — system instructions, retrieved documents, conversation history. It assumes one model call per task when many features make several. It ignores retries, failed attempts and hidden reasoning. It says nothing about the infrastructure around the model, and nothing at all about the people who handle what the AI cannot. And it produces a single number, when the honest answer is always a range.

The seven-line estimate

A complete estimate fits on one page and has seven lines. You can build it before a line of code is written.

1. Define the unit of work and what success means

Choose the thing you are paying for: one answered question, one processed document, one completed workflow. Then define a successful outcome — resolved without a human, extracted without correction, approved without rework. Every later number is expressed per unit, and the final figure is cost per successful unit, not cost per attempt.

2. Estimate volume as a range

Users, multiplied by tasks per user per day, multiplied by working days. Produce a low, expected and high case. New AI features are often used more than planned once people find them useful, so the high case deserves real weight.

3. Count every token per task

Input is more than the user's message. It includes the system instructions sent every time, any documents retrieved to ground the answer, and the conversation so far, which grows with each turn. Output includes any hidden reasoning the model is billed for. Then multiply by the number of model calls per task: a simple assistant makes one, an agent may make ten or more.

4. Price the model mix, not a model

Most well-designed features use more than one class of model: a smaller, cheaper model for routine requests and a more capable one for hard cases. Estimate the share of work each handles, and the share answered from a cache at almost no cost.

5. Add operating overhead

Retries, timeouts, answers regenerated after a failed check, and testing in production typically add a meaningful margin. Without data of your own, 10–20% is a sensible starting allowance.

6. Add the platform around the model

Search indexes and vector databases, hosting, logging, monitoring, security filters and evaluation tooling all carry monthly costs that do not appear on a model provider's invoice.

7. Price the humans

Every AI feature has a boundary where people take over: escalations, reviews, corrections, complaints. Multiply the expected escalation rate by the cost of handling one. This is the line Klarna's early estimate underweighted, and it is often the largest.

How AxON approaches this

This seven-line method is how we estimate running cost on AxON, our AI delivery platform, before a client signs. The design choices that reduce lines 3 to 5 — routing each task to the smallest model that handles it well, limiting retrieved context, caching repeated answers, capping agent steps — are built into how we deliver. AxON is model-agnostic, so the estimate compares model classes across providers rather than assuming one. And because line 7 usually dominates, we design escalation paths and quality checks as carefully as prompts. The client receives the estimate in writing, with every assumption shown, as a range rather than a single hopeful number.

A worked example

Take a customer-query assistant for a B2B manufacturer, answering questions about products, orders and documentation. The figures are illustrative, chosen to show how the lines interact. Model prices are round numbers for a small and a frontier model class, not any provider's price list.

Two things stand out. First, the design choices matter: the same volume sent entirely to a frontier model, with no cache, no routing and larger context, would cost about $1,700 a month in model fees instead of $240. That is worth doing.

Second, and more important, the model bill is under 3% of the total. The human line is over 90%. Every percentage point of escalation moves the monthly cost by $1,200 — almost as much as the entire saving from optimising the model. At a 5% escalation rate the human line falls to $6,000; at 12% it rises to $14,400.

What the example teaches

The biggest lever on AI running cost is often not the model at all. It is answer quality, because quality determines how many conversations come back to people. That is why the cheapest model is not automatically the cheapest system. A model that costs more per token but resolves more questions correctly can lower the total bill.

The human line can be designed down, too, without pretending people are unnecessary. A clean hand-off that passes the full conversation and the documents already checked lets an agent resolve an escalation in minutes rather than starting again. Clear boundaries — which topics the assistant should never attempt, such as disputes, complaints or anything with legal consequences — stop it from producing confident wrong answers that generate a second, more expensive contact. And grounding answers in your own approved documents, rather than the model's general knowledge, raises the share of questions resolved correctly the first time. Each of these lowers the largest line in the estimate.

It also changes what you should measure after launch. Cost per token and total spend are useful, but the numbers that tell you whether the estimate holds are cost per successful outcome, escalation rate and repeat-contact rate. Klarna's own later reporting leaned on exactly these kinds of quality measures.

Estimating without bias toward any provider

A useful estimate works across the whole market, not one provider's price list. The choice is genuinely global: closed models from OpenAI, Anthropic, Google and xAI; European options such as Mistral; open-weight families including Meta's Llama, DeepSeek and Alibaba's Qwen; and regional models such as Falcon from the UAE and Jais for Arabic. Four practical points apply across all of them.

1. Estimate by model class, then price the specific models. Prices change several times a year; the structure of the estimate should not.
2. Token counts are not universal. Each provider splits text into tokens differently, so the same document can produce different counts — and some languages, including Arabic, can use noticeably more tokens on models built mainly for English. Measure with your real content on the models you are considering.
3. Hosting location affects cost. Keeping data inside the EU or the Gulf may require specific regions, providers or self-hosting, each with its own price.
4. Self-hosting moves cost, it doesn't remove it. An open-weight model on your own infrastructure has no per-token fee, but hardware, operations and idle capacity replace it.

The one-page estimate to ask for

If a vendor is building AI into your software, ask for the estimate in this shape before you sign: the unit of work and definition of success, volume as a range, tokens per task with the number of calls, the model mix with cache assumptions, overheads, platform costs, the human line, and cost per successful outcome in low, expected and high cases. Ask what happens if usage doubles, and which line the design is most sensitive to. A vendor who can fill in every line has designed the feature. A vendor who can fill in only the first three has priced the tokens.

The bottom line

Estimating the running cost of an AI feature is not hard, but it is easy to do partially. The token formula is the start, not the answer. A complete estimate defines success, uses ranges, counts every token and every call, prices the model mix, adds overhead and platform costs, and — most importantly — prices the people who handle what the AI cannot.

CTA: If you are planning an AI feature and want the seven lines filled in before you commit, we will map one use case and give you the estimate in writing, with every assumption visible.

Frequently asked questions

How do I estimate LLM costs?

Multiply tokens per task by model prices across your model mix, multiply by volume, then add overhead, platform costs and the cost of human escalations. Express the result as cost per successful outcome, in a range.

What is usually the largest cost in an AI feature?

Often not the model. In customer-facing features, the cost of people handling escalations and corrections can be many times the model bill.

Does choosing the cheapest model minimise cost?

Not necessarily. A cheaper model that resolves fewer requests correctly can increase total cost through escalations and repeat contacts.