Pricing an AI feature means treating inference cost as a first-class input, not an afterthought: model gross margin per unit of usage before setting a price, then use credits, usage caps, or quality tiers to keep heavy users from eroding it. Unlimited plans on cost-bearing features are the single most common margin killer.
Quick Answer: AI features have real, variable marginal cost per query, so price them against a modeled gross margin floor — using credits, caps, or tiered model quality — rather than the flat unlimited-seat logic that worked for zero-marginal-cost software.
Why the Zero-Marginal-Cost Instinct Breaks
Classic SaaS pricing assumes each additional user or action costs the company almost nothing, so unlimited usage is a safe way to compete. That assumption collapses the moment a feature calls a large language model, because every inference — every token generated, every retrieval, every agent step — has a real, metered cost from the model provider or the compute you run yourself.
Traditional software pricing evolved around near-zero marginal cost: once you built the product, serving the millionth user cost almost nothing extra. SaaS pricing models, as widely documented by pricing consultancies like OpenView and Price Intelligently, leaned into this by charging for seats, storage tiers, or feature access — proxies for value, not cost.
AI-native features invert that logic entirely:
- Every chat completion, summarization, or embedding call has a per-token or per-call cost billed by the model provider (or a real compute cost if self-hosted).
- Heavy users don't just cost you more support time — they directly consume more of your cost of goods sold (COGS).
- A single "power user" running a feature in a loop can consume the margin of dozens of light users.
This is why a flat "$29/month unlimited AI assistant" tier can look attractive on a landing page and quietly destroy margin within a quarter. The fix isn't to avoid AI features — it's to price them the way a business that sells a metered utility would, closer to cost-plus logic than pure value-based abstraction. For a deeper foundation on how value-based and cost-plus approaches differ, see /blog/value-based-vs-cost-plus-pricing.
Gross Margin as a Live Constraint
Gross margin on an AI feature isn't a static number you check once at launch — it moves every time model providers change prices, usage patterns shift, or you swap in a different model. Treat it as a live constraint you monitor per plan, per cohort, and per power-user segment, not a one-time spreadsheet exercise.
A useful mental model: every AI-powered plan has an implicit cost-per-active-user (CPAU) that competes with your target gross margin. If CPAU creeps above the margin the plan price supports, you either raise price, reduce the compute-per-action, or cap usage. Ignoring this is how "we'll fix pricing later" becomes a board-level cost problem.
| Cost driver | Why it moves | Typical mitigation |
|---|---|---|
| Model choice (e.g., frontier vs. smaller model) | Frontier models can cost 10-20x more per token than smaller, distilled models | Tier by model quality (see below) |
| Prompt/context length | Longer context windows and RAG retrieval multiply token cost per call | Cap context size per plan tier |
| Usage frequency | Power users can call a feature dozens of times per session | Credits or rate limits |
| Output length | Verbose completions cost more than terse ones | Cap max output tokens by tier |
Credits and Usage Caps to Protect Margin
Credits work because they translate an abstract "AI usage" concept into a concrete, spendable balance that mirrors the underlying cost structure — different actions draw different amounts, matching what they actually cost you. This gives you a lever to protect margin without hard-blocking every user at an arbitrary number.
The core idea, familiar from cloud infrastructure pricing (AWS, Twilio, and similar usage-metered platforms), is to decouple the unit customers pay for from the literal API call so you can adjust the exchange rate as model costs change. A "credit" is your internal currency; you control how many credits a GPT-4-class call costs versus a lightweight classification call, without renegotiating price with customers every time.
Practical patterns for credits and caps:
- Weight credits by actual cost. A long-context research query might cost 10 credits; a short classification call costs 1. This keeps your unit economics honest even as usage mix shifts.
- Set soft caps with visible remaining balance. Show users their credit balance in real time so hitting a limit feels like a budget, not a surprise wall.
- Offer credit top-ups as a release valve. Let power users buy more credits rather than force an all-or-nothing plan upgrade — this captures willingness-to-pay from your heaviest, most engaged users.
- Reserve a small "trial" allotment for new users. This lets people experience the value before you introduce any friction, which matters for onboarding — see /blog/freemium-vs-free-trial-time-to-value for how time-to-value pressure interacts with usage limits.
- Audit credit-to-cost ratios quarterly. Model provider pricing changes; your credit weights should change with it.
Credits aren't just a UX pattern — they're a margin-protection mechanism disguised as a spending account.
Hard Caps vs. Soft Caps
A hard cap blocks usage entirely once exhausted; a soft cap slows or degrades usage (e.g., queues requests, drops to a cheaper model) while still letting the user finish their task. Choose based on how catastrophic an abrupt stop is to the user's workflow versus how exposed you are to margin risk at that tier.
| Approach | Best for | Risk |
|---|---|---|
| Hard cap | Free/trial tiers, low-margin plans | Can feel punitive, hurts conversion if timed poorly |
| Soft cap (throttle or downgrade model) | Mid-tier paid plans | More complex to build and communicate |
| No cap (true unlimited) | Only viable if usage is naturally self-limiting or cost per action is trivial | Margin exposure to a small set of extreme users |
Tiering by Model Quality, Not Just Feature Count
Tiering by model quality means your pricing ladder maps to which underlying model (or model configuration) a plan gets access to, not merely how many features are unlocked. This directly ties price to cost, because a frontier model call and a smaller model call are not remotely the same COGS event.
This pattern is already visible across consumer AI products: cheaper tiers route to smaller or distilled models, while premium tiers unlock frontier models with longer context windows and higher accuracy. It works because it lets you serve the same feature at different cost points rather than building an entirely separate feature for each plan.
Considerations when designing model-quality tiers:
- Make the quality difference legible. Users should understand why the premium tier costs more — faster responses, better accuracy, longer memory — not just experience an invisible model swap.
- Avoid silently downgrading quality on a plan users already trust. If you change the underlying model for a tier, communicate it; trust erosion costs more than the margin you're protecting.
- Route by task complexity, not just plan tier, where possible. A cheap model can handle simple classification even on a premium plan, saving cost without hurting the user's experience — this is where thoughtful value metric selection matters as much as the tier structure itself. See /blog/choosing-your-value-metric for how to pick the metric that scales fairly with value delivered.
Why Model-Quality Tiering Beats Pure Feature-Gating for AI Products
Feature-gating (locking UI elements behind a paywall) doesn't map to cost the way model-quality tiering does. A gated "export" button costs you nothing extra to unlock; a gated "use our best model" tier costs you real inference dollars every time it's used. Anchoring your ladder to model quality keeps price and cost moving together as you add tiers.
The Danger of Unlimited Plans on Cost-Bearing Features
Unlimited plans are dangerous on AI features specifically because usage isn't bounded by human attention the way it is in traditional software — a single automated workflow, script, or power user can generate thousands of calls in a session, and "unlimited" then means unlimited cost exposure, not unlimited convenience.
In traditional SaaS, "unlimited users" or "unlimited projects" is safe because human behavior self-limits: nobody creates a million projects by hand. AI features break this assumption because usage can be triggered programmatically, in loops, or by increasingly agentic workflows that call the model repeatedly without a human pacing the requests.
Signs an "unlimited" AI plan is exposing you to risk:
- A small percentage of accounts (often under 5%) consume a disproportionate share of total inference cost — a pattern common enough in metered-usage businesses that it's sometimes called the usage power-law problem.
- Customers build automations or integrations on top of your unlimited tier that multiply calls without your knowledge.
- Your support or infra team notices cost anomalies days or weeks after they start, because there was no cap to trigger an alert.
If you must offer something that feels unlimited for competitive reasons, consider soft unlimited framing: unlimited within fair-use bounds, with a clearly stated policy and monitoring that flags outliers before they become a margin crisis. This mirrors how cloud providers and API platforms frame "unlimited" tiers in practice — bounded by an acceptable-use policy, not literally uncapped compute.
The riskiest sentence in an AI pricing page is "unlimited AI-powered [anything]" without a fair-use clause behind it.
Bringing It Back to the Broader Pricing Strategy
None of these tactics — credits, caps, or tiering — work in isolation from the rest of your pricing strategy. They need to sit inside a coherent framework that also answers what you charge for, how you segment customers, and how pricing evolves as the product matures. For that broader context, /blog/pricing-monetization-complete-guide walks through how usage-based mechanics fit alongside packaging, discounting, and expansion revenue decisions.
It's also worth connecting margin protection back to the underlying jobs customers are hiring your product to do. A customer paying for an AI feature isn't buying "tokens" — they're buying a faster or better outcome for a specific job, and understanding that job (see /blog/jobs-to-be-done-complete-guide) helps you decide which usage should be generously included versus metered tightly. Mapping where AI-assisted moments sit across the customer's broader journey, as covered in /blog/customer-journey-complete-guide, also helps you decide which touchpoints deserve generous free usage to build trust versus which are natural places to introduce a credit cost.
How Prodinja Approaches This in Its Own Prototype
Key Takeaways
- AI features carry real marginal cost per query, so pricing must protect gross margin as a live, monitored constraint rather than a one-time calculation.
- Credits translate abstract AI usage into a spendable balance that can be weighted to match actual inference cost per action type.
- Soft caps often beat hard caps on paid tiers because they preserve the user's task completion while still protecting margin.
- Tiering by model quality ties price directly to cost in a way that pure feature-gating never does for AI-powered functionality.
- Unlimited plans are especially risky on cost-bearing features because programmatic or agentic usage can bypass the human-attention limits that made "unlimited" safe in classic SaaS.
- Fair-use framing is a safer middle ground than either a hard unlimited promise or an overly restrictive cap that hurts adoption.
- Pricing decisions for AI features should connect back to value metric selection and the broader monetization strategy, not be designed in isolation.
Frequently Asked Questions
How do I calculate gross margin on an AI feature?
Start by estimating cost per call (model provider pricing times average tokens per request) multiplied by expected calls per user per billing period, then subtract that from the plan's price to get gross margin per user. Track this per cohort, since usage patterns and model prices both change over time.
Should I use credits or a simple monthly usage cap?
Credits are generally better when different actions have meaningfully different costs, since a flat cap treats a cheap action and an expensive one identically. A simple usage cap can work fine if your feature has only one action type with fairly uniform cost per call.
Is it ever safe to offer unlimited AI usage?
It can be safe if usage is naturally bounded by human attention or the per-call cost is trivial relative to the plan price, but it's risky for any feature that can be triggered programmatically or in loops. Most companies that offer "unlimited" AI features attach an unstated or lightly stated fair-use policy to manage the tail risk.
How often should I revisit AI feature pricing?
Revisit at least quarterly, and immediately after any change in the underlying model provider's pricing or your own model mix, since your cost base can shift faster than typical SaaS re-pricing cycles. Treat gross margin monitoring as an ongoing operational metric, not a one-time launch decision.
What's the difference between tiering by model quality and tiering by feature count?
Tiering by model quality ties your price ladder to the actual cost driver — which model handles the request — while tiering by feature count is a value-based lever unrelated to marginal cost. For AI products, model-quality tiering keeps price and cost moving together as usage scales, which pure feature-gating cannot do.