Usage-Based Pricing Design for AI SaaS

Usage-based pricing is the natural fit for AI SaaS products because value delivery is inherently variable: a customer who processes 10,000 documents gets more value than one who processes 100. Seat-based pricing punishes light users and undercharges heavy ones. Usage-based pricing aligns cost with value — but only if you choose the right usage metric and price it correctly from the start.

This guide covers metric selection, credit vs. token pricing, cost floor protection, and the billing architecture that makes usage-based pricing manageable at early scale.

📐 Choosing the Right Usage Metric

The usage metric is the unit you charge for. It must satisfy three conditions: it must correlate with value delivered to the customer, it must be comprehensible without a data science degree, and it must be measurable at low infrastructure cost.

Metric Type	Examples	Good When	Bad When
Output units	Documents generated, emails written, images created	Output is discrete and clearly valuable	Output quality varies widely
Input tokens / words	Words processed, tokens consumed	Technical buyers who understand LLM pricing	Non-technical buyers; creates anxiety
Credits (abstracted)	Credits per action, monthly credit bundle	Mixed workloads; non-technical buyers	If credit-to-value ratio is unclear
API calls	Requests per month	Developer tools with uniform request cost	Variable-cost operations per call
Outcomes	Qualified leads found, deals closed, bugs fixed	Clear measurable business outcome	Hard to attribute; requires tracking infrastructure

For most AI SaaS products selling to non-technical buyers: use credits or output units. For developer tools: API calls or tokens are acceptable. Never use raw token counts as your primary pricing unit for non-technical customers — they create anxiety and invite comparison to raw API pricing.

💰 Credit vs. Token Pricing

Credits are an abstraction layer between your infrastructure costs and your customer pricing. One credit = some amount of compute and LLM cost on your side. Credits let you change the underlying cost structure without repricing your product.

Credit pricing advantages:

→ Isolates customers from LLM provider pricing changes
→ Lets you mix different model costs under one unit (cheap model = 1 credit, expensive model = 5 credits)
→ Simpler mental model for non-technical buyers
→ Enables pre-purchase (credit packs) without monthly billing complexity

Token pricing advantages:

→ Developer buyers expect it and can compare directly to API costs
→ No abstraction = easier to explain cost per task
→ Better for products with one primary LLM operation

🛡 Handling Cost Volatility

AI SaaS has a structural cost risk that seat-based SaaS does not: a single power user can generate 10,000x the infrastructure cost of a casual user. Without guardrails, one customer can make your unit economics negative.

Four mechanisms to protect your cost floor:

→ Hard usage caps — cut off usage at a plan limit. Simple and predictable but creates frustrating user experiences at the boundary.
→ Soft cap with overage pricing — allow usage beyond the plan limit at a per-unit overage rate. Lets customers burst without friction; you collect more revenue on heavy users.
→ Rate limiting — cap requests per minute or hour rather than total monthly usage. Prevents runaway costs from automated bulk processing without interrupting normal usage.
→ Model routing by plan — route free and low-tier plan users to cheaper or smaller models; route paid and high-tier users to premium models. Same credit unit, different infrastructure cost.

Recommended default: soft cap + overage pricing. It maximizes revenue from heavy users while protecting you from uncontrolled cost exposure.

🔧 Billing Architecture

Usage-based billing requires real-time usage tracking, not end-of-month reconciliation. Your billing system needs to record every usage event as it happens.

Minimal usage-based billing stack:

→ Usage events written to a usage_events table per user/account in real time
→ A materialized balance view: credits purchased minus credits consumed = current balance
→ A pre-check before each AI operation: does the user have enough credits? If not, block and prompt upgrade.
→ Stripe Billing or Orb for metered billing if you need automated invoicing at scale

Minimum schema:

CREATE TABLE usage_events (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  account_id  TEXT NOT NULL,
  event_type  TEXT NOT NULL,   -- 'credit_purchase', 'credit_consumed'
  amount      INTEGER NOT NULL, -- positive = purchase, negative = consumption
  metadata    JSONB,
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

CREATE VIEW account_balance AS
  SELECT account_id, SUM(amount) AS credits_remaining
  FROM usage_events
  GROUP BY account_id;

What to Do Next

If you are pre-launch: pick your usage metric today — output units or credits for non-technical buyers, tokens or API calls for developer tools. Set your credit margin at 4–5x infrastructure cost and build in a soft cap with overage from day one. If you are live on seat-based pricing and considering a switch: run a cohort analysis on your heavy users vs. light users. If heavy users cost 5x more to serve but pay the same, usage-based pricing will immediately improve your unit economics on that segment.