A summarisation feature priced at two cents a job can earn a 70% gross margin on a four-page memo. On a 200-page contract it loses money. Nothing about the product changed between those two requests; only the input length did.
That is the pricing problem generative AI creates. Flat-rate SaaS assumed that serving one more user costs almost nothing. A generative feature pays real money on every request, and the bill grows with how much text goes in and comes out, how fast the answer must arrive and how big the model is. The value users get from it varies just as widely. Pricing it well starts with modelling cost-to-serve and ends with a charge tied to what the customer values.
Three facts every AI price has to survive
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 cost of one more request is nowhere near zero. Each one pays for computing the answer, for the text the model reads and writes, for looking up documents and for any chain of extra model calls on top. An "average request" makes costs look better than they are. In most document products a few very large jobs eat a big share of the total. Model the curve against realistic traffic, including the heaviest decile of users, before anyone writes a price on a slide.
Value and cost do not move together. Decision support may need a short prompt and save an analyst an hour; bulk document rewriting can burn millions of tokens on a chore nobody would pay much for. Pure cost-plus pricing therefore underprices the cheap, valuable task and makes the expensive, low-value one unattractive. The workable approach models delivery cost and willingness to pay separately, then sets a price between the cost floor and the value ceiling, adjusted for what competitors charge.
Usage is volatile. Batch jobs, automation workflows, users experimenting and growth loops firing all create spikes without warning. Say a customer on a flat plan wires the feature into a nightly script that processes 5,000 documents instead of the 200 a person would submit by hand. Their cost-to-serve rises 25-fold overnight while their bill stays the same. A pricing system has to absorb that without melting margin or degrading the experience for everyone else, which is why the first design question is the meter.
Usage meters track cost, but customers have to be able to read them
If cost varies with every request and spikes without warning, a fixed bill cannot track it. Usage-based pricing links what the customer pays to what the request costs, and it comes in four shapes, each suited to a different buyer.
Token-based pricing charges by tokens generated and tokens processed as input. Because tokens are the unit the model itself consumes, this tracks cost-to-serve most closely, and technical audiences find it transparent. Outside that audience it fails on budgeting. Most buyers have no intuition for what a token is, and the same nominal task can cost very different amounts depending on input length. In products with non-technical users, token pricing usually survives only as the accounting layer beneath something friendlier.
Compute-based pricing moves the unit one level down: GPU time, inference units or compute credits. Its advantage is stability, because switching model architecture does not invalidate the price list the way a token scheme can. It fits technical, enterprise and API-first customers who already reason about infrastructure.
Request-based pricing charges a flat amount per image generated, document summarised or query processed. It is the easiest to explain and to forecast. Its weakness is the one in the opening example: a one-page summary and a 200-page one cost the buyer the same, so the vendor quietly loses money on exactly the heaviest use cases.
Hybrid systems are where most mature AI products end up: token accounting underneath, rate limits to bound the worst case, multipliers when a request uses a large context window, and higher charges for advanced model variants. They take more work to design and explain, but they give the customer predictability while still capturing value from the requests that cost the most.
One simple rule covers most cases. If the buyer is a developer integrating through an API, expose tokens or compute directly. If the buyer is a business user, price per request or per outcome, and add a size multiplier as soon as the 90th-percentile job costs more than about three times the median one. Below that spread, flat per-request pricing is simpler and the averaging works.
Tiers and credits absorb volatility, if the exchange rate is right
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 or a request cap), with higher tiers unlocking larger context windows, better or fine-tuned models, faster inference and bigger batch limits. Price then rises with capability, not only with seats. Pairing a base plan with pay-as-you-go overages keeps casual users out of an enterprise tier they do not need: predictable revenue for the vendor, a soft ramp for the customer.
Allowances and overages still bill in raw units that most buyers cannot budget against. 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. One image might cost 50 credits and a thousand tokens 10, so the customer reasons about a single currency while the vendor re-tunes what a credit buys. Credits also open upsell motions a raw meter cannot: bonus packs, volume bundles, seasonal boosts, a shared wallet across products.
The risk is the exchange rate. Work it through. A pack sells 1,000 credits for 10 USD, so each credit brings in one cent. A thousand tokens in the standard mode are priced at 10 credits (10 cents) and cost 0.4 cents to serve, a comfortable margin. A long-context mode that costs 2 cents per thousand tokens still clears 8 cents at the same rate. An agent mode is different: one user action can trigger ten model calls at 2 cents each, so 20 cents of cost against the 10 credits the action is priced at. Nothing in the credit price list signals the loss, because the customer sees one currency and the vendor sees one blended margin.
Every model and mode needs its own credit rate, reviewed whenever the underlying cost changes; otherwise you sell a currency you lose money redeeming.
Rate limits and fair-use clauses protect the margin a price list cannot
A price list sets what a unit costs. It does not stop one account on a flat plan from buying a hundred times the expected units. Three mechanisms do that work, and each has to be written down before launch.
Rate limits bound the worst minute. A cap of, say, 60 requests per minute per workspace stops the nightly script from the opening section from saturating shared capacity, and casual users never notice it, because a person typing does not reach it. The limit should return a clear error with a retry time; a silent slowdown looks like an outage and generates support tickets.
Overage pricing bounds the worst month. An allowance of 1,000 jobs with 0.03 USD per job beyond it turns the 5,000-document customer from a loss into revenue: 4,000 extra jobs bring 120 USD against roughly 24 USD of extra cost at the average job. Check the overage rate against the heaviest common job as well. At 0.03 USD, a contract-sized overage job (about 0.06 USD all-in) still loses money, so large inputs need a size multiplier even inside the overage.
Fair-use clauses cover what neither meter anticipated: resold access, automated scraping, one seat shared across a team. A clause works only if it names an observable trigger, for example sustained usage above ten times the plan median for two consecutive weeks, and a response the customer can predict, usually a conversation and an offer to move to a usage plan. Vague clauses get invoked inconsistently, and the first enforcement against a large account turns into a sales escalation.
The value metric is the price that survives a cheaper model
Whatever the structure, the customer has to know what they are 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. 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, and the margin gain stays with the vendor.
The gap between floor and ceiling is usually wider than teams assume. Take the contract summaries from the opening. All-in cost is about 0.06 USD per 200-page contract. If a paralegal would otherwise spend 40 minutes on the summary at a loaded 60 USD an hour, the buyer's value is about 40 USD per contract. Anywhere between those two numbers is a defensible price. Capturing a tenth of the value, 4 USD per contract, leaves the buyer 36 USD better off and the vendor a margin above 98%. The flat two cents per summary sits below cost on contracts and two orders of magnitude below what that segment would accept, which is the stronger argument for pricing by document size.
Outcome pricing has a real weakness: outcomes are contested. A vendor charging per "lead qualified" will argue that every lead its model touched counts; a buyer will argue that half of them would have qualified anyway. Each renewal becomes an attribution dispute, and some buyers will prefer a usage bill they can audit over an outcome bill they have to trust.
Usage pricing is the better choice when the outcome is not observable in a system both sides can read, or when the vendor's contribution cannot be separated from the buyer's own effort. In those cases, price on usage and report outcomes alongside the invoice, so value is visible without being the billing unit. Where the outcome is logged in a shared system (a document processed, a ticket resolved without escalation), outcome pricing usually wins.
Run the margin check before the number is set
None of these choices can be checked without a view of cost-to-serve. The model sets the floor under every request through its size and architecture. Token throughput and context length usually explain most of the gap between a cheap feature and an expensive one. Frequency of inference multiplies whatever the per-request figure is.
The other drivers come from how the system is built. Saving answers for reuse (caching) and grouping jobs (batching) decide how much work gets repeated for nothing. Looking up documents adds time and computing on top of generating the answer. Hardware and data-centre region can change the bill without users noticing anything. In real AI systems the model call is a small part of the whole. Collecting data, configuration, servers and monitoring make up the rest. Cost-to-serve follows the same shape, which is why a margin model built only from the provider's token rates comes out too optimistic.
A margin check before the number is set (illustrative). Take a document-summarisation feature where an average job sends 4,000 input tokens and returns 1,000 output tokens, and the model bills 0.30 USD per million input tokens and 1.20 USD per million output. Per job that is 4,000 × 0.30 ÷ 1,000,000 + 1,000 × 1.20 ÷ 1,000,000 = 0.0012 + 0.0012 = 0.0024 USD of raw inference. Add retrieval, logging and a slice of idle-GPU overhead and cost-to-serve lands nearer 0.006 USD. Price the feature at a flat 0.02 USD per summary and gross margin sits around 70%.
Now let one customer feed in 200-page contracts: input climbs toward 150,000 tokens, per-job inference approaches 0.05 USD, and the same flat 0.02 USD price is underwater on exactly the heaviest user. The arithmetic, not the intuition, is what shows a flat per-request price needs either a token component or a context-size multiplier. (Model against your provider's live rates and real traffic.)
The arithmetic also says how much of the base can be heavy before the feature as a whole loses money. With 0.014 USD of margin on a normal job and roughly 0.04 USD of loss on a contract-sized one (0.02 price against about 0.06 all-in cost), one heavy job wipes out the margin of about three normal ones. If more than about a quarter of jobs are contract-sized, the blended margin turns negative. That threshold is the number to put on the pricing dashboard.
Cutting the bill without hurting users follows a rough order. The cheapest request is the one never sent, so start by reusing frequent answers and shortening prompts. Model providers reward this with big discounts on reused input and on jobs that can wait a few hours. After that, most savings come from not using the largest model for everything. Training a smaller model to copy a bigger one, sending simple tasks to small models or switching model families usually saves more than polishing prompts. Looking up only the relevant history, instead of resending all of it on every call, also helps, and grouping jobs spreads fixed costs. Quality bounds all of it. Savings that users experience as worse answers move the cost from infrastructure to churn.
Two forces then pull against each other. Inference cost per unit tends to fall with better hardware, compression and routing, while usage tends to rise as the feature gets adopted and automated against. The first force is strong: the price of a given level of model capability has been falling fast, year after year. The second can be stronger, because a customer who scripts a feature can multiply volume by 25 in a night, as the earlier example showed. Which one wins is not knowable in advance, so cost-to-serve has to be monitored after launch, with an alert when the heavy-job share approaches the break-even threshold.
Premium tiers sell what a segment values, not what costs most
Cost-to-serve sets the floor under a premium tier, but it says nothing about whether anyone will pay above it. That depends on whether the tier holds something a segment wants and cannot easily get elsewhere. Four levers do most of the work.
Premium model access sells raw power: larger models, models tuned for one industry, industry data, and models that handle images or audio as well as text. Advanced automation sells leverage: agents that act on their own, multi-step workflows, bulk processing and live connections to other tools. Enterprise governance sells the guarantees a regulated buyer cannot do without: audit logs, control over prompts, data kept in a chosen country, custom tests, uptime promises and dedicated servers. It usually earns the highest premium, because without it the deal does not happen at all. Customisation (bespoke training, private embeddings, 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 the one that costs most to run. Governance features are a good example: audit logs and data residency cost little per request, yet they are what a bank or hospital pays for. Agent modes are the opposite trap. They can cost ten times a simple call and still be worth little to a buyer whose task needed one call.
Price tests need the same discipline as product tests
Whatever goes behind the paywall stays a guess until customers react to it, so pricing runs as a continuing experiment, and most price tests, like most product tests, will not produce a clear winner. Presentation matters as much as the number: which tier is shown first, what it is called and which one is marked as recommended all change what people pick, and none of it can be judged without a controlled test.
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. Reading them depends on segmentation, because an 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.
Two practical rules keep tests from burning the existing base. Test new prices on new sign-ups before touching existing customers, and grandfather current plans for at least one renewal cycle when a change ships.
Pair every pricing test with a guardrail metric it is not trying to move, usually 60-day retention of the tested cohort, because a higher price that lifts revenue per sign-up while cutting retention can look like a win for the first month and a loss by the third. 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.
Two questions pricing leads still ask before a repricing
Should token pricing be exposed to users?
Only to technical, often API-first audiences who already think in tokens. A buyer who cannot say how many tokens a long contract consumes cannot budget against a token quote, so for everyone else credits or simplified tiers sit on top, with tokens kept as the accounting layer underneath.
Which metrics actually matter?
Cost-to-serve per job, the share of heavy jobs, usage volume, workflow outcomes and the conversion funnel, read side by side. A rising usage line is good news while cost-to-serve per job stays under the price, and bad news the moment the heavy-contract case starts to dominate it.
Underneath both answers sits one dependency: the value metric the customer agrees they are buying has to exist before any packaging is built around it. When a team reverses that sequence, the problem tends to surface at renewal, when the heaviest accounts ask why their credits and tiers meter something they never agreed mattered, and by then the margin those accounts consumed is already gone.