Pricing and Packaging an AI Feature
Why marginal cost changes the pricing question, the three models in use and what each fails at, and the guardrails a pricing decision needs when usage is heavy-tailed.
Software pricing developed under near-zero marginal cost, which is why seat-based subscriptions became the default: the tenth user costs nothing to serve, so charging per user is charging for value rather than for cost. An AI feature has real per-request cost, and the mismatch between that and seat-based pricing is where margins go.
The three models
Seat-based charges per user per month. It is familiar, predictable for the buyer, and it decouples price from cost entirely. A heavy user consuming a hundred times the median destroys the unit economics for their seat, and the usage distribution is heavy-tailed enough that this is not a corner case.
Usage-based charges per token, request or task. It aligns price with cost, and it makes spend unpredictable for the buyer, which enterprise procurement dislikes strongly enough to be a sales obstacle. It also penalises engagement, which is the opposite of what a product wants.
Hybrid is what most products converge on: a subscription including a generous allowance, with overage or a higher tier beyond it. It gives buyers predictability for normal use and protects the provider from the tail. Setting the allowance requires knowing the usage distribution, which means launching with instrumentation and expecting to revise.
Outcome-based pricing, charging per resolved ticket or per completed task, aligns with value most directly and requires an agreed definition of success that both sides can verify, which is where it usually stalls.
What pricing must account for
The tail. Cost per user is not the mean; it is a distribution whose top percentile may be orders of magnitude above the median. Pricing on the mean guarantees losing money on the users who use the product most, who are also the ones least likely to churn.
Costs falling. Per-token prices have fallen substantially and repeatedly. Pricing locked to today's costs with long contracts forgoes that, and pricing that assumes continued falls is a bet.
Free tiers as uncapped liability. An unlimited free tier on a feature with real marginal cost has no ceiling, and free users' usage is heavier-tailed than paying users'. Caps on the free tier are not a growth obstacle so much as a precondition for having one.
When it breaks
Value and cost are uncorrelated. A short, cheap answer can be the most valuable output the product produces, and a long expensive one can be worthless. Usage-based pricing charges for the second and undercharges for the first, which is a real objection to it rather than a detail.
Metering has to be intelligible. A buyer who cannot predict their bill will not commit. If pricing is usage-based, the unit must be something the buyer can reason about, a task, a document, a conversation, rather than tokens, which nobody outside the industry can estimate.
Enterprise procurement wants a fixed number. Whatever the internal economics, many buyers require an annual figure, so a usage-based model often has to be sold as a committed spend with true-up, which reintroduces the estimation problem on both sides.
Cost reductions should not always become price reductions. A margin improvement from prompt caching or a smaller model can fund quality work or be passed on, and treating it as automatically one or the other forgoes a decision worth making deliberately.
12 flashcards for this concept
Click a card to reveal the answer.