The short answer. The cloud taught every company to forecast consumption costs by volume and build a stable architecture they can plan against.
Agentic workloads add another source of variance. A Microsoft Research study found that runs of the same agent on the same coding task differed by up to 30x in total tokens, and that the models could not predict their own consumption.
The Authorship Split sorts every metered line into spending somebody in the company decided, which goes through approval, and spending that moves without an internal decision, which needs a bound.
Table of Contents
Research Grounding
The mechanism and the timing come from different places.
The mechanism. A Microsoft Research paper published in April 2026 measured token consumption across agentic coding tasks. "Runs on the same task can differ by up to 30x in total tokens." Frontier models "fail to accurately predict their own token usage," with correlations to actual usage reaching only 0.39, and they systematically underestimate real costs. Expert difficulty ratings aligned only weakly with what a task actually cost. Stanford's Digital Economy Lab, covering the work in May, put it plainly: agents are not capable of predicting their own token costs.
The timing. Gartner surveyed 1,303 respondents at organizations with at least $50 million in annual revenue between January and April 2026. Roughly 11% are entirely unaware of what their function spent on AI in 2025, 85% of functional leaders plan to increase that spending in 2026, and functions gave an average of 12% of their budgets to AI last year.
The direction. Gartner predicts that by 2028, consumption-based pricing will account for over 35% of net new corporate legal technology spend with major vendors. That covers one function. BCG's April 2026 read of the software market describes the same structure from the vendor's side, with a usage-and-seat hybrid becoming the standard model for high-value AI applications.
The measurements are from coding agents rather than every agentic workload, so the 30x is evidence of a property rather than a number to plan against. The property is what matters.
Consumption that varies thirty-fold on identical inputs is a property of the system rather than a gap in the tooling.
The PE Translation
Consumption pricing is not new and neither is the discipline for handling it. Cloud has been metered since 2006, a merged pull request has always been able to move an AWS bill, and cost allocation has been broken for as long as companies have had tags. Each of those has a practice, a tool category and a job title attached to it.
That practice rests on one assumption. Plenty of things besides volume move a cloud bill, among them architecture, query behavior, data transfer and autoscaling, but for a stable architecture the resources a request consumes are a property of the system, so volume forecasts cost closely enough to plan and allocate against. That is why a software line has been among the easier things in an operating plan to underwrite.
Agentic workloads add a second source of variance the practice was not built for. How much work an agent does on a request is decided during the request, so volume can be flat while the cost of serving it moves.
Cloud cost discipline still works on the portion of the bill somebody inside the company decided. Nobody there decided the rest, and an approval process cannot reach it.
For a sponsor, this changes what the software assumption in the plan actually is. It was a contracted number with a known renewal date, and it is now a distribution with a tail set by a system chosen for not being deterministic. The right question about that line stops being what it will cost and becomes what bounds it.
The exit consequence follows. A buyer underwrites a cost structure it can see is controlled. Where a metered line has grown faster than headcount across the hold and the seller can show neither the decisions behind the growth nor a limit on it, the buyer underwrites the run rate it observes.
The last two issues examined the contracts a portfolio company sells. This one is about the contracts it signs.
Operator Experience
Three things separate this from the cloud cost problem a company already knows how to run.
The first is who can move it. AWS spending moves on infrastructure decisions, made by a platform team that is small, identifiable, and has had cost in its job description for a decade. Metered AI spending moves on application code, and increasingly on work that is not code at all: an agent assembled in a vendor console, a workflow built in a low-code tool, a prompt edit. Gartner's 12% of functional budgets says where this now sits, which is across many functions with no telemetry and no cost practice of their own rather than in one infrastructure bill with one owner.
The second is that the review which would catch an authored increase is a code review, and cost is not one of the things a code review is for. A pull request that widens a retrieval window or adds a verification pass is examined for correctness, readability and security by engineers who are good at all three. None of them knows what it does to next month's invoice, and most could not find out inside the review window. The pipeline around that review already stops a change for a failing test and for a vulnerable dependency. It has no opinion at all about one that triples the calls to a metered API.
The third has no equivalent in cloud. A service can be load-tested, because the resources a request consumes are a property of the code. An agent cannot be cost-tested against a stable cost per request, because the work it does on a request is chosen during the request. What testing produces instead is a distribution, so the figure that matters is the ninety-ninth percentile run rather than the average. Retries sit inside that tail, because a workflow that retries on failure raises spending precisely when the system is unhealthy and everyone is looking at the incident.
A limit that stops consumption is an availability decision before it is a finance decision. Whoever sets it accepts that a workflow may fail when the limit is reached, and the engineer who would set it does not carry the budget it protects. So most companies settle for an alert, which reports the money after it has been spent. That was tolerable when spending followed load and the forecast came close. Against a tail nobody authored, an alert only tells finance what already happened.
Board Question
Which of our vendor bills can a normal release raise, and who in this company approves that?
And which of them can rise with no release at all?
Every increase in a metered bill either follows from a decision somebody inside the company made, or it does not, and the two need different controls.
Spending with an internal author. Somebody decided, so the control is approval, recorded against the change.
Change class | What it moves | What the release should carry |
|---|---|---|
Frequency | How often a metered workflow runs: a new schedule, a shorter interval, a trigger placed on a busier event | The expected change in metered units per unit of business volume |
Fan-out | How much work each run does: more documents retrieved, longer context, an added verification or agent step | The same estimate, and the volume at which the change stops being affordable |
Failure handling | Retry counts, backoff and timeout behavior, which multiply calls when the system is unhealthy | A bound on calls per failed request |
Routing | Which vendor, model or service tier serves a step | The unit price difference and the volume it applies to |
Spending with no internal author. Something caused it, and it was not a decision anyone in the company made, so approval has nothing to attach to. The control has to be set before the variance happens.
Source | What moves | What bounds it |
|---|---|---|
Path selection | The model takes a longer route on this attempt: more reasoning, a replan, additional tool calls | A ceiling on calls or tokens per task, and a defined behavior when it is reached |
Vendor-side change | A changed default, a deprecated model, a version pointer that moved under a running workload | Pinned versions, and a review when a pin is released |
Input drift | The work itself gets harder while the volume stays flat | A ceiling on cost per unit of business work, and a defined response when it is crossed: a cheaper path, a reduced scope, or human escalation |
The estimate in the first table is stated in the vendor's billable unit and not in dollars, because the unit price moves during the term and the volume assumption is the part the company controls. The bound in the second table is what most companies do not have, and the research shows why a point forecast is not a substitute for one.
In diligence I would ask for the last three increases in a metered vendor's charge, and for each one, the expected impact, the actual impact and the person who approved it. An increase nobody can attribute to a decision belongs in the second table, and it needs a bound rather than a better record.
Three Decisions
Procurement holds the contracts and engineering knows what calls them, so neither can produce the list alone, which is the usual reason it does not exist. Each line needs two facts: whether shipping code can move it, and whether it can move without shipping code.
2. Put the cost check where the tests already are, for the authored portion
The delivery pipeline is the only place that sees every change before it reaches production. Start by labelling cost-bearing changes rather than blocking them, so the company builds a record while the estimates are still rough. Refusing a merge on a cost estimate is a later and harder step.
This is the work that does not get done, because setting the number requires the person who owns the outage and the person who owns the budget to agree it in advance. Until they do, the company has an alert rather than a control, and the difference is whether the money is already spent when it fires.
One Number for the Next Operating Review
30x.
Microsoft Research measured runs of the same agent on the same coding task differing by up to thirty times in total tokens.
This is a research setting and coding agents in particular, so it is not a planning figure. What it establishes is that the variance is a property of how these systems work rather than a symptom of immature engineering, so better forecasting does not remove it. The number to bring to the operating review is the company's own: for the two or three workflows that consume the most, the median run against the ninety-ninth percentile, and what currently stops the ninety-ninth.
Board Takeaway
Cloud cost discipline assumes spending follows load, and on the part of an AI bill that somebody decided, it still works.
The rest can move without an internal spending decision. Management should be able to say which metered lines carry a bound, who set it, and what happens to the customer when it is reached.
Portco Brief is a weekly briefing for PE operating partners and portfolio company executives focused on technology, AI, and value creation. If this was forwarded to you, subscribe at portcobrief.com.
Sources
Microsoft Research, "How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks", April 2026.
Stanford Digital Economy Lab, "How are AI agents spending your tokens?", May 5, 2026.
Gartner, "Gartner Survey Finds Only 22% of Organizations Have Successfully Scaled AI Across Multiple Business Units", September 1, 2026.
Gartner, "Gartner Says General Counsel Must Get Ready for Consumption-Based AI Pricing", September 3, 2026.
BCG, "Executive Perspectives: AI and the Future of Software", April 2026.