AI Product Pricing Models: The AI Pricing Playbook

Created by Stripe - https://stripe.com/guides/pricing-ai-products-lessons-from-leading-ai-companies

Overview

AI product pricing models have to answer a question that seat-based SaaS pricing could mostly ignore: what does it cost to serve this customer, and does the price move when that cost moves? Every prompt, generation or agent run consumes paid inference, and heavy users consume far more than light ones. The AI Pricing Playbook is a sequence for setting prices under that constraint. It starts from the cost to serve one unit of value, picks a unit the buyer understands, chooses a pricing shape, and wraps it in guardrails so neither side gets surprised.

The sequence follows Stripe's guide Pricing AI products: lessons from leading AI companies, which lays out five steps: determine your value metric, set your charge metric, pick your pricing model, set your guardrails, and iterate. Stripe drew the guide from interviews with AI companies and from its own survey, in which 56% of AI company leaders reported hybrid pricing and 38% purely usage-based pricing. This page adds the cost side that the pricing steps depend on, drawn mainly from Andreessen Horowitz's analysis of AI business economics.

That cost side is the reason AI pricing is its own problem. Martin Casado and Matt Bornstein at Andreessen Horowitz found that AI companies often run gross margins in the 50-60% range, against 60-80% or more for comparable SaaS businesses, largely because inference and cloud costs scale with use. Their advice was blunt: track down your real variable costs and do not let them hide in R&D. Newer data points the same way. Kyle Poyar's survey of more than 230 software companies found a median target AI margin of about 50%, with only 12% aiming for SaaS-like margins of 80% or more.

The cost base also moves quickly, which makes pricing a moving target. Guido Appenzeller at a16z estimated that the cost of an LLM of equivalent performance is falling about 10x per year. Epoch AI found declines that range from 9x to 900x per year depending on the task, and warned that the fastest drops are recent and may not last. A price tied tightly to today's token cost will be wrong within a year in one direction or the other. The playbook handles this by charging for a unit of customer value and tracking tokens internally, so falling costs show up as margin and rising usage per task shows up in the meter.

The market has converged on a few shapes. Stripe lists pay as you go, subscription with a usage allowance, subscription plus overage, credit burndown, and subscription with replenishing credits as the common AI pricing models. Outcome pricing sits at the far end: Intercom charges $0.99 per Fin outcome, where a resolution means the customer asked for no further help after Fin's last answer. Public repricings show what happens when the shape is wrong. GitHub moved Copilot to usage-based credits because, in its words, a quick chat question and a multi-hour autonomous coding session can cost the user the same amount.

The playbook is for product, finance and go-to-market leads who own an AI feature's price. Its output is a written pricing specification: the fully loaded cost per value unit, the value metric and charge metric, the tier table with included usage and overage rates, the guardrails (rate limits, spend caps, alerts), the metering rules, and the margin floor every plan must clear at maximum use. Teams that keep this specification in Hamster can have agents check new features and tier changes against it. The eight skills below each produce one part of that specification.

Core Principles

Price From the Cost to Serve One Unit of Value

Every pricing decision depends on one number: the fully loaded cost to deliver one unit of value to one customer. That includes model input and output tokens, retrieval, retries, tool calls, logging and any human review, not only the headline model call. Andreessen Horowitz's advice to measure real variable costs instead of letting them hide in R&D applies directly. Without this number, a tier limit or overage rate is a guess about your own margin.

Charge for a Value Metric, Track the Cost Metric Internally

Customers buy documents reviewed, tickets resolved or reports produced; they do not buy tokens. Stripe's guide separates the value metric (what the customer gets) from the charge metric (what the invoice counts), and notes that consumption charges such as per token track infrastructure cost closely while workflow and outcome charges tie more closely to value. Stripe also warns that AI pricing models fail when the value metric stops tracking how customers experience value. Keep tokens and GPU time in your own dashboards and translate them into the customer's unit.

Set a Margin Floor at Maximum Use, Not Average Use

Average margin hides the customers who lose you money. Test every plan against the heaviest use it allows and set a floor that no plan may cross. Bessemer's benchmarks show how wide the range is: its fastest-growing AI companies ran about 25% gross margins, often negative, while steadier growers held about 60%. Pick your floor deliberately and write it down, because every later decision is checked against it.

Treat Rate Limits and Caps as Part of the Price

Limits decide what a plan actually delivers, so they belong in the pricing specification, not only in infrastructure config. Stripe tells companies facing cost pressure to add guardrails like rate limits or caps, or even consider repricing. Anthropic added weekly limits to its consumer plans after some users ran Claude Code continuously, and estimated the change would affect fewer than 5% of subscribers. A limit announced as a pricing decision is easier to defend than one discovered as an outage.

Make the Bill Predictable for the Buyer

Usage pricing loses deals when a buyer cannot forecast the invoice. Stripe recommends spending caps, alerts and credit-based systems that make consumption visible before it becomes a bill. A base fee with included usage, a published overage rate and an opt-in cap turns a variable bill into one procurement can approve. Credits are spreading for the same reason: Poyar found 29% of companies already use AI credits and 33% plan to add them within 6 to 12 months.

Plan for Falling Unit Costs

