Where the AI money actually goes
Most companies can name their AI providers and not much else. Here is what an AI bill is actually made of, and which parts of it are producing nothing.
July 22, 2026 · The Camaze team
Ask a finance team what the company spends on AI and you will usually get a number. Ask what it is made of and the conversation stops.
That is not a criticism of finance. The information genuinely is not available anywhere. Provider invoices report by API key. Cloud bills report by service. Per-seat tools report by seat. None of those map to anything a business recognizes, and nobody built the layer that translates between them.
So here is what an AI bill is actually made of, in the order the money tends to sit.
Production workloads that serve customers
This is the part everyone assumes is most of the bill, and it usually is. It is also the part that is easiest to defend, because it maps to something the business sells.
What surprises people is the concentration. Once spend is split by workflow rather than by API key, it is common to find that two workloads account for the majority of everything. Not ten. Two. There is a long tail of small workflows, and the tail is almost never where the problem is.
This matters because it changes what a cost conversation looks like. A general anxiety about AI spend is unresolvable. Two named workflows with owners are a Tuesday meeting.
Production workloads that serve nobody
The second category is production spend behind features that no longer exist, or that never got traction.
Something ships. It works. Nobody revisits it. Eighteen months later the feature has been quietly removed from the product, and the workflow behind it is still running, still calling a model, still being billed. Nobody switched it off because nobody knew it was on.
The same pattern applies to dedicated infrastructure. An endpoint provisioned for a launch, sized for the traffic that launch was expected to bring, still running at low single-digit utilization a year later. The compute bill does not care that it is idle.
Evals, tests and prototypes
Non-production spend is consistently larger than anyone expects, and it is almost always invisible, because nothing separates it from production in the bill.
Three things drive it. Eval suites that were set to run nightly during a period of active development and never unscheduled. Load tests against a real model endpoint rather than a stub. And prototypes, which are the purest form of this: someone builds something, it does not go anywhere, the API key stays active.
None of that is avoidable in principle. Evaluation is how you avoid shipping something bad. The opportunity is an eval suite running nightly against a workflow that has not changed in six months.
Retries and loops
This is the fastest growing category, and it is specific to agentic systems.
An agent turns one user action into a chain: plan, call a tool, evaluate the result, retry, call another tool, retry again, summarize. Every step is a model call. Every retry is a model call that produced nothing.
The reason this is dangerous rather than merely expensive is that retries do not look like failures. A retry that succeeds on the fourth attempt is a success in every log the system produces. There is no error, no alert, no user complaint. The only place it appears is the bill, three weeks later.
It is normal to find agentic workflows spending a third of their budget on discarded attempts, and it is not unusual to find one spending considerably more than that.
The wrong model doing simple work
The largest single finding in most companies, and the easiest to explain.
Systems get built against the strongest available model, because that is what was used during development and there was never a reason to change it. Then the system goes to production and runs for a year, and a large share of what it does turns out to be simple.
A classifier returning one of five labels. A router deciding which of three paths a request takes. An extraction step pulling a date out of a document. These are not tasks that need a frontier model, and the difference in price between a frontier model and a small one is not marginal.
The pattern is easy to spot once you look: a workflow where most calls return a short output from a small set of possible outputs is doing classification, whatever model is behind it.
Context that changes no output
Prompts accumulate. A retrieval step is widened from five chunks to fourteen to fix one bad answer, and never narrowed. A system prompt grows through six iterations, keeping instructions that a newer model no longer needs.
Every extra token is paid for on every single call. Across millions of calls that is a large number attached to no change in output quality, and it is measurable: run the workflow at both settings against the same evaluation set and compare.
Pricing mechanics nobody switched on
Providers price cached input and asynchronous batch work well below standard rates. Both are configuration rather than engineering.
Most eligible workloads use neither, usually because they were built before the option existed and nobody went back. A workflow where most input tokens are an unchanged system prompt is paying full price to send the same text thousands of times a day. A nightly enrichment job with no latency requirement is paying synchronous rates for work that could run in a batch window.
Seats
Per-seat AI tools are bought in blocks and assigned generously, because provisioning is easy and reclaiming is nobody's job. Then usage settles, and a meaningful share of seats go quiet.
Separately, and more awkwardly, two teams often end up on two tools that do substantially the same thing. Nobody made a bad decision. Each team chose well for itself. The aggregate is duplication that only becomes visible when somebody adds it up.
Discounts already earned
The last category is not an inefficiency in the technical sense. It is money left on the table.
Providers offer committed-use pricing and volume tiers, and none of them apply automatically. It is entirely normal to find a company paying list price for twelve months on a volume that qualified for a discount in month three, because nobody was tracking the threshold and the provider had no particular reason to mention it.
What to do with this
The point of the list is not that every company has all nine. It is that when you cannot see the composition of a bill, you cannot act on any of them, and the only lever available is to cap the total. That lever is indiscriminate. It cuts the two production workflows that are working alongside the eval suite nobody has looked at since March.
Getting to the composition is not difficult. Every one of these categories is derivable from usage and billing data that already exists. What is missing is the layer that puts it in one place and attributes it to something a business recognizes.
Start with the split between production and non-production. It is the fastest to produce and it is usually the first genuine surprise.
Then look at your two largest workflows and ask what share of their calls return short outputs from a small set. That is where the largest single finding almost always is.