Three Pricing Models for AI in Your Product

Most companies that embed AI into their product never decided on a pricing model deliberately. They picked the default — usually whatever the underlying API vendor charged them — and pushed the cost into existing margins. Six months in, the unit economics start to bend. Twelve months in, they're rebuilding the pricing page and explaining the change to the customers who used to be on the old plan.

There are three pricing models for AI features in a product. Each has a math signature. If you can identify which one you're already on, you can decide whether it's the right one.

1. Included in base pricing

The AI feature is part of the product. No separate line item. The customer pays the same as they did before AI was a feature.

When it works. When the marginal cost per AI invocation is small relative to the customer's contract value. A copilot inside a $50,000-a-year platform doesn't need its own SKU if the average AI cost per customer is a couple hundred dollars a year. Included pricing also wins when AI is a competitive table stake — when customers expect it included and a separate fee would feel like a tax.

When it breaks. When the marginal cost per use is variable and unpredictable. The customer who runs the AI feature a hundred times more than the average customer is the customer who breaks your unit economics. You're charging them the same as the light user. The light user is funding the heavy user's behavior.

The math signal. Look at AI cost as a percentage of total cost-to-serve per customer. If it's under 5% and stable across the customer base, included pricing is fine. If it's over 15% or growing, you're cross-subsidizing the heavy users at the expense of the rest.

2. Per-user surcharge

A separate fee per active user, paid monthly or yearly. The standard SaaS pattern extended to the AI feature.

When it works. When usage scales roughly with seat count. A team of twenty users generates roughly twenty times the AI usage of a single user. If that holds in your data, per-user pricing is honest and predictable — and it's the model your buyers are most fluent in.

When it breaks. When a small subset of power users dominates total usage. Pricing per seat in this case undercharges the heavy users and overcharges the light users. The heavy users are the ones who would switch to a competitor offering usage-aligned pricing the moment they noticed. The light users are paying for someone else's behavior.

The math signal. Plot AI usage by user across your customer base. If the distribution is roughly flat, per-user pricing fits. If it's a long tail — 20% of users producing 80% of usage — per-user is the wrong shape. The tail is your churn risk.

3. Transactional pricing

The customer pays per AI invocation — per query, per generated document, per API call. Direct usage-based billing.

When it works. When the underlying cost is variable and tied to specific transactions, and the value of each transaction is high enough to support the price. AI-generated legal documents at $5 per document is a viable transaction. AI-generated commit messages at $0.10 each usually is not, because the per-event value to the customer isn't visible enough to justify the metering.

When it breaks. When transaction frequency is high and per-transaction value is low. Customers feel nickel-and-dimed. Usage gets suppressed — the very behavior the pricing was supposed to encourage. The metering infrastructure costs more than the revenue it captures.

The math signal. Multiply your per-transaction price by an honest estimate of transactions per month per customer. If that number lines up with your existing per-customer pricing, transactional billing is viable. If it's wildly higher or lower than what your customers are paying overall, the model is misaligned with the rest of your business.

The decision lives in the math, not the marketing

Three patterns. Three different math profiles. The wrong model produces three predictable failures:

• Included pricing erodes margins silently as AI usage grows.
• Per-user pricing churns power users who notice they're overpaying for what they actually use.
• Transactional pricing suppresses adoption when the per-event value isn't legible to the buyer.

Most product-led mid-market companies we work with have never been forced to do this analysis. They went with whatever the launch deck said. The cost of changing pricing later is high enough that most companies live with the wrong model for years.

When mid-market product companies hire us, the pricing-model question is usually one of the first three things we surface in discovery — because it determines whether the AI feature can scale economically before it determines anything about the architecture.

If you've built AI into your product right now, the question isn't “what's the right pricing model?” The question is: do you know which one you're on, and does the math support it?