AI product pricing sits at an uncomfortable intersection: the value you deliver varies significantly by customer and use case, your cost to serve (model inference, compute, human review) fluctuates with usage, and enterprise buyers are increasingly sophisticated about calling out AI pricing that doesn't reflect delivered value.
I've worked through pricing design for AI products in clinical documentation, medical device analytics, and enterprise automation. The pricing models that survive long-term are the ones that align vendor and customer incentives over the lifetime of the relationship, not just at the point of sale.
The Five AI Pricing Models
1. Seat-Based (Per User Per Month)
The traditional SaaS model. Each named user pays a fixed monthly fee regardless of usage.
When it works: Your product is used daily by identifiable individuals who derive consistent value from it. Think AI writing assistants, AI-assisted code review, AI meeting summarization - tools where each user is the unit of value consumption.
When it breaks: When usage is irregular (some users use it daily, others monthly), when the AI feature is one component of a broader platform, or when your cost to serve is highly variable. A power user who makes 1,000 AI calls per day and a light user who makes 10 are paying the same under seat pricing but costing very differently to serve.
Practical range: $20-200/user/month for prosumer/SMB, $200-2,000/user/month for enterprise depending on the value delivered and alternatives in market.
2. Usage-Based (Consumption Pricing)
Customers pay per unit of AI consumption - per API call, per document processed, per prediction made, per token generated.
When it works: High-variance usage across customers, clear unit of value consumption, and cost-to-serve that scales linearly with usage. Ideal for infrastructure-layer AI products and developer tools.
When it breaks: When customers have unpredictable bills (kills trust and expansion), when the unit of consumption doesn't map clearly to value (paying per token when value is per document is confusing), or when customers need budget predictability for procurement approvals.
Mitigation: Usage-based with committed minimums - customers commit to a minimum annual consumption (giving you revenue predictability) and pay overages at standard rate. This is the model OpenAI, Anthropic, and Google use for enterprise API contracts.
3. Outcome-Based Pricing
Customers pay based on measured business outcomes your AI delivers: cost savings, revenue generated, time saved, cases resolved.
When it works: Outcomes are clearly attributable to your AI, measurable without dispute, and large enough that a share of them is economically meaningful. Revenue cycle AI that demonstrably improves collections rate. Fraud detection AI where prevented fraud is the measurable outcome.
When it breaks: When attribution is disputed (was that revenue improvement from the AI or from the sales team's effort?), when measurement requires accessing sensitive customer financial data, or when the customer isn't willing to share outcome data with you.
Structure: A base fee covering costs and baseline value, plus a variable component tied to measured outcomes with a cap to protect customers from unexpected exposure. Split the outcome improvement 20-40% to vendor, 60-80% to customer.
4. Tiered Feature-Based
Multiple tiers (Free/Starter/Pro/Enterprise) with different AI capabilities at each tier. Higher tiers get more AI calls, more sophisticated models, or additional AI features.
When it works: You have a genuine product hierarchy where capabilities increase meaningfully across tiers, and there's a natural upgrade path as customers grow. Effective for PLG (product-led growth) motions where individuals trial on free and expand to enterprise.
When it breaks: When tier differences are artificial (you're limiting usage rather than enabling capabilities), when enterprise buyers see the tiering as a negotiating tactic rather than genuine segmentation, or when your cost structure doesn't support the free or low-cost tiers.
5. Platform Plus AI Usage (Hybrid)
A platform subscription covers base product access, with AI features billed separately as an add-on (per seat, per usage, or included above a tier).
When it works: AI is a significant enhancement to an existing product and you want flexibility to price it separately without changing the core pricing model. Notion AI ($10/user/month add-on) and Salesforce Einstein (per-feature add-on) use this model.
When it breaks: When the AI is the core value proposition, not a feature - in that case, hiding it behind an add-on model undervalues your differentiator. Also breaks when customers resent paying twice for what they see as one product.
Cost Structure: What Drives AI Pricing Math
Before setting prices, understand your per-unit cost to serve:
- Model inference cost: Token cost at current API rates, or infrastructure cost if self-hosted. This is often surprisingly low per individual interaction - the issue is volume.
- Human review cost: For AI products with human-in-the-loop, the human review cost per case is often 10-50x the model inference cost. Price must cover this.
- Infrastructure: Embedding generation, vector database, caching, monitoring. Often 20-40% of total COGS for AI products.
- Model retraining: Amortized across customers, but meaningful for fine-tuned or custom models.
A clinical AI product I worked on had inference costs under $0.02 per document processed. But adding HIPAA-compliant infrastructure, human review for edge cases, and model monitoring, the true COGS was $0.35 per document. Pricing at $1-2 per document gave a healthy margin; pricing against a per-seat model that assumed 50 documents per user per month was underwater at the actual usage rate of 200+ documents per day for some users.
Pricing Traps Specific to AI Products
- The race to the bottom on accuracy: Competing on price by reducing model quality. Users eventually notice and churn. Compete on trust and outcomes instead.
- Free tier with unlimited AI: If your AI costs something to run, unlimited free usage doesn't work. Build metered free tiers with explicit limits.
- Pricing on inputs rather than outputs: Customers care about documents processed, questions answered, hours saved - not about tokens consumed. Price on the output unit that matches how customers think about value.
- No ceiling on usage-based billing: Enterprise buyers need budget predictability. Usage-based pricing without a cap is a procurement blocker for many organizations.
Practical Pricing Design Checklist
- [ ] Calculated true COGS per unit at realistic usage volume
- [ ] Identified the unit of value consumption that maps to how buyers think about value
- [ ] Validated pricing with 5+ buyer conversations before committing
- [ ] Built usage cap options into usage-based pricing for enterprise
- [ ] Checked competitive pricing space (direct and adjacent)
- [ ] Confirmed pricing survives a 3x usage spike without going underwater
- [ ] Defined expansion path - how does pricing evolve as customers grow?
Where this lands
Match your pricing model to how customers consume and experience value, not how you incur costs. Usage-based aligns incentives but needs committed minimums for enterprise. Outcome-based is most defensible but requires measurable attribution. Always calculate true COGS including human review and infrastructure before setting prices. Build billing caps into any consumption model for enterprise buyers. Price on the output unit, not the input cost.
