How to price an AI feature when your cost is variable

Price the AI feature on a unit whose count the customer controls, then let the spread between your median tenant and your heaviest tenant decide whether you bundle it, meter it or cap it. Five shapes are in production use today, and each one asks for a different measurement before you can commit to it.

Why seat pricing breaks on an AI feature

Seat pricing works because the marginal cost of one more seat is close to zero and roughly the same for every seat. An AI feature has neither property. Cost per user is set by how many turns a conversation runs, how many tool calls each turn makes, how much retrieved context is re-sent on every turn, and how often a failed call is retried. None of those correlate with headcount.

The distribution is the part that surprises people. Usage of a chat feature tends to be concentrated in a small number of accounts and, inside those accounts, a small number of people, so the mean cost per seat is a number almost nobody actually incurs. A support team that pastes a 40-page policy PDF into every thread and a team that asks three short questions a week are on the same line item. No public benchmark tells you how wide that spread runs in your product, so compute it over one billing period: cost per tenant at the median, cost per tenant at the 95th percentile, and the ratio between them.

Concentration also arrives through the door marked "pilot". One enterprise account wires your feature into an automated workflow, calls it from a nightly job rather than from the UI, and consumes more inference in a week than the rest of the tier does in a month. No seat count changed, so nothing in the billing system flagged it. Working out what a single conversation actually costs you is the prerequisite for every model below, and cost per AI conversation covers how to compute it end to end.

How should I price an AI feature with variable LLM costs

Match the shape of the price to the shape of the cost. If cost per account is tight around the median, a flat price is honest and cheap to run. If it is heavy-tailed, a flat price is a bet that the tail stays small, and that bet is settled by your sales team, not by you.

Five shapes are in live use. They differ in who absorbs variance, how predictable your revenue is, and what you must already be able to measure before the model is safe to sell.

The hybrid row is where most teams end up, because it is the only one that gives the buyer a predictable line item and gives you a release valve. The platform fee covers the fixed cost of having the feature at all, the included allowance is sized from the real distribution rather than from the mean, and overage prices the tail without denying it.

Choosing a billable unit that survives a model swap

A billable unit is a promise about what the customer pays for. If you bill in tokens, or in credits whose exchange rate is defined in tokens, you have promised something you will renegotiate every time you change models, add prompt caching, or shorten a system prompt. Each of those changes the token count for identical customer-visible work.

A durable unit has three properties: the customer can count it without your help, the customer's own actions change the count, and the count does not move when your implementation does. A resolved conversation, a document processed, a report generated, and a ticket deflected all qualify. Tokens, model calls, tool calls and agent turns do not, because you can halve any of them next quarter with a routing change that the customer never sees.

Keep the internal unit and the billable unit separate. Track cost per token and cost per model call for engineering, and bill on the unit above it, so that routing some traffic to cheaper models and model routing decisions show up as gross margin rather than as a price change your customers have to approve.

The rule for choosing

Take one month of production usage, group cost by tenant, and compare the 95th percentile against the median for tenants on the same plan.

1. Spread is narrow, and cost per account is small relative to plan price. Bundle it into the base price and set a fair-use cap high enough that no honest customer meets it. Record per-tenant cost anyway, because the cap only protects you if you can see who is approaching it.
2. Spread is moderate, and usage tracks the number of people using the product. Price a seat uplift, but measure cost per active user first. A buyer who licenses 400 seats and gets 40 real users makes this model look better than it is until adoption improves, and measuring AI feature adoption tells you which of those two numbers you are actually pricing against.
3. Spread is wide, and heavy accounts are heavy for a legible reason. Meter it on the customer-legible unit, with an included allowance in the platform fee. Wide spread with a legible driver is the case usage pricing was invented for.
4. Spread is wide and the driver is your own retry, planning or context behaviour. Fix the cost before you price it. Billing a customer for your agent's retries converts an engineering problem into a support argument you will lose.
5. Cost correlates with something the customer already counts as revenue or saved labor. Outcome pricing is available to you, provided you can define success in a sentence that survives a hostile reading and can measure attempts as well as successes.

Caps that do not feel punitive

Every shape above except pure usage pricing needs a limit somewhere, and a limit is where pricing turns into product experience. A cap that a customer discovers as a hard failure in front of their own end user costs more in trust than the inference it saved.

Four rules make caps tolerable. Set them per tenant rather than per seat, since the tenant is the entity with the contract, and express them in the billable unit so the number in the product matches the number in the order form. Warn on approach through the same admin surface where the customer sees their usage, not by email to whoever signed the order form. Degrade before you deny: route to a cheaper model, shorten retrieved context, or queue the request, and reserve outright refusal for abuse.

The enforcement point matters as much as the number. A cap checked before execution stops the spend; a cap computed from a nightly billing job reports it. Setting AI usage limits per customer goes through where that check belongs and what to do when a tenant crosses it mid-conversation.

What you have to measure before you commit

Every model above rests on the same three facts, and none of them can be reconstructed later from a provider invoice. You need cost per execution with the tenant and end user it ran for, attached at execution time rather than annotated afterwards. You need the count of your billable unit per tenant, computed the same way in the product and in billing. You need adoption per tenant, because a cost distribution taken during a pilot is not the distribution you will price against at scale.

Pick the shape after you can see all three for a full month. Choosing before that is choosing a hypothesis about your own cost curve and then discovering it at renewal.

Where this gets easier

Per-execution cost with tenant identity is the input every one of these models needs, and it is the input most stacks do not have until someone goes looking for it. Runtype records cost per execution, per record and per batch as part of running the agent, with cached and uncached tokens separated and the tenant and end-user identity the request ran under carried on each figure, so the distribution you price against comes from production rather than from an estimate. That makes the choice above an arithmetic exercise on real numbers instead of a bet you settle at the first enterprise renewal.