> ## Content Index
> Fetch the complete content index at: https://insights.cloudacio.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why AI cost forecasts miss, and what to measure instead
- URL: https://insights.cloudacio.com/ai-cost-forecast-coverage-attribution/
- Published: 2026-10-29T14:30:24.000Z
- Updated: 2026-11-09T15:53:16.000Z
- Description: 98% of enterprises track AI cost and 11% can forecast it within 10%. The coverage data in the same survey says that is an instrumentation gap, not a modelling one, and a tighter forecast is the wrong thing to want.
- Author: Juan Pablo Olivera
- Tags: AI, #author-juan-pablo-olivera

The finance team asks what AI will cost next quarter. You give them a number.

The quarter ends, the real number arrives, and it is nowhere near the one you gave them.

Nobody was careless. The dashboards were green the whole time.

That gap is almost universal, and it is not a math problem.

By the end of this piece you will know why AI forecasts miss and what to measure instead.

Start with the paradox. In Mavvrik and Benchmarkit's [2026 State of AI Cost Governance](https://www.mavvrik.ai/press-releases/ai-bill-shock-hits-the-boardroom/?ref=insights.cloudacio.com), a survey of 396 enterprises, [98% track AI infrastructure costs](https://www.mavvrik.ai/blog/blog-ai-cost-governance-report-2026/?ref=insights.cloudacio.com). Only 11% can forecast that spend within 10% of what they end up paying. Nearly everyone is watching, and almost nobody can see ahead. That figure went down since the last survey, not up.

