The price of a unit of AI is falling fast, by roughly an order of magnitude a year for the same capability. Bills are rising anyway. Both of those things are true at once.

That sounds like a contradiction, and it comes up constantly in conversations about AI spend.

Prices Are Falling. Bills Are Rising.

Mostly, this is a sign of value. Capability keeps climbing, and organizations are putting AI to work on far more than they could a year ago. The rising bill reflects higher rising use than lowering costs. So the useful question is understanding what actually shapes the bill, so spend keeps tracking value as adoption grows.

This piece of the puzzle is not new. The warning that AI costs would outrun the budgets set for them has been around for a while now, and it has been attributed to poor architectural choices and a lack of operational know-how rather than to price (1). What has changed is not whether the bill climbs, but what drives it.

Part of the increase is a change in how AI is sold. Contracts are moving from bundled seats (e.g., a subsidy for consumers) to consumption pricing, so usage that used to sit hidden inside a flat fee is now billed directly. That shift is real, but it is largely understood, and it is mostly a one-time repricing. You feel it once, you adjust, and you move on.

What I want to get into is a different driver, one that keeps changing the bill long after the pricing model settles. It is a change in where the demand comes from. As adoption moves from simple chat to agents that do real work, the demand behind the bill is increasingly generated by the software itself.

AI is the First Cost Line that Creates Its Own Demand

Think about almost any cost line a business manages. A person has always been the throttle. Someone decides to run the report, open the ticket, start the server. The cost follows a human choice, and the purchase is passive. We set the pace.

Agentic AI breaks that link. You give an agent one instruction, and the software decides how many model calls to make, how much context to carry, how many times to retry something that didn’t work the first time, whether to bring in another agent to help. The demand is generated by the tool, not by the person asking. This is new. It is the first time an enterprise cost line has been driven mainly by the software’s own decisions rather than by a human decision.

Cloud is the natural comparison, but the two behave differently. Cloud scales to serve demand that arrives from outside: a customer, a transaction, a traffic spike. An agent creates the demand itself. And the vendor can change how much an agent generates from one model release to the next, without any change on your side.

This is also why the same task can cost wildly different amounts depending on the day you ran it. One study of agentic coding tasks found token use for the same task can vary by as much as thirtyfold between runs, with higher consumption buying no additional accuracy (2). The task looked the same from the outside. What happened underneath it did not.

None of this means AI spend can’t be forecast. It means the basis for the forecast has to change. Usage doesn’t follow seats, so counting heads and multiplying by a flat number will be wrong every time. It follows how people actually work and how the software behaves on a given day, and that’s what the forecast needs to model instead.

Budget by Behaviour, Not by Headcount

Usage concentrates. A small share of users and agents tends to drive most of the spend, so a per-person budget describes almost no one.

The better basis is behaviour, not headcount. Group people by how they actually work, and set a spending cap for each group rather than one number applied to everyone. The factors worth grouping on are things like: role and function, whether someone mostly chats with a model or mostly runs agents on their behalf, the type of task (drafting, research, coding, document processing), how frequently and intensely they use the tools, and how much autonomy their agents are given to act without a human checking in first.

The technical levers underneath all this, things like model routing, prompt caching, tighter context management, output limits, are worth doing and are quickly becoming standard practice. But on their own they don’t change much, because the people generating the demand usually can’t see what it costs. Behaviour actually shifts when consumption becomes visible to the person creating it; and it shifts moreso when hitting their cap means losing access to the tool. When someone has a cap and can see what a particular way of working costs, in tokens or in dollars, they tend to adjust it themselves. Making spend visible at the point of use, alongside those group-level envelopes, does more to shape demand than any technical lever on its own.

The Absorption Gap

There’s a deeper idea underneath all of this, and it’s clearest in places where agents are already doing real build work.

The gain from agents is real. Used well, they can produce a lot of work quickly, often faster than the people reviewing it can keep up. That’s a large part of the point of using them, and it changes where the actual constraint sits. When production is abundant, it stops being the bottleneck. Absorption becomes the bottleneck instead. You pay (AI costs) at the speed the agents produce. You only capture value at the speed your organization can absorb what they’ve produced, which means reviewing it, correcting it, judging it, and actually putting it to use.

The distance between those two speeds is the absorption gap. It is a natural result of fast production, not a failure. Managing it is what turns the production gain into realized value, and anything sitting in that gap has already been paid for but isn’t doing anything yet.

Software engineering shows this most clearly, because that’s where metered agent work arrived first. A team can point agents at a codebase and have them generate far more changes than the available reviewers can check. The build cost is set by the agents. The value depends on everything slower that comes after: reviewing the work, merging it, shipping it, getting people to actually use it. Nothing returns any value until that happens. The gap between what’s built and what’s actually in use is paid-for work sitting in a queue.

The same gap appears anywhere agents produce output faster than people can act on it, and it is not a software problem. The most common version right now is mass content creation without use. A team can generate a stream of campaign assets, reports, analyses, or draft documents far faster than anyone can review them, decide on them, or put them to work. Most of it never gets used, and the meter has already run to produce every bit of it.

So the control that actually matters isn’t a spending cap on any one person. It’s a portfolio decision about which work belongs in flight at all. Because production is abundant now and absorption is scarce, the real question isn’t how much the agents can build. It’s which work is worth reviewing, deploying, and actually putting to use. Organizations get more out of AI by prioritizing the work with the clearest path to value and deliberately holding back work that would just pile up. Limiting how much runs at once still helps, but choosing what to run matters more. This is an old operations discipline, managing work in progress and yield, applied to a new kind of output.

What This Means for How We Work

The organizations that get the most from AI are going to be the ones that understand these dynamics early and design for them, so rising spend actually keeps pace with rising value instead of just climbing on its own.

A few things follow from that, practically:

  1. Forecast the work and the behaviour driving token use, not a flat count per seat. Group demand by how people actually work, and set spending envelopes by group rather than by headcount.
  2. Measure the absorption gap in your highest-volume agent workflows.
  3. Treat AI work as a portfolio: decide deliberately which work is worth absorbing, prioritize what has the clearest path to value, and pace production to what you can actually absorb.

I’ve written before about how AI is compressing delivery cycles and pushing teams toward rapid prototyping. This is a related shift, but from the cost side rather than the delivery side, and it’s the half of the conversation that gets less attention.

In a business built on people, closing the absorption gap was never about removing the humans from the loop. It’s about moving them up into the review and judgment work that now sets the pace of everything else. That’s where their time was always worth the most, and it’s the part the software still can’t do for them.


Tokenomics: the economics of how AI usage gets consumed and priced, measured in tokens rather than seats or licences.

Inference: the process of actually using a trained model to respond to a prompt, generate content, or complete a task, as opposed to training the model in the first place.

Absorption gap: the distance between how fast AI agents can produce work and how fast an organization can review, correct, and actually use what’s been produced.


Sources

(1) Gartner (2026), 10 Best Practices for Optimizing Generative and Agentic AI Costs

(2) Bai et al. (2026), How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks, Stanford Digital Economy Lab https://digitaleconomy.stanford.edu/publication/how-do-ai-agents-spend-your-money


Leave a comment