Model prices fall fast but unevenly, so anchor price to customer value and let lower costs flow to margin first. The a16z estimate of a 10x yearly decline for equivalent performance is an average across models; Epoch AI's task-by-task data shows the rate varies widely and recent drops may not persist. When you pass savings to customers, do it as a deliberate move, such as higher included usage or a cheaper tier, rather than a reactive cut. Usage per task can also rise as products become more agentic, which can offset cheaper tokens.

Meter Before You Price

You cannot bill, cap or check margins on usage you do not record per customer. Stripe's billing model is built on meters that aggregate customer usage events, each carrying a customer, a value and an optional idempotency key. Decide before launch how failed requests, retries and cached responses count. Metering built after the price is announced tends to produce billing disputes.

Steps

1. Map the cost to serve List every AI request type the product makes and measure input tokens, output tokens, model, retries and tool calls for each. Price them with the vendor's current per-million-token rates, keeping input and output separate, since output tokens cost more than input on published rate cards. Add retrieval, orchestration, logging and human review, then roll it up to a cost per unit of customer value. Check the model against real invoices before you trust it. The output is a cost table per value unit, with its assumptions written next to it. The inference unit economics skill covers this in detail.

2. Choose the value metric Find the unit that grows as the customer gets more value. Stripe's definition is a useful test: your metric is whatever unambiguously gives your customer more value as it increases. Check that a buyer can estimate next month's volume, that more units mean more value, and that you can count it reliably. Avoid metrics that punish exploration, such as charging for every prompt in a drafting tool. Write down two or three candidates and the reason each passes or fails.

3. Set the charge metric Decide what the invoice actually counts. Stripe describes three families: consumption, such as per token or API call; workflow, such as per completed task; and outcome, such as per successful result. Consumption is easiest to meter and closest to cost; outcome is closest to value but needs a definition both sides accept, as Intercom's published resolution definition for Fin shows. Pick the most value-aligned charge you can measure and defend in a dispute.

4. Model the usage distribution Pull per-customer usage by month and look at the median, upper percentiles and the maximum, not the average. Usage in AI products is usually skewed, so a few accounts drive most of the cost. This is where you see whether a flat price is viable: Stripe warns specifically against flat pricing with extreme usage variance. Mark natural breaks in the distribution, since those become tier boundaries. If you only have beta data, treat it as provisional, because beta users are rarely typical.

5. Pick the pricing model and design the tiers Choose among pay as you go, subscription with allowance, subscription plus overage, credit burndown and replenishing credits, the shapes Stripe observed across AI companies. For each tier, set the target customer, the included usage, the price, the overage rate and the limits. Check each tier against the margin floor at its maximum allowed use. Keep the number of billing dimensions small, because each added dimension makes the bill harder to predict.

6. Set guardrails Define rate limits, monthly caps, alerts and what happens at the cap: throttle, block, or bill overage with consent. Provider APIs show the mechanics, with limits measured across requests and tokens and enforced by whichever limit is reached first. Give customers alerts before they hit a threshold; Stripe can fire a webhook when a customer crosses a usage threshold. Publish the rules on the pricing page so the limit reads as part of the plan.

7. Build metering and billing Instrument usage per customer and per feature, send it to your billing system, and reconcile it against provider invoices. Decide whether failed requests count, whether retries bill once, and whether customers benefit from cache hits. Check what your billing tool shows mid-cycle: Stripe's basic meters reconcile usage at invoice time, while its Metronome engine tracks usage and credit burndown in real time. Ship a usage dashboard that customers can see.

8. Launch, measure and iterate Launch to new customers first, then review conversion by tier, overage frequency, pricing-related support tickets and actual margin per tier. Stripe found the highest-growth AI companies were nearly three times as likely to report frequent pricing adjustments, usually as small, local changes. Move existing customers with notice and a transition period. Cursor's apology and refunds after an unclear pricing change show the cost of skipping that step.

Pricing Shapes Compared

When to Use

• You are adding AI features to a seat-priced product and the heaviest AI users cost far more than they pay. The playbook gives you a way to price the AI part explicitly instead of letting light users subsidize heavy ones.
• You are launching an AI-native product and must choose between seat, usage, credit, outcome or hybrid pricing. The step sequence forces the cost and value questions before the price question.
• Your gross margin is falling as usage grows and you suspect the pricing, not only the model choice. The margin floor and usage distribution steps show which plans are underwater.
• Enterprise buyers object that they cannot forecast a usage bill. The guardrail step gives you caps, alerts, commits and credits that procurement can approve.
• Model prices have moved since you last priced and you need a rule for whether to keep the savings, pass them on, or raise included usage.

When Not to Use

• AI is a minor feature whose cost is small next to your other cost of goods. Absorbing it into the existing price is simpler, and a usage meter would add friction without protecting much margin.
• Every deal is a bespoke enterprise contract negotiated by hand. The playbook's tier design assumes many customers on shared plans; with a handful of large contracts, use the cost model for deal desk review and skip the tiers.
• The product is a thin resale of a third-party model with no added value. Price is set by the vendor's rate card and competitor markups, and the playbook's value-metric work has little room to act.
• Your board has knowingly chosen to subsidize usage to win a market. The playbook still helps you measure the subsidy, but its margin floor will conflict with that decision until the strategy changes.