![Donut chart of how far 396 enterprises miss their AI cost forecasts: within 10% 11%, off by 11 to 25% 39%, off by 26 to 50% 35%, off by more than 50% 13%, no forecast at all 2%. Source: Mavvrik and Benchmarkit, 2026 State of AI Cost Governance.](https://storage.ghost.io/c/62/8f/628feacd-48cf-4de5-85ac-9760eb6467c8/content/images/2026/10/forecast-accuracy-2.svg)

The middle is where most companies live: 74% miss by somewhere between 11% and 50%. Only 2% produce no AI forecast at all, which is the point. Almost everyone is forecasting, and the forecast is wrong.

The obvious reading is that AI is just hard to predict. I think that is wrong, and the same report shows why. Look at where the cost reporting stops.

## Your reporting stops where the invoices stop

The survey asked which parts of your AI setup actually show up in your cost reports. The answers fall into a neat pattern. If a provider mails you a bill for it, you can see it. If no bill exists, you mostly cannot.

![Bar chart of the share of 396 enterprises including each environment in AI cost reporting: public cloud 67%, hosted models and LLM APIs 53%, data platforms 52%, on-prem and private data centre 44%, AI coding tools 42%, agentic workflows 36%, GPU infrastructure 36%. Source: Mavvrik and Benchmarkit, 2026 State of AI Cost Governance.](https://storage.ghost.io/c/62/8f/628feacd-48cf-4de5-85ac-9760eb6467c8/content/images/2026/10/coverage-cliff-2.svg)

The survey's own version of this chart draws a line between on-prem and AI coding tools, labelled "native billing ends here". Above the line a provider sends you a bill. Below it, nobody does.

That slope tells the story. Habits built around reconciling cloud invoices work exactly as far as the invoices reach.

In the cloud era, visibility came free with the service. You laid out your resources, the provider itemised them, a tool added up the rows. The meter was installed for you. With AI the meter stops at the edge of the provider's API, and the expensive behaviour happens past that edge. You install your own or you get nothing.

Agents are the clearest case. By an agent I mean software that takes a goal and decides for itself which tools to call and how many times. Nearly all of these organisations run them. Just 36% include them in cost reporting, the lowest of any category on that chart. The fastest-growing thing in the budget is the least likely to be in the ledger, and you cannot forecast what you never collected.

## What the bill cannot tell you

Databricks published the best public example of this, and it is about themselves. In September 2026 they wrote up [how they eliminated about $1 million a year of wasted AI agent spend in roughly an hour](https://www.databricks.com/blog/how-we-eliminated-1-million-year-wasted-ai-agent-spend-one-hour?ref=insights.cloudacio.com). The waste came from seven bugs in the connectors their internal agents used to reach other tools. Most of that million was engineering time lost waiting on stuck agents; the rest was tokens burned on retries. Read it as a rough estimate scaled up from a single day of data, not an audited figure.

The mechanism is the part that generalises.

Their agent fleet was throwing well over a thousand errors a day. One broken call to Jira, failing with an unhelpful `KeyError`, accounted for a quarter of the annual waste by itself. The agents never crashed. They retried, guessed, found workarounds, and billed for every attempt.

Their own description of what the dashboard showed is the line I keep coming back to: "an aggregate cost dashboard may show a 10% bump in token spend that can be easily misinterpreted as usage growth." The cost was visible all along. The cause was not. They found it by reading [OpenTelemetry traces in a unified trace table](https://docs.databricks.com/aws/en/ai-gateway/unified-trace-table?ref=insights.cloudacio.com) rather than by staring at a total. OpenTelemetry is an open standard for recording what software actually did, step by step, more like a flight recorder than a receipt.

The detail that surprised me most is that the quality of your error messages is a cost variable. When an error explained itself, the agents recovered quickly and rarely hit it again. When it was cryptic, recovery took roughly three times as many turns. When it was actively misleading, they hit it again about half the time. Bad error text has stopped being just a developer annoyance and become a line on the invoice.

Long conversations also cost more even when nothing is broken. Snowflake spells this out in its [Cortex Analyst docs](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst?ref=insights.cloudacio.com), noting that the models "do not store state between requests. The full history is processed for each new query in a conversation, with corresponding compute cost that increases with each round." Turn twenty pays for turns one through nineteen again.

And now the misdirection. When the survey asked where the unexpected AI costs actually came from, the top answer was not the models but data platform usage overages, ahead of LLM token costs.

That ordering makes sense once you follow one agent request. It searches your data, fanning out across tables; something fails; it retries; all that data work runs again. The model call was cheap. The warehouse behind it was not. Instrument your tokens beautifully, ignore your query volume, and you have measured the second-biggest surprise.

## You know who spent it, not why it moved

Attribution exists, but it is aimed at the org chart.

![Column chart of attribution dimensions used by 396 enterprises, multi-select: team or department 54%, product or feature 53%, agent or workflow 46%, model or provider 43%, customer 40%, developer tool user 29%. Source: Mavvrik and Benchmarkit, 2026 State of AI Cost Governance.](https://storage.ghost.io/c/62/8f/628feacd-48cf-4de5-85ac-9760eb6467c8/content/images/2026/10/attribution-dimensions-2.svg)

A gradual 25-point slope rather than a cliff. Team and department lead; the dimension that would explain a coding-tool bill, the individual developer, sits last.

In practice, a team can name the cost centre that owns a line item and still have no idea which model choice or retry loop produced it.

For billing a department, that is fine. For forecasting it is useless, since the org chart is not what changed when the cost moved. Nobody reorganised. Something smaller and quieter happened... a router started choosing a bigger model, a retry loop started firing, more people started using the thing.

Before anyone on a team builds a forecast, we split AI spend three ways, since each part grows for its own reason and breaks a forecast in its own way.

| Where the AI runs             | Grows with            | What goes wrong                        | Tag the cost by            |
| ----------------------------- | --------------------- | -------------------------------------- | -------------------------- |
| Inside your product           | Your customers        | Margins shrink until you reprice       | Customer and feature       |
| In your team's daily tools    | Your headcount        | Tool spend nobody can tie to results   | Tool and person            |
| Agents doing tasks end to end | How hard each task is | Retries and coordination steps pile up | Agent, run, step and model |

  
Agents are the row that bites, since they scale with how hard the task is and nobody can cap that. Add all three into one number and you get a figure that is accurate in total and dangerous to act on.

The first row is where this stops being an engineering concern. Most of the survey's respondents say AI costs are already denting their gross margins, and a large majority have never tracked AI as a cost of goods sold. That means the cost never gets counted against the revenue of the product that caused it. So AI compute sits in the research budget, nobody knows what a feature costs to serve, and the price gets set anyway. Roughly half have since repriced an AI product, usually in full view of their customers.

## Stop trying to be the 11%

This is where I would argue with the report. Hitting your forecast within 10% is the wrong goal.

AI spend rides on things that change at runtime: which model the router picks, how often work retries, how long conversations get, how many people use it. Promising precision on a line like that is either luck or sandbagging.

The FinOps Foundation is a standards body rather than a vendor, and it refuses to set the bar this metric assumes. Its [Forecasting capability page](https://www.finops.org/framework/capabilities/forecasting/?ref=insights.cloudacio.com) leaves acceptable variance for each organisation to define, and opens with Paul Saffo: "the goal of forecasting is not to predict the future but to tell you what you need to know to take meaningful action in the present."

I would take that trade every time. A team that misses badly but can break the miss into model mix, retry volume and adoption growth beats a team that lands on the nose and cannot say how.

There is also a reading of the drop that is not decline at all. Coverage expanded into agents and GPUs, and AI moved out of pilots into production. Teams that just started measuring a wider, wilder surface should post worse numbers for a while. That is my interpretation rather than the report's, but two surveys hand it the same tell, which is that the most AI-mature companies forecast worst.

The survey found that AI-native companies had the worst forecasting of any segment, despite more than half calling themselves "advanced". CloudZero's [ROI in the AI Era](https://www.cloudzero.com/guide/roi-in-the-ai-era-2026-survey-report/?ref=insights.cloudacio.com) found the same shape in a separate survey, where the firms with the best live monitoring also had the worst catastrophic misses. Their conclusion is blunt. These companies "have invested the most in visibility infrastructure and still can't forecast reliably. They aren't struggling with tooling or best practices; rather, it's a volatility problem."

A skills-gap story cannot survive that finding. An exposure story predicts it.

One caveat before you quote any of this. Every forecast-accuracy figure here comes from a company that sells AI cost tooling, and those two surveys share a research partner. That is itself a decent reason to be sceptical of "buy a dashboard" as the cure.

## Four moves, in this order

These build on each other. Do coverage first, or everything after it computes on missing data.

**1) Extend coverage past the billing API.** Hosted model APIs, data platforms, agent runtimes, AI coding tools, your own GPUs. On AWS, [Bedrock application inference profiles](https://docs.aws.amazon.com/bedrock/latest/userguide/application-inference-profile.html?ref=insights.cloudacio.com) let you tag model calls by application and customer.

**2) Attribute on what explains the change, not who owns the budget.** Record one row per model call rather than per session, tagged with the model, the agent, the step and your own customer and feature labels. Then roll it up to cost per finished task.

**3) Alert on drivers rather than dollars.** Plenty of teams still find out when the invoice lands, and by then the money is gone. Set your alarms on retry counts, spend per session, conversation length, routing changes and idle GPU time. Those move first; the dollar total moves last.

**4) Publish the decomposition along with the number.** Explain the miss in drivers. Report cost per task as a median plus the P90, the figure 90% of tasks come in under, since the expensive tail is the signal and an average hides it. Reconcile your own ledger against the provider's invoice monthly.

Be honest with yourself about how much of this you will be building. The [OpenTelemetry GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai?ref=insights.cloudacio.com) give you an agreed vocabulary for recording model calls, tool calls and token counts, so your traces mean the same thing across tools. There are two catches though. The vocabulary is still marked as in development, so pin your version and expect renames. And it defines no cost fields at all. It carries the token counts and leaves the dollars to you.

## This week

Pull up your AI cost report and check it against that second chart. How many of those seven environments are actually in there?

Then take your last forecast miss and write one paragraph explaining it in drivers, meaning how much was model mix, how much retry volume, how much was simply more people using it. If you cannot write that paragraph, the forecast was never the broken part.

The question to carry into the next budget review is less how accurate your AI forecast was and more whether anyone in the room can explain the last miss.