Pricing Under Unpredictable Marginal Costs

Classical SaaS pricing rests on three conveniences. Marginal cost per user is approximately zero. The variable costs that do exist — hosting, support, third-party services — concentrate: they are roughly independent, finite-variance draws, so the portfolio mean converges and a single price of mean + margin absorbs the tail. And the distribution is stationary, so last quarter’s cost curve can price next quarter’s plan.

AI-native workloads break all three — but in specific, different ways, and the right design response depends on which one is binding. It is worth separating the sources, because much of the public discussion (“costs are fat-tailed, therefore subscriptions are dead”) conflates them.

The pricing consequence is best stated directly: a price schedule is a policy, not a price point. Formally, the schedule is a rule:

Flat-rate unlimited pricing is the degenerate policy: π is a constant, conditioning on nothing. Every real pricing decision — what to meter, what to include, where to cap, when to reprice — is a choice about what π conditions on and who holds the residual variance. The framework is the four questions above, and the remaining sections take them in turn.

You cannot design the contract before estimating the object it prices. Three quantities are worth the instrumentation, all recoverable from serving logs.

The Per-Task Cost Distribution

Report robust summaries — median, p90, p99, truncated means — not just the mean. With a standard deviation of 3.5× the mean (plausible for a truncated power law), a mean estimated from 1,000 tasks carries a ±20% interval; 100,000 tasks narrows it to ±2%. Early products are routinely pricing against a mean known to ±20%. The contract must survive that error band, which argues for structures whose viability does not depend on the point estimate (see Contracts).

Per-User Cost per Billing Period, by Segment

Within a heavy user’s month, draws concentrate; the dispersion that matters for plan design is across users. The worked example below is representative: with per-task cost drawn from a truncated power law (tail index 1.5, mean $0.01, bounded at $5), monthly cost per user concentrates for every segment — but the segment means sit 25× apart.

The Meter-Cost Ratio

If customers are billed in unit u (tasks, credits, seats) while costs accrue in compute, define R = internal cost per unit u. R is the quantity your margin actually depends on. Monitor its distribution and drift; a pricing plan is only as stable as R (see The Meter Trilemma).

Two disciplines carry over from the measurement guide. First, estimate from windows that include peak-concurrency states: a cost curve fit entirely off-peak prices a product you do not have. Second, where per-request resource cost is state-dependent and its conditional mean does not converge within the observation window, do not force it into a per-request scalar — price against capacity-impact signals (predicted sequence length, compute-time consumed) rather than predicted per-request cost.

The floor depends on who holds the variance — so compute it per contract component, not per company.

Where the vendor holds the variance (the flat part of any plan, and the allowance part of a hybrid):

The mean-plus-fixed-margin habit silently spends the difference between the mean and the tail. In the table above, the standard segment’s mean monthly cost is $5.84, but its CVaR95 — the expected cost given a bad month — is $8.44. A plan priced at mean + 40% margin has already given back most of that margin in the worst 5% of months. The right question for vendor-held tails is: how many tail months can the plan absorb before the margin is gone? If the honest answer is “fewer than one per customer-year,” the structure, not the price, is wrong.

Where the customer holds the variance (metered and overage components): the floor is allocated fixed cost plus service margin, with usage passed through at cost × (1 + m). The vendor has not eliminated risk; it has converted cost risk into bill-shock churn risk, which arrives on retention timescales. Predictability is part of the product. If you push variance to the customer, sell some of it back — caps, alerts, committed-use discounts — and price that insurance like an underwriter (next section).

Every pricing structure is an answer to one question: who absorbs the difference between expected and realized cost? The taxonomy is clearest in insurance language. The vendor underwrites some slice of the customer’s usage risk, and the premium for that slice should be set like an underwriter, not a marketer.

The insurance mapping is exact. The included allowance is a deductible in reverse (the vendor covers the first A of cost); the overage rate is co-insurance; a hard cap is a stop-loss; prepaid credits are an indemnity limit; outcome pricing is a performance guarantee that the vendor must reinsure internally through routing, caching, and model selection.

Designing the Hybrid: Allowance, Base, Overage

The hybrid is the workhorse because its parameters map one-to-one onto the measured distribution:

1. Allowance A. Set at the p80–p95 of the target segment’s monthly cost distribution. Most customers never see an overage (predictability), while the tail is paid for.
2. Base fee B. B ≥ allocated fixed cost + E[min(U, A)] + loading. The middle term is the expected cost of the covered slice; the loading prices the vendor-held variance within it.
3. Overage rate r. r ≥ unit cost × (1 + m). The slope passes the tail through at a margin, so heavy users price themselves — no adverse selection, because the marginal dollar of usage is never sold below its expected cost.
4. Optional stop-loss. A customer-settable hard cap converts residual bill-shock risk into a feature, and bounds churn risk on the vendor side.

A meter — the unit the customer is billed in — should be three things at once:

1. Cost-aligned. Bills track the driver of cost, so margin survives heavy use.
2. User-legible. The customer can predict the charge before incurring it, and can control it.
3. Manipulation-resistant. The unit cannot be cheaply gamed or arbitraged against you.

