When a client asks what an AI integration costs, they almost always mean the model. How much per question? Per document? Per user? It's a fair instinct — the model is the visible, new, slightly scary part. But after building these features for a living, we can tell you the token bill is rarely the line that decides your budget. It's usually the one you'll worry about least.

This piece breaks the cost into its real parts, puts current numbers on each, and shows the levers that move the total. If you sell software, it's the conversation to have with your client before you quote — not after the first invoice surprises them.

The line everyone quotes: model tokens

Language models bill per token — a chunk of text about three-quarters of a word. You pay separately for input (what you send) and output (what the model writes back), and output is the expensive side. As of mid-2026, the going rates per million tokens look like this:

  • Flagship tier — Claude Opus 4.8 at $5 in / $25 out, for the hardest reasoning.
  • Workhorse tier — Claude Sonnet 5 at $2 in / $10 out (introductory, rising to $3 / $15 in September 2026); OpenAI's GPT-4o at $2.50 / $10. This is where most production traffic should live.
  • Cheap tier — Claude Haiku 4.5 at $1 / $5, GPT-4o mini at $0.15 / $0.60, Mistral Large 3 around $0.50 / $1.50. For routing, extraction and high-volume simple work.

Put that in human terms. Anthropic's own worked example runs 10,000 customer-support conversations through Haiku for about $37 — roughly a third of a cent each. A mid-tier model answering a few thousand questions a day lands in the tens to low hundreds of euros a month. For a typical business copilot, the model is not what breaks the budget.

And this line only trends down. Every generation has cut the price of a given capability: work that needed the flagship last year runs on the workhorse tier this year at a fraction of the cost. Betting your business case on tokens getting cheaper is one of the safer bets in this field.

The model is the cheapest, most predictable line in the whole project. The cost lives in everything you build around it.

The five things that actually drive the bill up

1. Getting your data to the model

A model on its own knows nothing about your client's business. The moment the feature needs to answer from their documents, tickets or database, you're building RAG: ingestion pipelines, chunking, a vector store, retrieval, reranking and an evaluation loop to prove it fetches the right thing. This is real backend engineering, and it's usually the biggest single slice of the build. The model is an afternoon; the plumbing that feeds it good context is weeks.

2. Evaluation — the invisible line

The demo works on the first five questions. Question six is confidently wrong, and now you need to know how often that happens before your client's customers find out. Evaluation — a test set of real questions with known-good answers, scored on every change — is what separates a weekend prototype from something you can put your name on. It rarely appears on the first quote and it's non-negotiable. Skipping it doesn't remove the cost; it just moves it to production, where it's paid in support tickets and lost trust.

3. Retries, loops and context bloat

Here's where the token bill quietly grows after launch. Three culprits, in order of how often we see them:

  • Context bloat — every prompt drags along more chat history and more retrieved documents. Input tokens climb, and you're paying to re-send the same context on every turn.
  • Agent loops — an "agentic" feature that plans, calls tools and checks its own work can fire the model five or ten times per user action. Each hop is billed.
  • Retries — a weak model or a shaky prompt fails, so you retry, or a human redoes the work. You pay twice and lose the time.

The fix is architecture, not a bigger budget. Prompt caching reads repeated context — a long system prompt, a fixed policy document — at about 10% of the input price. Batch processing runs non-urgent jobs at roughly half price. On the right workloads these two levers cut token spend by more than half. Most teams leave them switched off.

4. Guardrails, compliance and a human in the loop

Anything customer-facing needs guardrails: input validation, output checks, a way to catch the model saying something wrong or unsafe, and — where the stakes warrant it — a person reviewing before the answer ships. If the feature touches personal data you also carry the GDPR work: lawful basis, PII handling, logging, and disclosure that users are talking to AI. None of this is model cost. All of it is project cost, and it's the part that keeps a launch from being pulled the week before go-live.

5. Maintenance and model churn

An AI feature is a living system. Models get deprecated on a schedule — the one you built on this year will be retired, and the swap needs re-testing against your evaluation set. Prompts drift as the client's data and tone change. Retrieval quality decays as documents pile up. Budgeting an AI integration as a one-off deliverable is the single most common costing mistake we see. It has an owner and a run-rate, like any other production system.

A rough shape of the total

We won't quote a universal figure — anyone who does is guessing. But the shape is consistent. On a typical mid-sized copilot or automation, the model tokens are a minority of month-one cost and a small fraction of the build. The engineering around the model — retrieval, evaluation, guardrails, integration into the client's existing systems — is the bulk of it. And the run-rate after launch is dominated by maintenance and human oversight, not by the API meter.

Which is good news for how you scope the work. The expensive parts are the parts you control: they respond to good architecture, honest evaluation and a clear owner. The token bill mostly takes care of itself, and gets cheaper on its own.

How we keep the total down

  1. Right-size the model per task. A cheap model for routing and extraction, the workhorse tier for most answers, the flagship only where the reasoning earns it. One size fits nothing.
  2. Turn on caching and batching. Free money on repeated context and non-urgent jobs. We wire these in by default, not as an afterthought.
  3. Measure tokens per request from day one. Log input and output tokens per call so context bloat and runaway loops show up on a graph, not on an invoice.
  4. Build the evaluation set before the feature. It sets the quality bar, catches regressions on every model swap, and lets you drop to a cheaper model with evidence instead of hope.
  5. Quote the run-rate, not just the build. Name the ongoing cost — maintenance, model migrations, oversight — in the first conversation. Clients budget for what you tell them about.

FAQ

Is the model API bill really the small part?

For most business copilots, yes. At 2026 prices a well-built support assistant runs in the tens to low hundreds of euros a month in tokens. The build — retrieval, evaluation, guardrails, integration — is where the real money goes, and unlike tokens it doesn't scale down when traffic is quiet.

Why does my token bill keep creeping up after launch?

Usually three causes: context bloat (more history and documents in every prompt), retries and agent loops that call the model several times per action, and a model upgrade to a pricier tier. Log tokens per request from day one so you can see which one it is.

Should we just use the cheapest model to save money?

Not blindly. A cheap model that gets answers wrong costs you in retries, human corrections and lost trust — all of which dwarf the token saving. Match the model to the task: small for routing and extraction, mid-tier for most answers, flagship only where the reasoning genuinely needs it.

What's the one cost people forget to budget for?

Maintenance. Models get deprecated, prompts drift, the client's data changes, and the evaluation suite needs re-running. Budget for ongoing ownership from the start — an AI feature is a living system, not a fixed deliverable you ship once.

How much do caching and batching actually save?

Prompt caching reads repeated context at about 10% of the input price; batch processing runs non-urgent jobs at roughly half price. On workloads with a lot of fixed context or asynchronous work, the two together routinely cut token spend by more than half.

Sources: Anthropic, Claude API pricing & the 10,000-ticket worked example · OpenAI, API pricing (GPT-4o / GPT-4o mini) · Mistral AI, model pricing. Prices verified July 2026 and change often — check the source before you quote.

Scoping an AI feature and want the number to hold up? Plan a call — we'll cost it with you, white-label, before you send the quote.