Charging Users for AI: Credits, Seats or Usage

Every pricing model for an AI product is an answer to one question: who absorbs the variance in usage. There are only four answers, and each one has a margin curve you can write down.

The problem all four are solving

Traditional software has fixed cost and zero marginal cost, so a flat subscription is nearly risk-free: a customer who uses the product ten times more costs you nothing extra and is simply a happier customer. Inference breaks that. The tenth-percentile and ninety-ninth-percentile users of the same plan can differ by two orders of magnitude in what they cost to serve, and the pricing model decides who carries that.

Throughout, R is revenue per user per period, u is requests per user per period and c is your fully loaded variable cost per request, from the unit-economics model.

Seats: margin falls as the product succeeds

revenue = R                      (flat)
margin  = 1 - (u * c) / R        (falls linearly in u)
zero at  u* = R / c

R = $20, c = $0.012  ->  u* = 1,667 requests per month

The curve is a straight line sloping down. Every improvement in engagement moves each customer to the right along it. That is the uncomfortable property of seat pricing for AI: you are penalised for the product being good, and the penalty arrives via exactly the metric your product team is optimising.

• Works when usage per seat is bounded by something real — a human’s working hours, a fixed number of documents a month, a workflow with a natural ceiling — and the variance across seats is low.
• Fails when a seat can be automated, shared, or pointed at a batch job. One scripted seat can consume more than a hundred human ones, and there is no term in the revenue to notice.

Pure usage: margin is constant, adoption is not

revenue = u * p          p = your price per unit
margin  = 1 - c / p      constant in u, by construction

p = 4c  ->  margin = 75% at every usage level

Metered pricing is the only shape where margin does not depend on behaviour, which makes it the safest for you and the least comfortable for the buyer. The costs it imposes are real and are not financial:

• Unpredictable bills suppress usage. Users self-limit when they cannot predict the cost, which lowers engagement — the thing you were trying to grow.
• Procurement hates it. An unbounded line item is hard to get approved, and many enterprise buyers will simply require a cap, at which point you are doing hybrid pricing anyway.
• The unit must be legible. Pricing per token exposes an implementation detail and makes your bill move when you change models. Price per action the user recognises — per document, per query, per minute — and absorb the token variance yourself.

Credits: a currency you now have to manage

Credits are metered pricing with prepayment and an abstraction layer. They solve the legibility problem — one credit is one action — and create three new problems.

• The exchange rate is a commitment. You have fixed how many credits an action costs. If the model behind it gets more expensive, or you add a verification pass, your margin moves and the price cannot without a customer-visible change. Build the buffer in from the start: set the credit cost of an action from a pessimistic c, not from today’s.
• Breakage is revenue you should not plan on. Unused credits look like profit. Depending on jurisdiction and on your terms, unexpired credits may be a liability on the balance sheet, and expiry policies are regulated in some places. This is a question for a finance person before it is a question for an engineer.
• Users must be able to predict consumption. If an action can cost between one and forty credits depending on document length, credits are as unpredictable as metering with an extra layer of confusion. Either make the rate flat and absorb the variance, or show the cost before the action.

The version that works well is credits as a ceiling rather than as a currency: a plan includes a number of actions, they are visible in the interface, and the buyer knows what they bought.

Seat plus allowance plus overage

The shape most products converge on, and it is worth writing out because the margin curve is piecewise and both pieces need checking.

revenue(u) = R + max(0, u - A) * p_over

  A       included allowance
  p_over  overage price per unit

margin(u):
  u <= A :  1 - u*c / R                       falls, as for seats
  u >  A :  1 - (u*c) / (R + (u-A)*p_over)    recovers if p_over > c

Design rule:   A < R * (1 - m_target) / c      and    p_over > c / (1 - m_target)

R = $20, c = $0.012, m_target = 0.70:
  A      < 500 requests
  p_over > $0.040 per request

Those two inequalities are the whole design. Satisfy both and no customer, at any usage level, can fall below your target margin. That is a stronger guarantee than any of the pure shapes offer, and it costs you a more complicated invoice.

The failure mode to avoid is an allowance set generously for marketing reasons and an overage price set timidly for the same reasons. That combination is a seat plan with extra steps, and it has seat pricing’s margin curve.

The statistic that chooses for you

Compute the coefficient of variation of usage across your users — the standard deviation of requests per user divided by the mean.

CV = stdev(u) / mean(u)

CV well below 1   users are similar     -> seats are safe
CV around 1       moderate spread       -> seats + allowance + overage
CV well above 1   heavy tail            -> metered, or a hard cap

It is one query over a month of usage and it settles most of the argument, because it measures exactly the thing the pricing model has to absorb. A second useful statistic is the share of total usage coming from the top 1% of users: above roughly a third, no flat plan survives contact with them and some form of metering is unavoidable.

Two closing notes. Whichever shape you pick, make cost visible inside the product before the expensive action, not on the invoice afterwards — an interface that shows what something will consume gets far fewer refund requests than one that does not. And keep the internal accounting in a unit you control regardless of what the customer sees: charge in credits, account in integer micro-dollars, and never let the customer-facing abstraction become the number your margin reporting is built on.