Every finance team that has tried to get AI spending under control has run into the same instinct: treat it like a utility bill. Count the tokens, multiply by the rate, allocate the cost to each team, and report the total. It works for electricity. It should work for AI.
It doesn't. And the reason it doesn't is not a tooling problem. It is a measurement problem that no invoice will solve.
What electricity measurement actually tells you
When you measure electricity consumption, the unit you are tracking — the kilowatt-hour — is directly proportional to the work performed. More machines running, more power consumed, more work done. The relationship between input and output is close enough to linear that consumption is a reliable proxy for productivity.
AI token consumption does not work this way. A workflow that consumed 400,000 tokens last week and 800,000 tokens this week did not do twice the work. It may have done the same work less efficiently, or it may have done more work at the same efficiency, or it may have been stuck in a retry loop that produced nothing useful at all. The token count alone cannot tell you which.
This matters because the entire utility-bill model of AI cost management is built on an assumption — that more consumption means more value — that is false in AI workloads. A model stuck retrying a failed tool call consumes tokens at the same rate as a model completing tasks successfully. The invoice looks identical.
The metric that actually matters
The signal that correlates with value is not token volume. It is tokens per completed outcome — how many tokens did it take to finish one unit of work.
A workflow that completes a task in 1,200 tokens is performing well. The same workflow completing the same task in 4,800 tokens is not. If that ratio is rising week over week, something is degrading: the model is retrying more often, the context is being filled with irrelevant history, the prompts are getting less efficient, or the integration is breaking silently. None of this is visible in a utility-style cost report. All of it is visible in a tokens-per-outcome trend.
The second signal that disappears in utility measurement is retry amplification. In a healthy AI workflow, the ratio of model calls to completed tasks runs close to 1.0. When that ratio climbs above 2.0 or 3.0, the workflow is looping — calling the model repeatedly without advancing toward completion. This is the AI equivalent of a process hanging. Standard cost reports do not surface it because every retry call is just another line item at the same per-token rate.
Why teams default to the electricity model anyway
The utility model is appealing precisely because it is simple and it does something. Engineering teams feel the pressure from finance to explain the AI bill. Finance wants a number they can allocate and trend over time. Token counts give them that number quickly. The fact that the number is not measuring what matters gets discovered later — usually after a costly production incident, or after months of rising spend with no clear explanation.
The deeper issue is that AI cost tools were largely designed to solve the invoice problem, not the performance problem. They can tell you which team spent the most. They cannot tell you which team is getting the most value per dollar, which workflows are degrading, or which prompts have stopped working efficiently.
What the right model looks like
Measuring AI well requires treating each session not as a billing unit but as a performance event. The data available in an AI session — tokens in, tokens out, call count, completion status, retry frequency, context utilization — contains everything you need to diagnose whether a workflow is healthy or degrading.
When you aggregate those sessions at the workflow level, you can track efficiency trends over time: is this workflow taking more or fewer tokens per outcome than it did last month? When you aggregate at the team level, you can see which teams are improving and which are plateauing. When you aggregate across the organization, you get a measure of whether AI is becoming more efficient as the org learns to use it — or whether it is staying flat while the bill grows.
None of this requires abandoning cost visibility. It requires adding outcome context to cost data. The same token counts that generate the invoice can generate a tokens-per-outcome ratio if you know what the workflow was trying to accomplish when it consumed them.
The organizational consequence of measuring wrong
Organizations that measure AI like electricity make one consistent mistake: they optimize for the number they can see. They reduce token consumption without knowing whether they are reducing waste or reducing value. They cap spending without knowing whether the cap is hitting low-efficiency workflows or high-efficiency ones. They report AI ROI as cost-per-token without being able to answer whether the cost is going toward outcomes or toward retry loops.
The more consequential problem is that utility-style measurement accumulates no organizational learning. An electricity bill from last year tells you how much power you used. An AI session log from last year — if you captured the right signals — tells you which workflows were efficient, what the tokens-per-outcome baseline was, and how it compared to this year. That history is how organizations improve at AI over time rather than simply spending more on it.
The teams that will compound their AI advantage over the next several years are not the ones with the lowest token rates. They are the ones building a system of record around how AI actually performs — and using that record to close the gap between their best workflows and their median ones.
Electricity measurement will not build that. Outcome measurement will.