Skip to content

Why Usage-Based Pricing Is Hard to Get Right

5 min read · updated August 3, 2026

Metered pricing is usually defended as the fair one: customers pay for what they use. Fairness is real and it is not free — the same mechanism that makes a bill proportional makes it uncertain, and uncertainty has a price the buyer pays and you collect none of.

What metering transfers

Under a flat price, the seller absorbs all variance in usage: a heavy month costs you and the customer pays the same. Under metering, the buyer absorbs it. Neither arrangement destroys the variance; it decides who carries it, and the two parties are not equally able to.

You carry usage variance across a whole customer base, so it partly averages out. Your customer carries it alone, against a budget that was approved once, in advance, as a fixed number, by somebody who will not enjoy being asked to revisit it. That asymmetry is the entire reason buyers resist metering even when they concede it is fairer, and it is not irrational risk aversion. It is a real institutional constraint.

It also has a direct consequence for who your customers turn out to be. Metering is easiest to sell to buyers with elastic budgets and hardest to sell to buyers with rigid procurement, which correlates with size, sector and regulatory posture. A pricing model is a selection mechanism on customers before it is a revenue mechanism.

The risk premium, computed

A risk-averse buyer does not compare expected costs. They compare something closer to a certainty equivalent — the fixed amount they would accept instead of the uncertain one:

CE = mean(bill) + k * stdev(bill)

  k  how much the buyer dislikes variance.
     k = 0 for an indifferent buyer; k around 1
     is a reasonable working value for a buyer
     with a fixed approved budget; k is higher
     when overspending has a personal cost.

Assume a metered plan with mean $800 and stdev $400,
against a flat plan at $1,100:

  k = 0    CE = 800    metered wins by $300
  k = 0.5  CE = 1,000  metered wins by $100
  k = 1.0  CE = 1,200  flat wins by $100
  k = 1.5  CE = 1,400  flat wins by $300

The metered plan is cheaper in expectation in every row and loses in two of them. That is the whole argument in one table: a metered price has to beat the flat price by the risk premium, not by a penny. If your usage distribution has a long tail — and usage distributions nearly always do — the standard deviation is large and the premium you must beat is large with it.

The useful implication is that reducing the variance is worth as much as reducing the price, and it is usually cheaper to do. A cap truncates the distribution, which cuts the standard deviation disproportionately because the tail contributes to it quadratically. Selling the same expected bill with a ceiling on it is a genuine price cut in the buyer’s terms while costing you only the tail you probably did not want to serve at that price anyway.

Suppressed usage is a real cost

The second failure is behavioural and it is worse for AI products than for infrastructure, because the usage you are metering is the usage that makes the product habitual.

When the cost of an action is visible and uncertain, people hesitate before it. They batch work up rather than asking as they go. They stop exploring. Every one of those is a reduction in the engagement that drives retention, so metering can lower revenue through a channel that never appears in the pricing model:

revenue = users * usage(price) * price

Metering raises the perceived price of the *next*
action from zero to something, which is the largest
proportional change in price there is.

If usage falls by fraction s in response, revenue is
  users * u * (1 - s) * price
and retention falls too, because a product used less
is easier to cancel.

This is why so many products that meter also give the first units away and show a balance rather than a running charge: the goal is to move the decision away from the moment of use. Anything that puts a price tag next to a button suppresses the button.

The unit has to survive your roadmap

This is the constraint that catches teams a year in, and it has nothing to do with buyer psychology. Whatever you meter, you have promised to keep stable. Consider what a metered unit forbids:

  • Metering tokens means a quality improvement that adds a verification pass doubles your customers’ bills for the same work. You have made your own roadmap a price increase.
  • Metering API calls means an agentic redesign that turns one call into twelve is a twelvefold price rise for identical output.
  • Metering a business action — a document, a resolved case — is stable under all of those, and puts the token variance on your side of the line, where you can actually do something about it.

The rule that falls out: meter something the customer would have counted anyway. If the unit only exists because of how you happened to implement the feature, you have coupled your prices to your architecture, and one of the two will have to give.

Two operational obligations come with any meter, and both are non-negotiable once a customer is large. The count has to be auditable — itemised, timestamped, and reconcilable with something the customer can see on their side, because they will check and a discrepancy you cannot explain is a lost renewal. And the counter has to be idempotent under retries, or a network problem becomes a billing dispute.

The four fixes, in order

FixDescription
A cap the customer setsTruncates the tail of the bill distribution, which is where nearly all of the risk premium lives. Cheapest possible improvement to a metered offer, and it converts an unbounded line item into an approvable one.
Alerts before the factA forecast at the current run rate, sent partway through the period, plus a visible estimate before an expensive action. Bill shock is not caused by the amount; it is caused by the amount being a surprise.
Commitment with rolloverThe buyer commits to a floor in exchange for a lower rate and unused units carrying forward. Gives you predictable revenue and gives them a predictable budget, which is the trade both sides actually wanted.
A base plus allowance plus overageThe shape most products converge on. It bounds the downside for the buyer and the margin risk for you; the two design inequalities that make it safe are worked out in the pricing-shapes comparison.

Worth adding: none of these fixes require abandoning metering, which is the false choice the debate usually presents. Every one of them keeps the proportionality that made metering attractive and removes the variance that made it hard to buy. The buyer objection is almost never “I should not pay for what I use”; it is “I cannot approve a number I do not know”, and those are different complaints with different remedies.

None of those is exotic and the order matters: a cap and an alert are a week of work and remove most of the objection, while a repricing is a quarter of work and a renegotiation with every existing customer. The margin curves each of these shapes produces are derived in the comparison of pricing shapes, and the reason the cost being metered is variable in the first place is the subject of gross margin in an AI-native business.

Why Usage-Based Pricing Is Hard to Get Right · Multigrid