How to Structure AI Pricing That Customers Will Buy

The simplest curve there is: price rises in a straight line from zero, in exact proportion to quantity. No included allowance, no base fee, no ceiling. Use ten units, pay for ten units. Use ten thousand, pay for ten thousand.

It's the shape underneath most raw token and API metering — pay a fixed rate per call, per token, per minute of compute, with nothing softening the line. It's also the fairest curve in a narrow sense: nobody ever subsidizes anybody else's usage, and nobody ever pays for capacity they didn't touch.

Same straight line as PAYG, up to a point — then it goes flat. Past the cap, additional usage is either free, throttled, or simply unavailable until the next billing period. The customer keeps the linear pricing they understand at low volume, and gets a hard ceiling on what a bad month can cost them.

This is the most direct fix for the volatility problem above, and it costs the vendor almost nothing to implement on top of a metering layer that's already tracking consumption. The cap doesn't have to be the same for every customer either — a self-serve tier might cap at a modest monthly figure while an enterprise contract caps at a number large enough to never realistically bind, existing purely as a budget backstop.

Instead of a continuous line, price moves in discrete steps. Inside a quantity band, price is flat — use more within the same band and the bill doesn't move. Cross into the next band and price jumps to a new, higher flat rate.

This is the plan-ladder pattern most SaaS buyers already know instinctively: Starter, Growth, Scale, each with its own quantity ceiling and its own flat price. It reads as simple because it is simple — a customer can look at their current usage, see which step they're on, and know exactly what the next step costs before they get there.

Same stepped tiers, but the gap between them isn't a cliff — it's metered. Once a customer's usage passes their current tier's included quantity, each additional unit is billed at a per-unit overage rate until they reach the next tier's threshold, at which point the flat step price resets.

This is the shape behind the classic "plan includes X, additional usage billed at $Y per unit" structure that dominates modern hybrid pricing — it keeps the plan-ladder simplicity for the common case while removing the tier-boundary cliff for customers who occasionally spike above their allowance. Nobody gets a surprise step-function bill; every unit of overage is priced individually and predictably.

The line doesn't start at zero. There's a fixed platform or access fee paid regardless of consumption, and usage is billed linearly on top of it from the first unit — no included allowance, just a base charge plus a straight usage line stacked above it.

This is the textbook two-part tariff, and it's a genuinely different commercial relationship from anything above it: the base fee buys access and covers the vendor's fixed cost of serving the account, and the usage line is pure marginal pricing on top. It's the structure we've covered in depth as the hybrid pricing model — a predictable floor for revenue forecasting, with the variable component doing the work of tracking value delivered.

The most common shape in AI-era SaaS pricing today. The platform fee isn't just access — it bundles a chunk of usage inside it, so the price line stays flat while the customer works through their included allowance. Only once they exhaust it does the line kink upward into linear overage pricing.

This is functionally the credits model most AI products have converged on: the subscription fee includes, say, 10,000 credits a month, and additional credits are metered at a per-unit rate once that's used up. We've written separately about what running a credit-based structure actually involves operationally — reconciliation, expiry, rollover — which is worth reading before committing to this shape, since the curve is simple but the mechanics behind it aren't.

Flat, full stop — for the length of the term. No metering the customer sees, no bill that moves with usage inside the contract period. What makes it "adaptive" rather than a plain legacy flat fee is what happens at renewal: the number itself is recalculated based on the prior period's actual consumption data, so the price doesn't stay frozen forever, it just doesn't move mid-term.

This is a deliberate compromise for buyers who want zero exposure to a moving invoice but whose vendor still needs pricing to track real usage over time. Enterprise AI contracts often land here in practice — a CFO who will not accept a metered line item on a monthly invoice will often accept that next year's number reflects this year's consumption, because it's the forecasting cycle they already run every renewal.

A guaranteed base — the flat line continuing out from the starting point — with an additional payment layered on top that depends entirely on results. The diverging dashed lines aren't a forecast, they're the range of what the bonus component could become depending on how much value the software actually delivers: none, if nothing gets achieved, or a steep upward line if it performs well.

This is a base fee with outcome-based pricing bolted onto it rather than replacing it, and it's the least predictable of the eight shapes for the vendor by design — the whole point is that the bonus line's slope isn't something either party fully controls at signing. We've gone deep on the risk profile of that arrangement separately, including who can actually absorb a bad outcome quarter and who can't, in our full breakdown of outcome-based pricing risk — read that before proposing this shape to a customer, because the base fee protects the vendor's downside far more than it protects the buyer's.

Work backward from what your buyer needs to tolerate, not from what feels most "fair" to meter. Three questions do most of the sorting:

Does the buyer need a forecastable number before they'll sign? If yes, PAYG and platform-fee-plus-usage are out unless capped — a procurement process rarely approves an open-ended line item. Tiers, tiers-with-overage, platform-including-usage, and adaptive flat rate all give a buyer something to put on a purchase order.

Is usage genuinely spiky, or does it grow steadily? Steady growth suits a continuous curve — PAYG-with-a-cap, platform-fee-plus-usage, or platform-including-usage. Genuinely spiky, agent-driven usage is better served by tiers with overage, since it absorbs a bad week without forcing an early plan upgrade the customer will resent.

Is there already a subscription relationship to extend, or are you pricing from scratch? Extending an existing product almost always means platform-including-usage — it's the shape that lets a subscription's AI features start free-feeling and become metered only for the customers actually pushing them hard. Pricing a new, usage-native product from zero is where pure PAYG, capped PAYG, or plain tiers make more sense, because there's no base relationship to protect yet.

Most mature AI pricing ends up combining two of these shapes rather than picking one in isolation — a platform-including-usage curve for the core product, with something closer to the success-bonus shape reserved for the handful of accounts where outcomes are genuinely measurable. The entitlement layer that tracks which shape applies to which customer is what makes running more than one of these at once operationally sane, rather than a spreadsheet exercise that falls over at renewal.