Which AI pricing model works when every answer costs money?

01Why AI breaks flat pricing

Traditional SaaS features cost roughly the same to serve whether a customer uses them once a week or all day. AI features do not. Model providers bill per token, with input and output priced separately, and with lower rates for cached prompt content and for batch processing. A single answer can also trigger retrieval, tool calls, web research and retries, each with its own cost. This is part of our larger guide, LLMOps for SaaS: keep AI features working in production.

The result is that cost per customer varies widely, and it varies with behavior you do not control. Your heaviest users can cost more to serve than they pay. If the plans were designed by marketing and the AI was designed by engineering, nobody owns that gap until it shows up in the margin. We cover the margin side in how much production AI costs in SaaS.

The fix is not to make AI cheaper first. It is to make the plans and the AI one design, so that every expensive action has an owner, a limit and a price.

02Map cost to actions before you map plans

Before anyone draws a pricing page, list what the AI actually does and what each of those actions costs. We work through six steps:

1. 01

   List every AI action in the product

   answer a question, generate a page, run a research pass, summarize a record, draft a message.

2. 02

   Measure cost per action from real traces, not estimates

   tokens in and out, retrieval calls, tool calls, retries and the share of requests that need a second pass.

3. 03

   Sort actions into groups

   cheap and frequent, expensive and occasional, and background work that no user triggers directly.

4. 04

   Find what can be computed once and shared. If every user sees the same analysis of the same public item, compute it once on the server on a schedule, not once per user request.

5. 05

   Decide plan limits per action group, including what the free tier shows instead of the full result.

6. 06

   Meter usage per account and show it in an admin view, so product and finance see the same numbers.

Step four often changes the economics more than any model choice. A shared result computed once costs the same for ten users or ten thousand.

03Choose the shape of your AI pricing model

Stripe's documentation describes the common recurring pricing models: flat rate tiers, per-seat pricing, tiered pricing, and usage-based pricing, which includes fixed fee and overage, pay as you go, and credit burndown. Each behaves differently once AI cost enters the picture.

There is no universally right answer. The right shape is the one where the most expensive action in your product is either limited or paid for.

04Enforce limits on the server

Plan gating in the interface is a suggestion. A hidden button can be found, and an API can be called directly. Enforcement has to happen on the server, at the exact point where an AI action is triggered: check the plan, check the quota, then run the work.

A few more controls make the limits hold up in practice:

• Give the free tier a real but lighter result, such as a probability and a short summary, with the full analysis on paid plans. That shows value without paying for the expensive path.
• Route by cost. A fast, cheaper model can handle routine requests while a stronger model handles hard ones, with a default fallback when the preferred model fails.
• Log token usage per conversation or per action, so you can see which accounts and which features drive cost.
• Decide in advance what happens at the limit: a clear message, an upgrade path, or a top-up, never a silent failure.

05Test the plans like features

Pricing logic is code, and it breaks like code. Include plan gating in your test plan: a free account trying the paid action through the API, a paid account at its quota, a downgrade in the middle of a billing period, a failed payment. These cases are easy to miss in a demo and expensive to discover in production.

Review the numbers after launch as well. Compare cost per account with revenue per account every month, by plan. If one plan consistently costs more to serve than it earns, the fix is usually a limit on one specific action, not a new price for the whole plan. Because the AI actions were listed and metered from the start, that review takes an hour instead of a project.

06What we see in production

For a founder building a subscription analytics product for prediction market traders, we started with a written technical review of the repository and the live product. It included a full-stack run with nothing mocked and checks on accounts, Stripe subscriptions and plan gating. That review produced a list of blockers and fixes before the product went to beta users. In that product, plan enforcement decides who can trigger AI research and how often. The gap between the AI probability and the market probability is computed once on the server, and plan gating is enforced on the server. The free tier shows the AI probability and summary, and paid plans get the fuller analysis.

For a founder-led AI company, we engineered an AI website builder with Stripe credit billing and quota enforcement. We recommended keeping the credit model with top-ups rather than moving to a flat subscription, because generation cost varies so much from one request to the next. In the children's version of the same builder, the word credits was changed to parts for young users, a reminder that the billing model also has to make sense to the person using it.

In a governed internal app builder, we added per-organization model routing between fast and strong models from two providers, with an audit entry on every change and a default fallback. In a multi-tenant sales assistant for dealer websites, built in partnership with a dealership software company, token usage is logged per conversation so cost can be tracked and controlled for each tenant.

Frequently asked questions