Nobody knows what the AI costs.

Ask a company what it spent on model providers last quarter and you tend to get one of two answers. The first is a number from the finance system — accurate, and completely uninformative, because it is an invoice total and an invoice total cannot tell you who spent it or on what. The second is a pause, followed by someone offering to go and find out.

The second answer is more common than the industry likes to admit, and it is worth being clear that it is not a discipline problem. Nobody forgot to build the dashboard. The number genuinely does not exist, because of how the spend is structured.

Why the number does not exist

Model providers bill an account. Inside that account, a credential is a string — and a string has no team, no cost centre, no owner and no memory of where it has been copied.

So the ordinary lifecycle of a key runs like this. It is created once, for one experiment, by somebody who needed to try something on a Thursday. It works, so it is pasted into a second service. Then into a scheduled job. Then into a CI secret, a notebook, and a colleague's local environment. None of those are recorded anywhere, because copying a string is not an event that any system observes.

By the time anyone asks for a breakdown, four or five systems are transacting under one identity. The provider sees one caller. Finance sees one line. The engineering team sees a number they cannot decompose, and the honest answer to "which team does this belong to" is that the information required to answer it was never captured.

Three places the money actually goes

When teams do finally reconstruct a quarter, the surprises tend to cluster in the same three places.

Things nobody switched off. A proof of concept from March that still runs nightly. An evaluation harness that re-scores a fixed dataset on a schedule. A demo environment pointed at a production-grade model because that was what made the demo good. Individually small, permanently on, and invisible precisely because they never fail and therefore never page anyone.

Work you paid for and threw away. Retries after a timeout. Requests that returned something malformed and were re-issued. Calls whose answers arrived after the user had already navigated away. Providers bill for tokens generated, not for tokens used, and the gap between those two numbers is entirely invisible from the invoice.

Context that grows. This is the one that catches people out, because it is not linear. A conversational feature re-sends its history on every turn, so turn ten carries the first nine with it. Add retrieval and each turn also carries several chunks of document. The cost of a twenty-turn conversation is not twenty times the cost of one turn — it is substantially more, and the per-user number that looked fine in testing was measured on conversations three turns long.

Budgets are set per feature. Providers bill per token. Almost every forecasting failure in this category lives in the gap between those two units.

Why the forecast misses

Even teams that do estimate up front tend to be wrong in the same direction, for three reasons that are all structural rather than careless.

• Estimates are built on a token count per interaction that came from testing, where interactions are short, clean and made by people who know what the feature is for.
• Success is the risk. A feature nobody uses costs nothing. The scenario where spend triples is the scenario where the launch went well, which is not a scenario anyone is inclined to plan pessimistically for.
• Unit economics move underneath you. A model is deprecated, a default is changed, a team swaps to a larger model to fix a quality complaint — and the per-call cost changes without a single line of the budget being revisited.

What month-end discovery actually costs

The lag is worse than the number. Finding out on the fifth of the following month means several things are already true.

You cannot charge it back, because you cannot attribute it, which means it sits in a central budget and looks like an engineering overrun rather than the cost of four different product decisions. You cannot distinguish a runaway from healthy growth, because both look like a bigger number. And you cannot act on it, because whatever caused it ran to completion weeks ago — the conversation is a retrospective rather than a decision.

The same lag makes the next forecast worse. If the only granularity you have is a monthly total, the only projection you can make is a monthly total multiplied by optimism.

What tracking would actually require

Three things, none of which are a dashboard.

1. 1.Attribution captured when the call is made. Which system, on whose behalf, under which budget. This cannot be reconstructed afterwards, because the information that would answer it never left the machine that made the call.
2. 2.A unit between the request and the month. Most of what goes wrong happens over minutes — a run, a conversation, a job. A control scoped to one request cannot see it and a monthly total sees it four weeks late.
3. 3.A number with an owner. Attribution is only useful if somebody receives it. A per-team figure that arrives on the same cadence as every other cost line is a budget; a figure nobody is accountable for is trivia.

None of that is novel. It is the same problem cloud spend had fifteen years ago, and it was solved the same way: by making the resource carry an owner at the moment it is consumed, rather than asking an accountant to work backwards from a bill. Model providers are simply the newest place where a long-lived shared secret is still the default, and where the reckoning arrives monthly.