For agentic workloads you get at most two. Tokens are aligned and moderately robust, but illegible — nobody knows what a refactor costs in tokens before running it. Requests or tasks are legible and robust, but misaligned, because a task is unbounded in compute. Seats are legible and robust, and aligned to nothing. Dollar-denominated credits are aligned by construction and robust, but only semi-legible, since they still map to opaque underlying work. Outcomes (per resolved ticket, per merged PR) are legible and decouple price from cost by design, but are robust only where the outcome is verifiable — which is why outcome pricing arrives first in domains with instant verification, and why it transfers measurement risk onto the vendor.

Model menus deserve special mention. A menu of (quality, price) pairs is second-degree price discrimination that also attacks the value-revelation problem: a user who chooses the cheap model for a task reveals that task’s value sensitivity. Routing then serves the revealed-elastic demand at low cost. A well-designed menu prices information, not just compute.

The natural instinct — “power users should pay more” — partitions customers by baseline level, E[cost | X]. That is prediction, not sensitivity, and it is the pricing version of a segmentation mistake the measurement guide warns against. What justifies a different contract is a different slope: does the segment’s cost scale differently with usage, with features (long context, agentic loops), or with system state?

The validation discipline is the same as for any allocation policy:

1. Pre-specify operational segments — workload shape, customer tier, latency sensitivity — not deciles data-mined after the fact.
2. Estimate cost curves per segment (cost against usage, across windows including peak) and test whether the slopes materially differ. If they do not, one contract with different allowance levels is enough.
3. Differentiate only where the slope difference is stable. Differentiation without slope differences is price discrimination against your best customers, and they will notice.

Internal allocation already conditions on system state — queue-depth-dependent routing is a crude shadow price on the supply side. The demand-side analog is state-contingent pricing: off-peak discounts, burst pricing, priority lanes, batch-class service tiers. Even coarse two-regime pricing (peak versus off-peak credit value) shifts deferrable demand out of congested windows and recovers much of the theoretical welfare gain, without solving the full shadow-price problem.

The constraint is the customer’s predictability budget. Users accept state-contingent prices when the rule is stable and published; they revolt when the multiplier is a black box.

Everything in §1 drifts. Model releases move cost curves in both directions; efficiency gains cut unit costs while elastic demand raises volume; context growth raises the per-task bound; mix shifts as the product finds new users. Pricing is therefore a versioned artifact with a maintenance burden, not a launch decision. Three requirements:

1. Telemetry on a cadence. Recompute the §2 quantities on a schedule, and version the assumptions: every price on the page should record which model mix, context distribution, and provider rate card it was designed against. When those inputs change, the price version is stale — whether or not anyone has noticed yet.
2. Pre-committed adjustment rules. Indexation (list prices track a published cost index), caps on per-period changes, notice windows, grandfathering for existing contracts. The repricing episodes of the past two years are instructive: the backlash tracked surprise and opacity more than magnitude. A rule-following adjustment preserves trust because customers can verify the rule was applied to them fairly; a discretionary adjustment reads as betrayal even at smaller size. Commit to the rule while you are calm, so you are not negotiating it during a cost shock.
3. Repricing triggers as stop gates. Pre-specify the conditions that force a pricing review — R drifting beyond its band, allowance exceedance running above the design quantile, an upstream repricing event, a model swap — and the conditions that block a pricing change, below.

Stop Gates for Pricing Changes

Choosing a structure is a small set of questions about your measured reality:

The Worked Example, End to End

Take the §2 product, with a 50/40/10 mix of casual, standard, and power users, choosing between a $20 flat unlimited plan and the §4 hybrid ($20 base, $12 at-cost allowance, overage at 1.4× cost):

The flat plan looks healthy at the launch mix — and every dollar of its decline comes from the two correlated forces of §1, not from any single user’s tail: the mix drifts toward the segment the plan underprices, and an upstream shock moves the whole book at once. The hybrid keeps every segment profitable because its overage slope passes marginal cost through; the power user’s median bill lands at $71 with a p95 of $78 — variable, but predictable, and never sold below cost. Note what the example does not show: within-user tail blowups. With per-task cost bounded, monthly costs concentrate. The tail was never the main character — heterogeneity and correlation were.

1. Price against a distribution, not a point estimate. The mean you price against converges slowly, and it expires.
2. A price schedule is a policy. Flat rates are the degenerate case; decide deliberately what your price conditions on.
3. Every contract is underwriting. Charge the premium; cap the policy.
4. Who holds the variance is the design decision. Predictability is part of the product — sell it deliberately, on both sides of the contract.
5. Meters: alignment, legibility, robustness — pick two, engineer the third. Monitor the ratio between the billed unit and internal cost.
6. Segment where slopes differ, not where levels differ. One contract whose slope tracks cost beats a tariff sheet of special cases.
7. Publish the rule, smooth the state. Let routing absorb high-frequency variation; expose only slow, legible regimes.
8. Rule-following repricing preserves trust; discretionary repricing spends it. Commit to adjustment rules before the cost shock arrives.