What an AI Chatbot Actually Costs to Build and Run

An AI assistant costs less to run than most people expect, and more to build than most vendors admit. The model tokens, which is the part everyone asks about first, are usually the smallest line on the invoice.

Here's the actual breakdown. We've checked the model pricing against current published rates rather than quoting numbers we half-remember from a launch announcement.

What you're actually paying for

There are three separate costs and they scale differently:

• Build. A one-off, somewhere between €12,000 and €45,000 depending on how many systems the assistant has to reach and how strict you need it to be about accuracy.
• Model usage. Charged per conversation, and almost always smaller than people expect. Numbers below.
• Evaluation and maintenance. Ongoing, and the line most often missing from a quote entirely. It's what stops the assistant quietly going stale.

Model costs, or the part everyone overestimates

Frontier model pricing is published per million tokens, split between input (what you send) and output (what it writes back). Current Anthropic API rates give you a sense of the range:

• Claude Opus 5: $5 per million input tokens, $25 per million output
• Claude Sonnet 5: $3 per million input, $15 per million output
• Claude Haiku 4.5: $1 per million input, $5 per million output

A typical grounded support conversation pulls in a few passages of your documentation and runs for a handful of turns. That lands in the low thousands of input tokens and a few hundred output tokens, which at the mid tier works out to fractions of a cent. Ten thousand conversations a month usually means a two-figure or low three-figure bill, not the four-figure number people brace themselves for.

Two things change that arithmetic, and both are about how the thing is built rather than which model you pick.

How much context you send. Cost scales with what goes into the prompt, not with how clever the answer is. An assistant that stuffs forty retrieved documents into every request costs roughly ten times one that retrieves four good ones. Retrieval quality isn't only an accuracy question. It's a cost control.

Whether you cache. If a large, stable instruction block goes out with every single request, prompt caching charges roughly a tenth of the normal input rate for the repeated part. On a busy assistant with a big fixed preamble, that's the difference between a comfortable bill and an uncomfortable one.

You also don't need your most capable model for most support traffic. A cheaper, faster model handles well-documented questions perfectly well, and you can reserve the expensive one for the reasoning-heavy stuff. Routing by question type is a legitimate way to cut costs. Just do it after you have accuracy, not instead of getting there.

Build costs: what actually drives the range

That €12,000 to €45,000 spread isn't padding. Four things move a project across it.

How many systems it has to reach

An assistant that only answers from documentation costs a fraction of one that checks order status, looks up account state, or opens tickets. Every live system is its own integration, with authentication, error handling, and permission logic behind it. This is the single biggest driver of the number. If the assistant needs to reach systems that don't currently expose an API, have a look at how we approach integration work, because that's usually where the budget goes.

How strict the accuracy requirement is

A marketing-site assistant and a regulated-industry support assistant are different projects wearing the same label. The second one needs a proper evaluation set, tighter grounding, explicit refusal boundaries, and human review before anything reaches a customer. That work is real, and where being wrong has consequences, it isn't optional.

What state your content is in

This is the one that blindsides people. Retrieval-augmented generation retrieves what you actually have. If your documentation contradicts itself, or it's out of date, or it's scattered across five different tools, the assistant will faithfully surface every one of those contradictions. Cleaning up content is often a bigger job than building the assistant, and you want to find that out before the build rather than halfway through it.

Whether handover is real

An assistant that can't escalate properly is worse than no assistant at all. Real handover means the human picks up the full conversation and context, instead of a cold transfer where the customer has to explain themselves twice. That's integration work with your support desk, and it's where a lot of cheap chatbot projects quietly stop.

What deflection you can realistically expect

For well-documented, repetitive queries, 40 to 70% deflection is realistic. Anything promising 90% is either counting differently, usually by including conversations where the customer simply gave up, or it isn't being asked hard questions.

Two things decide where you land, and neither of them is the model. The first is how good your documentation already is, because the assistant can't answer what nobody has written down. The second is how much of your volume is genuinely repetitive. If most of your tickets are one-off account problems, deflection stays low no matter what you spend.

Measure it honestly, too. "Conversations that didn't reach a human" is the wrong metric, because it counts people giving up as a win. What you want is conversations resolved without a human where the customer didn't come back with the same question two days later. That number means something.

The cost nobody quotes: keeping it accurate

An assistant isn't a project that finishes. Your products change, your policies change, and the assistant carries on confidently answering from whatever it was given on day one. Without an evaluation set and somebody actually reading real conversations now and then, quality degrades silently and you hear about it from a customer.

So budget for it. In practice it's a fairly modest ongoing commitment: an evaluation suite built during the project, plus regular review of a sample of real conversations. Much cheaper than the alternative, which is finding out six months in that your assistant has been cheerfully explaining a returns policy you discontinued in spring.

When not to build one

We turn this work down in three situations, and it's usually obvious inside one conversation:

• Your documentation doesn't exist. Fix that first. It's valuable on its own, and you need it either way.
• Your volume is low. Below a few hundred repetitive queries a month, the build cost won't pay back against just answering them.
• Your questions are all unique. If every ticket needs account-specific judgment, what you need is better tooling for your support team, not an assistant sitting in front of them.

The EU compliance question

If you're serving EU customers, this isn't a future problem any more. Article 50 of the EU AI Act applies from 2 August 2026, and the European Commission's guidance is specific about it: systems that interact directly with people have to be designed so those people know they're talking to an AI, unless it's already obvious. The notice has to arrive at the start of the first interaction, clearly and distinctly, and in an accessible form.

None of that is hard to satisfy, but build it in from the start rather than retrofitting. A disclosure line in the opening message costs nothing at build time and is awkward to bolt on afterwards. Keep conversation logs and a working escalation path to a human as well. Both help with compliance, and both are things you want regardless.

On data: under enterprise terms with the major providers, your conversations aren't used to train models, and EU-region infrastructure is available for the knowledge base. If your requirements are stricter than that, open-weight models deployed in your own environment are a genuine option, though the engineering and hosting bill goes up meaningfully.

Want a real number for your case? The fastest route to a useful estimate is your twenty most repeated customer questions plus a rough monthly volume. That tells us what's deflectable, what it would cost to run, and occasionally that you shouldn't build one at all. See how we build AI assistants, or just send us the list.