John

Posted on Mar 31 • Originally published at saaslogic.io

What working on SaaS billing taught me about token-based vs subscription pricing for AI products

#ai #sass #startup #webdev

At Saaslogic, we work closely with SaaS billing infrastructure across growth-stage products. One pattern keeps showing up: AI SaaS founders defaulting to subscription pricing and quietly breaking their margins under usage variance.

It's not laziness. Subscription pricing is familiar, easy to sell, and simple to implement. But for AI products specifically, it creates a structural problem that compounds as you scale and by the time most founders notice it, they've already frustrated a chunk of their best customers.

Here's what I've learned from being close to this problem daily.

The core issue with subscriptions for AI products

Subscription pricing was designed for software with relatively flat infrastructure costs. A project management tool, a CRM, an email platform, your costs don't change much whether a user logs in twice a week or twenty times.

AI products break this assumption completely. Every inference call, every document processed, every image generated consumes variable compute. Two users on identical plans can cost you 40× differently to serve.

The result is one of three bad outcomes:

You overprice light users → they leave for a more flexible competitor
You underprice heavy users → you bleed margin silently every month
You cap usage to protect margins → you frustrate your most engaged customers

Token-based pricing exists to solve exactly this.

What token-based pricing looks like in practice

You already use products built on this model:

OpenAI — charges per input and output token
Replicate — charges per second of GPU compute
AWS Rekognition — charges per image analyzed
Anthropic — per-token pricing across Claude API tiers

The pattern is consistent: when underlying compute costs scale with usage, the pricing model should too. Customers pay for what they consume. You earn more when they use more.

The honest tradeoffs

Neither model is universally better. Here's the direct comparison:

	Subscription	Token-based
Revenue predictability	High	Variable
Customer budgeting	Easy	Harder
Fairness at scale	Low	High
Best for	Consistent, daily-use tools	Variable or burst-heavy AI workflows
Churn risk	Light users feeling overcharged	Heavy users hitting surprise bills
Implementation	Simple	Requires usage tracking + metered billing

The implementation complexity of token-based pricing is real but manageable. Stripe's metered billing handles most of it cleanly.

A simple decision framework

Before choosing, answer these three questions:

1. What's your usage variance ratio?

Divide your 90th percentile user's monthly consumption by your median user's consumption.

Under 3× → subscription works fine
Over 5× → token-based pricing almost always wins

Most founders skip this calculation entirely and copy their competitor's pricing page instead.

2. Who approves the purchase?

B2B enterprise buyers prefer subscriptions, and predictable invoices make budget approval easier. Developers and technical buyers prefer usage-based models, as they understand compute costs and appreciate the transparency. Know your buyer.

3. Can you absorb billing variance on your end?

Token-based pricing shifts cost uncertainty from customer to you. If your infrastructure costs are already variable (as most AI products' are), this alignment is natural. If you have high fixed costs regardless of usage, a hybrid approach protects your margins better.

The hybrid model: what most mature AI SaaS products actually use

Pure subscription or pure token-based is increasingly rare at scale. Most mature AI SaaS products in 2026 use a hybrid:

Base subscription + usage overage. The customer pays a fixed monthly fee covering a token allocation. Usage beyond that bills at a per-token rate. Predictability for typical usage, proportional billing for power users.

Here's the Stripe implementation pattern for metered billing:

Step 1 — Create a metered subscription item

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

// Create a price with metered billing
const price = await stripe.prices.create({
  currency: 'usd',
  unit_amount: 1, // $0.01 per token (adjust to your model)
  recurring: {
    interval: 'month',
    usage_type: 'metered',
    aggregate_usage: 'sum',
  },
  product: 'prod_xxxxx', // your product ID
});

Step 2 — Report usage after each AI operation

async function reportTokenUsage(subscriptionItemId, tokensUsed) {
  await stripe.subscriptionItems.createUsageRecord(
    subscriptionItemId,
    {
      quantity: tokensUsed,
      timestamp: Math.floor(Date.now() / 1000),
      action: 'increment', // accumulates throughout billing period
    }
  );
}

// Call this after every AI operation in your app
await reportTokenUsage('si_xxxxx', 1240); // 1,240 tokens consumed

Step 3 — Check current usage anytime

async function getCurrentUsage(subscriptionItemId) {
  const usageRecords = await stripe.subscriptionItems.listUsageRecordSummaries(
    subscriptionItemId,
    { limit: 1 }
  );
  return usageRecords.data[0]?.total_usage ?? 0;
}

This architecture gives you complete billing flexibility — you can set a free tier, a base allocation, and overage rates independently without rebuilding your billing logic.

My take for 2026

For most AI SaaS products launching today, I'd default to usage-based with a free tier over a flat subscription. Here's why:

Usage-based pricing naturally attracts developers and technical evaluators. A free tier with real token limits converts better than a 14-day trial with arbitrary feature gates because developers want to see actual cost before committing, not a countdown clock.

As those users grow, their billing grows proportionally. Your best customers self-select into higher revenue without a manual upsell motion.

Subscriptions are easier to pitch to enterprise buyers, but most AI SaaS products don't start with enterprise buyers. They start with builders. Price for the customer you have, not the customer you hope to have in year three.

DEV Community