Generative AI has rewritten pricing strategy across SaaS and enterprise software, because it breaks the one assumption flat-rate pricing depended on: that serving one more user costs almost nothing. A generative feature carries a variable cost on every request (inference compute, context length, token volume, latency, model size) and the value users pull from it varies just as widely. Pricing it well means modelling cost-to-serve before setting a number, and matching the charge to what the customer actually values rather than to what the model happens to consume.
The rules that hold whichever model you pick
Three facts about AI economics anchor every pricing decision, and ignoring any one of them is how teams ship a feature that loses money at scale.
The first is that marginal cost is not near zero. Every request spends real money on inference compute, token generation, context-window expansion, memory, retrieval and vector queries, and any multi-agent orchestration on top. Understanding the cost curve is not optional; it is the input to every other choice, and it has to be modelled against realistic traffic and load, not a single average request.
The second is that value and cost do not move together. A high-value task like decision support might need a short prompt, while a low-value chore like bulk document rewriting can burn millions of tokens. Price purely on cost and you overcharge for the cheap-but-valuable and lose money on the expensive-but-trivial. Pricing has to blend value, competitive pressure and a cost floor.
The third is volatility. Usage spikes (batch jobs, automation workflows, users experimenting, a growth loop firing) arrive without warning, and the pricing system has to absorb them without either melting margin or degrading the experience for everyone else.
Charging for what people consume
Usage-based pricing is becoming the default precisely because it links what the customer pays to what the request costs. It comes in a few shapes, each with a different audience.
Token-based pricing charges by tokens generated and tokens processed as input context. Because tokens are the unit the model itself consumes, this is the most granular option available and the one that tracks cost-to-serve most closely, which is why technical audiences generally find it transparent. The problems appear outside that audience. Most buyers have no intuition for what a token is, so a quote denominated in tokens is impossible to budget against, and the same nominal task can cost wildly different amounts depending on input length. In products with non-technical users, token pricing usually survives only as the internal accounting layer beneath something friendlier.
Compute-based pricing moves the billing unit one level down the stack: GPU time, inference units or compute credits. The advantage is stability: switching to a different model architecture does not invalidate the price list the way a purely token-based scheme can. That makes it a natural fit for technical, enterprise and API-first customers, who are already reasoning about infrastructure and can map compute consumption onto their own capacity planning.
Request-based pricing is flat per request (per image generated, per document summarized, per query processed) the easiest model to explain and the easiest for a buyer to forecast. Its weakness is that it treats a one-page summary and a two-hundred-page one identically, so for LLM workloads with highly variable input length it is often too coarse, and it quietly loses money on exactly the heaviest use cases.
Hybrid usage systems are where most mature AI products end up: token pricing underneath, rate limits to bound the worst case, compute multipliers when a request uses a large context window, and higher charges for advanced model variants. The combination takes more work to design and to communicate, but it is the only one that gives the customer predictability while still capturing value from the requests that genuinely cost the most to serve.
Tiers, seats, and the ceiling problem
Subscriptions still work, but a flat AI tier hits a ceiling the moment a heavy user consumes more than their fee covers, so the tier has to carry a limit. The common design gives each plan a monthly allowance (tokens, compute credits, a request cap) with higher tiers unlocking larger context windows, higher-quality or fine-tuned models, faster inference and bigger batch limits, so price rises with capability rather than seats alone. Pairing a fixed base plan with pay-as-you-go overages beyond the allowance is what keeps that structure from forcing casual users into an enterprise tier they don't need: predictable revenue for the vendor, a soft ramp for the customer.
Credits as a shock absorber between price and cost
A credit sits between the price the customer sees and the cost the vendor pays, and its job is to hide technical volatility behind one number. A credit maps onto tokens, compute time, request volume or a model-tier multiplier (one image might cost 50 credits, a thousand tokens 10) so the customer reasons about a single currency while the vendor keeps re-tuning what a credit buys. Credits also open upsell motions a raw meter cannot: bonus packs, enterprise volume bundles, seasonal boosts, a shared wallet across products. The stickiness is real, but so is the risk: set the credit-to-cost ratio wrong and you sell a currency you lose money redeeming.
Picking the unit customers agree they are buying
Underneath the mechanics sits the real question: what is the customer paying for? The strongest answer is a value metric rooted in an outcome they already track: documents processed, tasks automated, leads qualified, hours saved, cost avoided, conversions lifted, insights generated. Pricing on one of these is value-based rather than usage-based, and it survives a change in model cost: if inference halves next quarter, the value delivered does not, so neither does the price. The condition, as always, is that the metric is observable and attributable; where it is not, you fall back to usage. Any change to the metric or the price belongs in a designed experiment with enough traffic to read significance, not a guess shipped to the whole base at once.
What it costs you before anyone has paid you
Cost is driven first by the model itself (its size and architecture set the floor under every request) and then by how much text moves through it: token throughput and context length usually explain most of the gap between a cheap feature and an expensive one. Frequency of inference multiplies whatever that per-request figure turns out to be.
The remaining drivers are architectural rather than model-related. Caching and batching efficiency determine how much work gets repeated needlessly, retrieval adds its own latency and compute on top of generation, and the choice between GPU and CPU offload, together with the region the compute runs in, can move the bill substantially without changing anything a user would notice. PMs who can name these factors are the ones who avoid shipping negative-margin AI features.
Reducing that bill without hurting the experience follows a rough order. The cheapest request is the one never sent, so caching frequent responses and trimming prompts to what the model actually needs come first. Beyond that, most savings come from not defaulting to the largest model: distillation, routing simple tasks to smaller models and switching dynamically between model families typically cut more cost than any amount of prompt-level tuning. Retrieval and synthetic memory reduce how much history has to be resent on every call, and batching spreads fixed overhead across requests. The constraint on all of it is quality: savings that users experience as worse answers do not save anything, they move the cost from infrastructure to churn.
Two forces then pull against each other over time. Inference cost per unit tends to fall (better hardware, model compression, smarter routing, architectural advances) while usage tends to rise as the feature gets adopted and automated against. Which force wins is not knowable in advance, which is why cost-to-serve is something you monitor continuously, not a figure you set once at launch.
Deciding which capability sits behind the higher tier
A premium tier only works if what sits behind it is something a segment genuinely wants and cannot easily get elsewhere. Four levers do most of the work. Premium model access (larger models, specialised fine-tunes, industry datasets, multi-modal capability) sells raw capability. Advanced automation (autonomous agents, multi-step orchestration, batch processing, real-time integrations) sells leverage. Enterprise governance (audit logs, prompt control and filtering, data residency, custom evaluation sets, SLA guarantees, dedicated compute) sells the assurances a regulated buyer cannot ship without, and commands the highest premium. And customisation (bespoke training, private embeddings, domain-knowledge integration, proprietary data pipelines) sells a result no competitor can copy, usually through high-touch sales and long contracts. The discipline is to put behind the paywall the capability a segment values most, not simply the one that costs most to run.
Testing a price without burning your existing base
Pricing is not set once; it is a running experiment, and monetization belongs inside the same discipline as any product change. The useful tests are specific (price-sensitivity checks, tier redesigns, credit-consumption modelling, churn-and-upgrade analysis, and model-perception tests that separate perceived quality from willingness to pay) and each has to clear a real significance bar before it ships. Reading them well depends on segmentation, because a single average hides the people who matter: heavy generators, enterprise automation users, long-context power users, casual users, and specialists in law, medicine or research each value different capabilities and tolerate different prices. Getting this right is as much a finance and discovery skill as a product one: cost-to-serve modelling, customer discovery, experimental design and strategic framing sit at the centre of it.
What pricing leads want answered before a repricing
What is the most common model for generative AI? Hybrids that combine subscription tiers with usage-based overages or a credit system: predictability plus cost alignment in one package.
Why does usage-based pricing matter so much? Because inference cost is variable; billing that ignores consumption erodes margin on exactly the customers who use the product most.
How should premium features be designed? Around advanced model access, automation, compliance and customisation: the capabilities a segment will pay a real premium to unlock.
Should token pricing be exposed to users? Only to technical audiences who think in tokens. For everyone else, credits or simplified tiers are easier to budget against.
Which metrics actually matter? Cost-to-serve, usage volume, model performance, workflow outcomes, value delivered and the conversion funnel, read together, not in isolation.
The order that keeps all of this coherent is simple: choose the value metric the customer agrees they are buying first, then design the packaging around it. Get that sequence right and pricing becomes a lever on margin and growth; get it backwards (packaging first, value metric never) and every clever tier just meters something the customer never agreed mattered.