How to Price an AI Feature When Costs Are Variable

The problem seat pricing cannot solve

Traditional SaaS has a marginal cost close to zero, which is what makes per-seat pricing work: one more user on the same plan costs you nothing extra, so the price can be flat and predictable. AI features break that assumption. Two accounts with identical headcount can differ by an order of magnitude in inference spend, because one of them actually uses the feature.

Flat pricing on top of variable cost has exactly two outcomes, and you get both at once: light users are overcharged and quietly churn to something cheaper, while heavy users are subsidised out of your margin and are, individually, your least profitable customers. The dashboard shows a healthy blended gross margin the whole time.

Start from cost per task, not cost per token

Token prices are the wrong denominator because customers do not buy tokens and because the token count is not the whole bill. A completed task usually involves retries, tool calls, a retrieval step and sometimes a second model checking the first — so measure what one finished unit of work costs end to end, including the failures on the way.

Do this per workflow rather than per account. Averages across a product hide the one workflow whose cost per task exceeds its revenue, which is the thing you actually need to find.

Pick a unit the customer already counts

The billing unit should be something the buyer can forecast without understanding your architecture: documents processed, tickets resolved, reports generated, minutes transcribed. Tokens and credits fail this test — a customer cannot tell you how many tokens next month holds, so they price in a margin of fear or postpone the purchase.

If you use credits anyway, publish the conversion. A credit system that cannot be translated into money reads as an attempt to hide the price, and procurement treats it that way.

Structure: a floor, an allowance, and a meter

Most AI products converge on hybrid pricing, and the shape is consistent. A platform or seat fee covers access and the fixed costs of serving an account. A generous allowance is included so that ordinary usage never produces a surprise line on the invoice — this is what keeps the model from feeling like a taxi meter. Beyond that, usage is metered in the unit above.

Set the allowance from real data: the 80th percentile of current usage is a reasonable starting point, so four in five customers never think about overage at all.

Cap the tail before it caps you

Variable cost needs a ceiling on both sides. Give customers a spend cap or a hard stop they control, because unbounded bills produce disputes and refunds rather than revenue. Give yourself rate limits per account, because one automation loop on a customer's side can generate a month of usage in an afternoon.

Both protections are also sales assets. "You cannot accidentally spend more than X" removes the single most common objection to usage-based pricing.

Re-check the numbers quarterly

Model prices fall, your prompts grow, and caching changes what a task costs. A price set against last year's cost per task is either leaving margin on the table or quietly losing it. Recompute cost per task per workflow every quarter and treat a large change as a pricing decision rather than an engineering one.