If you're a SaaS founder watching your AI costs eat your gross margin, usage-based pricing is probably already on your roadmap — but most teams botch the first implementation. They overcomplicate the credit-to-action mapping, they price the credits too low, they bury the usage layer five clicks deep in billing settings, or they try to replace their entire subscription model with usage rather than layering one on top of the other. The result is a pricing page that confuses customers and a margin structure that doesn't actually improve.
[Insert diagram: a layered visual showing a SaaS pricing page with two distinct layers — Subscription tier (Starter / Pro / Enterprise) on top, Usage layer (credits, with pricing) underneath. Arrows show how usage credits get consumed by AI actions. Annotations point out which costs each layer covers.]
This post is the tactical follow-up to our broader SaaS pricing in the AI era post. The hub covers the strategic frame — why Software 3.0 is forcing the change, why freemium is breaking, why outcome-based pricing won't fully replace subscriptions. This one is the how-to: when to add usage-based pricing, how to design the credit system, what real implementations look like, and the mistakes to avoid.
What usage-based pricing actually is
Usage-based pricing charges customers based on how much they consume — not how many seats they have, not which tier they're on, but specifically how many units of a metered resource they use in a given period. The "unit" can be anything: API calls, generated images, processed contracts, AI tokens, gigabytes of storage, minutes of video processed.
The core difference from traditional SaaS pricing: the bill scales with usage rather than with access. A subscription customer pays the same amount whether they use the product heavily or barely at all. A usage-based customer pays proportionally to their consumption.
In its pure form, usage-based pricing replaces the subscription entirely. AWS, Twilio, and Stripe are canonical examples — there's no monthly "access" fee; you pay only for what you use. This worked for infrastructure-tier products where the underlying compute cost dominated, but it's a poor fit for most application-tier SaaS where the customer wants predictable budgets and access to a stable feature set.
The model that's emerging for application SaaS is hybrid. A subscription layer covers access and the non-AI features; a usage layer covers the AI compute on top. The subscription is predictable; the usage is proportional. Both layers exist on the same pricing page. This is what Notion, Cursor, Weavy, ChatGPT, Claude, and most modern AI-native products are doing.
When this post talks about "usage-based pricing for SaaS," that's the hybrid pattern — the usage layer on top of a subscription, not the replacement of subscription pricing entirely.
When to add a usage layer
The decision is driven by your unit economics, not by what competitors are doing. The trigger is simple: does the marginal cost per active user vary meaningfully with consumption?
If yes — your costs scale with how heavily each user uses the product — you need a usage layer. AI generations, video processing, large-scale data processing, anything that calls expensive third-party APIs in proportion to user activity falls here.
If no — your costs are roughly fixed per user regardless of how much they consume — you don't need a usage layer. Pure collaboration tools, simple CRMs, basic project management, anything where the underlying compute is cheap and stable can continue on flat subscription pricing.
The mistake is doing this analysis in your head. Get the actual number. Pull the OpenAI/Anthropic/Google bill from last month. Divide by active users. Look at the distribution: what does the 10th, 50th, 90th, 99th percentile user cost you? If the 99th percentile is 10x the median, you have a power-law cost distribution and a usage layer becomes mandatory. If the cost distribution is flat across users, a subscription model still works.
A few specific triggers that suggest "yes, add usage now":
- Your gross margin is shrinking month over month even though revenue is growing
- Your top 5% of users consume 50%+ of your AI compute while paying the same monthly price as everyone else
- You're considering capping AI features to control cost — that's a half-step toward usage-based pricing
- You're seeing freemium signups that don't convert but generate real AI cost — see the freemium-is-broken section in the hub post
- Customers are asking for "more AI" but your pricing page doesn't let them buy it — you're leaving revenue on the table
If any two of these apply, design the usage layer now. If three or more apply, design it this quarter.
How to design the credit system
Most teams pick credits over direct token billing for the usage layer because credits are easier for non-technical users to reason about. The customer buys "$50 worth of credits" rather than "300,000 OpenAI tokens." The mapping from credits to AI actions stays opaque, which gives you operational flexibility to adjust ratios as model costs change.
A few specific design choices that matter:
Pick a credit-to-dollar ratio that's easy to remember. $1 = 100 credits, or $1 = 10 credits, or $10 = 1 credit-pack. Don't make customers do mental math. The cleanest pattern is integer credits priced at round dollars (e.g., 100 credits for $10), which lets you write copy like "150 credits — about $15 worth."
Map credits to actions on a public reference table. Not buried in billing; right there on the pricing page. "Generating one image = 5 credits. Generating one short video = 50 credits. Sending one chat message = 1 credit." Customers can do the math forward (I want to do X, how many credits do I need?) and backward (I have N credits left, how many actions is that?). Opacity in either direction creates anxiety.
Include a baseline credit allotment with each subscription tier. Pro gets 500 credits/month included. Starter gets 100 credits/month included. Free gets 20 credits/month included (or zero, depending on your freemium decision — see the hub post). This positions credits as overage rather than the primary purchase, which feels much friendlier to subscription-oriented buyers.
Let credits roll over (within a sensible cap). Customers hate "use it or lose it." A simple rule like "credits roll over for 90 days then expire" gives buyers budget flexibility without letting them stockpile years of unused credits.
Offer volume discounts. $100 in credits should buy more than 10x what $10 in credits buys. The credit pack pricing should look like: $10 = 100 credits, $50 = 600 credits (20% bonus), $200 = 2,800 credits (40% bonus). This rewards the buyers who commit larger purchases and gives you a price-anchor that makes the small packs look like the "obvious bad deal."
Price for margin, not for cost. If an AI action costs you $0.02 in API fees, don't price the corresponding credit at $0.02. Price it at $0.04-$0.06 to leave room for your own infrastructure, fine-tuning, support, and the bumps in API pricing that come with the next model release. Starting tight on margin and trying to raise prices later is much harder than starting with sensible margin and offering volume discounts.
Real examples — what's actually shipping
Notion — Subscription tiers (Free, Plus, Business, Enterprise) plus a separate Notion AI add-on at $8/user/month. The AI add-on includes "unlimited" generations, but they reserve the right to cap heavy users — so it's structurally usage-aware even though the customer-facing pricing is flat. The decision to bolt AI on as a separate add-on rather than bundling it into tiers means existing customers can stay at their current subscription without forced AI cost, and AI-curious customers can opt in cleanly. This is one of the smoothest transitions to a hybrid model we've seen.
Cursor — $20/month Pro subscription that includes a generous monthly compute allotment, plus usage-based overage charges once you exceed it. Most users never hit the overage, so the perceived pricing is just "$20/month." Heavy power users see the overage and pay proportionally. Their take rate is high enough that the underlying compute is subsidized (a position they can't sustain forever — see the hub post's note on AI cost subsidies), but the model itself is well-designed.
Weavy (Figma's recently-acquired node-based design tool) — Free tier with a small monthly credit allotment, paid tiers with progressively larger included credits, and the ability to purchase additional credits on top. The credit system is visible on the pricing page with example mappings. This is the cleanest public example of the "subscription + credits" pattern in action.
ChatGPT and Claude — Direct $20/month Pro tiers with included usage caps, plus the option to upgrade to Team or higher tiers for additional capacity. Both companies expose usage analytics so the customer can see consumption, which builds confidence that the cap is fair rather than arbitrary.
Intercom Finn — Pure outcome-based pricing ($0.99 per AI-resolved ticket), no subscription. This is the outlier — it works because Intercom's underlying subscription was historically expensive enough that outcome-based pricing usually meant paying less. This isn't a generalizable model; it's a specific arbitrage opportunity for one incumbent. See the hub post's section on outcome-based pricing for the broader reasoning on why we don't think this pattern generalizes.
The common pattern across the successful implementations: the subscription layer remains the primary purchase, the usage layer is overage or expansion, and the customer's monthly bill is mostly predictable with a known variable component on top.
[Insert screenshot: a side-by-side of three real pricing pages — Cursor, Notion (with the AI add-on visible), and Weavy. Annotations call out where the subscription layer ends and the usage layer begins on each.]
Common mistakes on the first attempt
Five patterns we see repeatedly:
Mistake 1 — Pricing the credits at cost. Founders who are nervous about charging "too much" for AI usage often price credits at exactly what the API costs them. The result is zero margin on the usage layer, which means scaling usage doesn't grow profit. Even worse: when the next model release raises API costs, you're underwater. Price for margin from day one. Customers expect to pay a markup; they're paying for the integration and operational overhead, not just the raw API.
Mistake 2 — Hiding the credits behind a generic "AI add-on" toggle. Customers want to understand what they're buying. A pricing page that just says "+$8/month for AI features" without specifying what that gets you in terms of usage volume creates buyer hesitation. The Notion approach (AI add-on with a documented usage policy) works fine; the lazy approach (vague "AI features" line item) doesn't.
Mistake 3 — Replacing subscriptions with pure usage-based pricing. A founder reads about Stripe or Twilio and decides "we should do that too." Pure usage works for infrastructure products where the underlying compute is the entire value. It doesn't work for application SaaS where customers value predictable access. Stick with the hybrid pattern.
Mistake 4 — Making the credit-to-action mapping opaque. "Use credits to access AI features" with no documented ratio is one of the most common pricing-page failures. Customers don't know what to budget for, so they either over-purchase (resentment when they don't use it) or under-purchase (annoyance when they run out). Document the mapping. Even if you reserve the right to adjust it, the current ratio should be public.
Mistake 5 — Not running a pricing experiment before shipping. The right credit-to-dollar ratio, the right roll-over policy, the right volume-discount curve — none of these are knowable from first principles. They come from testing. Ship the first version cleanly, then run A/B tests on the actual variables. The teams who treat pricing as a one-time decision and never revisit it are the ones who end up either underpricing for years (lost revenue) or overpricing (churn). Treat pricing like product: iterate.
How the usage layer shows up on your comparison pages
When you add usage-based pricing, your competitor comparison pages suddenly have a new dimension. Buyers comparing you to a competitor will weigh both the subscription price and the usage price — and if the competitor doesn't have a usage layer, the comparison gets interesting fast.
The right move on a comparison page when you have a usage layer and the competitor doesn't:
- Show the subscription tiers side-by-side as usual
- Add a row for "AI usage" that clearly shows your model (included credits + transparent overage) and the competitor's (likely "unlimited but capped without notice")
- Lead with the customer benefit of transparency — buyers prefer knowing what they'll pay over discovering it via mid-contract throttling
The reverse — when you don't have a usage layer and the competitor does — is also worth handling explicitly. Either point out the predictability advantage of your flat pricing ("no surprise bills"), or, if your underlying cost structure is starting to crack, take the conversation as a signal that you need to add a usage layer yourself.
Frequently asked questions
"How is usage-based pricing different from per-seat pricing?"
Per-seat scales with users. Usage scales with consumption. A team of ten light users pays the same per-seat as a team of ten heavy users; under usage-based pricing, the heavy team pays meaningfully more. The two pricing dimensions are independent and most modern SaaS uses both — per-seat for the subscription layer, per-action for the usage layer. The combination matches the underlying cost reality: more seats = more login overhead, more usage = more compute cost.
"What's the right starting credit price for my AI feature?"
Start at 2-3x your underlying API cost, then test. If GPT-4 costs you $0.05 per typical interaction, your credit pricing should land that interaction at $0.10-$0.15 to the customer. The exact margin depends on competitive dynamics in your category, but starting at margin parity with infrastructure providers (40-60% gross margin) is a safe place to begin. You can always run promotional pricing later; you can't easily raise prices on existing customers.
"Should included credits roll over or expire monthly?"
Roll over with a sensible cap (most common: 30-90 days before expiry). Pure "use it or lose it" feels punitive and produces customer resentment, especially in months when usage is low. Indefinite roll-over creates accounting headaches and lets heavy users stockpile credits at promotional prices that won't be available later. The 30-90 day window balances buyer-friendliness with operational sanity.
"How do I handle customers who consistently exceed their included credits?"
Two options. Option one: automatic overage billing — once they exceed their included credits, additional usage is billed at the standard credit rate at end of month. This is the cleanest pattern and what most successful implementations use. Option two: prompt them to upgrade tier when they exceed. This works better for products where the upgrade carries other meaningful benefits beyond just more credits. Avoid the third pattern (throttling them with no warning) — it produces immediate churn.
"How does this interact with my positioning work?"
Positioning shapes who you charge how much. If you're positioned for solo founders and small teams, your subscription tiers should top out at a price that solo founders can credibly pay, and your usage layer should be priced to fit small-business AI budgets. If you're positioned for enterprise, you can absorb higher subscription tiers and a more aggressive usage layer. This is the same principle covered in The Three Phases of SaaS Marketing — positioning is the foundation that makes every downstream pricing decision easier.
"Will my existing customers tolerate the transition?"
If you handle it transparently, yes. Most existing customers signed up under the old subscription model and have an expectation that their pricing won't change abruptly. Two approaches that work: (1) grandfather existing customers on their current plan and apply the new usage model to new signups only — this keeps trust intact but means your existing book doesn't benefit from the new economics until they upgrade; (2) communicate the transition 60-90 days in advance with clear before/after pricing, an opt-in pilot, and a fallback option for customers who can't accept the new model. The mistake to avoid: silently changing pricing or quietly adding usage caps mid-billing-cycle. Both produce churn that's much more expensive than the margin you were trying to recapture.
