The build quote is the small number. Your AI’s running cost scales with its success.
You have two quotes on your desk for the same piece of AI. One says £40,000. The other says £65,000. You have spent a week working out which number to believe.
Neither quote mentions the number that will matter more in a year's time. Neither was asked to.
The assumption that used to be true
For thirty years software has had one cost shape. You pay to build it, and then it runs for almost nothing. A macro that saves an hour a day costs the same whether it runs ten times or ten thousand. Once the thing exists, one more use rounds to zero. Every software budget you have ever approved was built on that shape.
A system built on a large language model does not have that shape.
Every time it runs, it pays. Every document it reads, every reply it drafts, every decision it reasons its way through is a metered call to a model somebody else hosts. The unit price is small. It is also multiplied by every use, for as long as the system exists, and it gets bigger the more useful the system turns out to be.
Why does an AI system cost more to run than to build?
Because the build is a one-off and the running cost is per use. Gartner's June 2026 guidance on generative AI costs expects inference, the cost of actually running the model, to account for at least 70% of a model's lifetime cost, and predicts that at least half of generative AI initiatives will exceed their planned budgets by 2028. The same research says organisations moving from pilot to production "experience a rude awakening", because a production-ready system "can be orders of magnitude more expensive than running a pilot".
That is not a new warning. At Gartner's own symposium in October 2024 the line was that organisations which do not understand how their AI costs scale can be wrong by 500% to 1,000%, and that cost is as big a risk to an AI strategy as security. Three months earlier the firm had predicted that 30% of generative AI projects would be abandoned after proof of concept, with escalating costs named alongside poor data and unclear value.
Being wrong by a factor of ten is not a rounding error. It is the difference between a system you keep and one you switch off.
Tokens are getting cheaper. Your bill is not.
You will be told, correctly, that model prices are falling. Andreessen Horowitz worked it out in late 2024: for a model of equivalent capability, the price per million tokens had fallen from $60 in 2021 to $0.06, a thousandfold in three years, roughly ten times cheaper every year.
Two things stop that helping you.
Nobody stays on the equivalent model. The model that now costs six cents is the one nobody wants. The system you are being quoted for will use the current best model at the current top-of-range price, and when a better one arrives your supplier will move to it, because the output is better. Gartner's August 2026 prediction puts numbers on this: token prices fall 95% by 2030, and the inference cost per agentic workflow rises more than fivefold through 2028 anyway.
Product leaders cannot rely on more efficient token economics to rationalise AI costs. Each successive generation of AI capability will necessitate more, and often more expensive, tokens.
Usage grows faster than prices fall. CloudZero's survey of 500 engineering leaders in May 2025 found average AI budgets rising 36% in a year, the share of companies planning to spend over $100,000 a month more than doubling from 20% to 45%, and only 51% able to say with confidence whether any of it was paying back.
The surprise then reaches the board. Mavvrik's 2026 survey of 396 enterprises found nearly half had escalated an unexpected AI cost to board level in the past year, a third had imposed an emergency spending freeze, and a quarter had delayed or cancelled an AI initiative because of it. The FinOps Foundation's 2026 survey reports that 98% of respondents now actively manage AI spend, up from 31% two years earlier. That is not a discipline maturing. It is a discipline being invented in a hurry because the bills arrived.
The cost that scales with success
Here is the uncomfortable version.
A traditional system adopted twice as widely as planned is twice as good a deal. An AI system adopted twice as widely as planned costs twice as much to run. The thing you are hoping for is the thing that breaks the budget, and nobody bidding for the build has any reason to point that out.
Three ways it happens, from our own work.
The scope quietly grows. We built support triage for a technology firm: classify every inbound email, filter the spam, draft a reply. The running cost was scoped on one inbox at one model tier. Both of those are things somebody can change after go-live without raising a change request. Add the sales inbox, move the model up a tier because the drafts read better, and the monthly bill has multiplied while the system is, by every measure anyone is looking at, a success.
The inputs are not the sample. We built a pipeline that turns bank statements into structured data. The cost per statement depends on its length. A sample of a dozen tidy statements tells you nothing about the client who uploads a year of them as one 400-page PDF. The cost of that single upload goes from pence to pounds, and the person uploading it has no idea.
Agents multiply everything. A classifier makes one call per item. An agent that reasons, calls a tool, checks its work and reasons again makes many, and it can loop. Gartner's fivefold figure above is per workflow. If the pilot ran on a single-step design and the production system is agentic, you are not comparing like with like.
We have written before about why pilots fail at the integration boundary. Cost is the other boundary the pilot never crosses. A pilot runs on a few hundred items and the bill is invisible. Production runs on the real volume, and the bill is the first thing the finance director notices.
What to ask before you sign
What does one run cost today, at list price? Per document, per email, per conversation. A supplier who cannot answer has not measured it, and a supplier who has not measured it cannot have budgeted it.
What is that at my volume, per month, and at three times my volume? The second number is the one you pay if the system works.
Which model, and who decides when it changes? Every change of model is a change of price. If the contract does not say, the answer is "the supplier, whenever they like".
What stops it? A system with no spending cap has no budget, only a hope. Ask what happens at 2am when something upstream starts sending it the same document in a loop.
Is there a cheaper way to do most of this? Very often the routine 80% can be handled by a rule or a small, cheap model, with the expensive model kept for the hard cases. Most of what people want to automate does not need AI at all, and the part that does rarely needs the most expensive model for every step. That is a design decision made in week one, and it sets the running cost for the life of the system.
What this means for the two quotes
The gap between £40,000 and £65,000 is a one-off. The running cost is every month, and at any real volume it can exceed that gap within the first year. Which means the cheaper quote is not necessarily the cheaper system, and the more expensive one is not necessarily the more careful. The only way to tell is to make both of them put the second number in writing.
The supplier who volunteers the running cost, and shows you a design that keeps it down, is the one more likely to build something you can afford to keep switched on.
Our proof of concept is four weeks at a fixed £18,000, and one of the things it ends with is a production route: what it would cost to build, what it would cost to run at your volume, and where the risk sits. We have set out what a proof of concept should cost and include in detail. Occasionally the honest verdict is that the running cost kills the case before the build cost gets a look in. That is a cheap thing to learn in week four and a very expensive thing to learn in month fourteen.