Your cost moves with user behavior. Your price doesn't have to — if you design it right.
Before any pricing mechanics, one question decides whether this chapter applies to you at all:
Does customer behavior move your AI cost?
If no — if your AI runs a fixed number of times per record, at onboarding, or in a batch job whose size you control — then your AI cost is effectively a fixed cost per account. Price simply, keep an eye on the total, and stop reading; the rest of this chapter would only add complexity you don't need.
If yes — if users can hold longer conversations, run more sessions, lean on agents, or otherwise decide how much compute you burn — then your cost per customer is a distribution, not a number (chapter 3), and a flat price is an unhedged bet on that distribution's tail. This chapter is the hedge.
There are five workable patterns. Each fits a different situation, and most real price lists combine two of them.
Usage caps at a percentile. Keep the flat price; add a generous ceiling. Set the cap from your observed usage distribution — P85 is a good default: 85% of customers never notice it exists, and the tail that was silently eating your margin now pays for what it uses. The cap's job is not revenue; it's making the flat price safe to offer.
Tier ladders. Two or three packages that step up in included usage. Customers self-select, upgrades feel natural rather than punitive, and the ladder gives your heavy users somewhere to go that isn't your margin.
Included AI units. Bundle a quantity of abstract units — calls, minutes, renders, credits — into each package; when a customer burns through them, they step up or top up. This is how the biggest AI platforms price their own products, and for good reason: units translate raw compute into a language customers can budget in, while keeping the link to your actual cost.
Per-connector / per-capacity pricing. Price the thing that scales cost rather than the usage itself — per integration, per phone line, per concurrent agent, per environment. Works well when capacity is the honest predictor of cost and customers understand it natively.
Pure usage-based. The most cost-faithful and the hardest to sell: buyers resist prices they can't predict, and procurement resists them harder. Usually better as a component (overage beyond included units) than as the whole model.
There's a tension in that menu: the patterns exist to track cost, but buyers say yes to prices they can predict. A pricing page that reads like a tax code loses deals that a clean flat price wins.
The resolution is not to choose simplicity or protection — it's to understand that your unit-cost data is what makes simplicity safe. A flat price with a P85 cap looks, to 85% of buyers, exactly like a flat price. A tier ladder set from real usage curves looks like three clean packages. The complexity lives in your analysis, not on your pricing page. Companies that skip the analysis end up with the worst of both: simple pricing that quietly loses money, or protective pricing that scares buyers.
Changing pricing feels like a leap because most teams do it blind. It doesn't have to be. If you have per-customer cost (chapter 4), every candidate change can be rehearsed before it ships: take last quarter's observed usage, apply the proposed cap, tier, or unit bundle to it, and read off what margin would have been.
An illustrative example of the shape: a product running at 61% gross margin models a P85 usage cap against last quarter's sessions and finds the same customers, same usage, would have produced roughly 67% — with fewer than one in six accounts ever touching the cap. (Numbers invented for the shape of the exercise; yours will differ.) That's not a pricing gamble anymore. It's a measured change with a known effect and a known blast radius, and you can name the specific accounts that will feel it before they do.
Every usage distribution has a far tail — the one account whose sessions are 10× the median. Don't redesign your pricing around them, and don't let them ride the standard tier either. One custom-tier conversation ("your usage is exceptional; here's a plan built for it") recovers more margin than a fleet-wide price increase, with none of the fleet-wide friction. Your per-customer cost data is what lets you have that conversation with numbers instead of vibes.
Priced right, variable cost stops being a threat and becomes a moat: you know your unit economics and your competitors are guessing at theirs. The buy-side has a different version of the same discipline — making a budget hold against spend that moves. That's chapter 6.
Next chapter: Budgets that hold →