Consumption-Based Pricing Models for SaaS: The Complete Taxonomy
This page answers one question: what are the consumption pricing models, and how does each one actually bill? It is a taxonomy, not a recommendation. Whether consumption pricing suits your product is covered in Usage-Based Billing: What It Is and When to Use It; how to set the numbers is in Usage-Based Pricing: How to Price SaaS by Consumption.
Stripe’s own billing documentation organizes recurring pricing into four models — flat rate, per-seat, tiered, and usage-based — and states that usage-based pricing itself breaks down into fixed fee and overage, pay as you go, and credit burndown [1]. This page expands that skeleton to the nine models you’ll actually encounter in vendor pricing pages, and describes the billing mechanics of each.
Terminology first
Three terms describe the same family of models, and this cluster uses them interchangeably:
- Usage-based billing — the term SaaS companies and developers reach for
- Consumption-based pricing — the term infrastructure vendors use
- Metered billing — the term billing systems and payment APIs use
They are synonyms. The distinction some draw — that “usage” means product activity while “consumption” means infrastructure resources — is semantic, not structural.
The models at a glance
Model
What triggers a charge
Base commitment
Bill varies by
Complexity
Flat rate
Per-seat
Pay-as-you-go
Fixed fee + overage
Graduated tiers
Volume tiers
Prepaid credits
Committed spend + overage
High-watermark
Outcome-based
The first two are not consumption models — they’re the baseline every consumption model is measured against, and Stripe lists them as peer pricing models [1].
1. Flat rate
Customers choose a service tier and pay a fixed amount for it [1]. Usage is irrelevant to the invoice.
How it bills: one recurring charge, one amount, every cycle. No metering layer exists.
Where you see it: Basic / Starter / Enterprise plan structures across most of B2B SaaS.
Why it appears in a consumption taxonomy: it is the control case. Every consumption model trades flat-rate predictability for usage alignment. Knowing what you’re giving up matters more than the case for the change.
2. Per-seat
Each pricing unit represents one user; a business buys a license per employee who needs access [1].
How it bills: seat count × per-seat price, adjusted for adds and removals mid-cycle.
The failure mode consumption models exist to solve: a customer with 12 active users buying a 50-seat license pays for capacity they don’t use. The value delivered and the amount charged diverge.
3. Pay-as-you-go (pure metered)
No base fee, no commitment. Every unit of consumption is billed at a per-unit rate. Stripe names this as one of the three usage-based sub-models [1].
How it bills: meter events → aggregate per period → apply rate → invoice. Nothing is billed if nothing is consumed.
Verified example — Twilio. The pricing page leads with “Start for free. Then pay as you go” and states pricing is current as of August 2026 [3]:
Product
Rate
SMS
RCS
WhatsApp Business API
Voice
Elastic SIP Trunking
Twilio Email
Verify
Functions
Studio
TaskRouter
Note the pattern: Twilio’s page states “no monthly fees” and “the freedom to scale up or down without contracts” [3]. That is the model’s defining property — and its defining risk, since the customer carries all the variance.
Structural requirement: this model needs a metering layer from day one. There is no subscription object to fall back on.
4. Fixed fee and overage (hybrid)
A base subscription includes an allowance; consumption beyond it bills at a per-unit rate. Stripe names this as a usage-based sub-model [1].
How it bills: base fee every cycle, plus (total usage − included allowance) × overage rate.
Verified example — Twilio SendGrid Email API. “Start for free with 100 emails/day. Paid plans start at $19.95/month” [3]. The free allowance, the monthly base, and the per-volume overage are three separate mechanics in one product.
Verified example — Twilio Flex and Video. “Start with 5,000 hours free. $1/active user hour or $150/named user per month” [3]. This is a hybrid with a choice of unit — metered hours or flat named seats — on the same product line.
Why this dominates SaaS: the base fee gives a finance team a predictable line item and covers fixed costs; the overage captures expansion. Most companies that describe themselves as “usage-based” are running this.
5. Graduated tiers
Usage is segmented, and each segment is billed at its own rate. Stripe distinguishes graduated pricing from volume pricing under its Tiered model [1].
How it bills: 0–10,000 units at rate A; 10,001–100,000 at rate B; 100,001+ at rate C. A customer consuming 150,000 units pays A on the first 10,000, B on the next 90,000, and C on the remainder.
The property that matters: the bill never decreases as usage increases. Crossing a tier boundary is always an improvement.
6. Volume tiers
The unit cost changes with quantity, but the rate for the highest tier reached applies to all units — Stripe names this volume-based pricing as the sibling of graduated [1].
How it bills: at 150,000 units, every unit bills at rate C.
The cliff problem this creates: a customer at 99,000 units pays more than a customer at 101,000 units. This is a real support and revenue problem, not a theoretical one, and it’s the main reason most SaaS companies choose graduated over volume.
Worked comparison
Same rate card, two models, 150,000 units consumed:
Band
Rate
0–10,000
10,001–100,000
100,001+
Graduated: (10,000 × $0.010) + (90,000 × $0.008) + (50,000 × $0.005) = $100 + $720 + $250 = $1,070
Volume: 150,000 × $0.005 = $750
The volume customer pays 30% less for identical usage — and the customer at 100,000 units pays $800 while the customer at 100,001 pays $500.
7. Prepaid credits / credit burndown
The customer buys a credit balance up front; consumption draws it down. Stripe names credit burndown as the third usage-based sub-model [1].
How it bills: purchase creates a balance. Each metered event decrements it. When the balance reaches zero, service stops or auto-recharge triggers.
Why AI SaaS converged on this: it decouples the consumption unit from the price. You can change per-event credit costs without renegotiating contracts, and the customer gets a spend ceiling they control — the single most common objection to pure pay-as-you-go.
Variants worth knowing: credits with expiry (use it or lose it), auto-recharge thresholds, and credit top-ups layered onto a base subscription.
8. Committed spend with overage
The customer contracts to a monthly minimum; usage above the commitment bills at a separate rate.
Verified example — Datadog’s hybrid monthly/hourly plan (MHP). Datadog charges the minimum monthly commitment, and for any host hours above that commitment charges an hourly rate [4]. Datadog’s docs state this plan “is well-suited to ephemeral environments, such as autoscaling fleets or short-lived workloads” [4] — because hourly overage tracks bursty infrastructure far more accurately than a monthly peak.
How it differs from fixed fee + overage: the commitment is contractual and typically annual, not a self-serve plan tier. This is a sales-led model; fixed fee + overage is product-led.
9. High-watermark billing
The vendor meters a resource count at intervals and bills on the peak, not the average or the total.
Verified example — Datadog’s high watermark plan (HWMP). Datadog meters host count each hour. At month end it bills on the maximum count of the lower 99% of those hourly readings, excluding the top 1% — explicitly “to reduce the impact of short usage spikes on your bill” [4].
That exclusion detail is the interesting part. A pure peak model punishes a single accidental spike. Datadog discards the top percentile so a one-off burst doesn’t set the month’s price. It’s a deliberate fairness mechanism inside a peak-based model, and almost no pricing guide mentions it.
Where this applies: anything measured as concurrent capacity rather than cumulative consumption — hosts, containers, devices, Fargate tasks. Datadog records unique containers every five minutes and charges on fractional hours of monitored containers [4].
10. Outcome-based
Price tied to a business result rather than a resource consumed.
How it bills: the meter is a result — revenue influenced, spend managed, tasks completed — not an infrastructure unit.
Why it sits in this taxonomy: it is still consumption pricing in mechanics. You meter an event and bill per event. The difference is that the event is defined in the customer’s language rather than yours.
The strategic argument: pricing on outcomes insulates you from the commodity squeeze. If you bill per token, your price falls as token costs fall. If you bill per completed report, your price is anchored to the value of the report.
Two axes that organize all of this
Every model above is a combination of two independent decisions:
Axis 1 — What you meter. Requests, storage, compute hours, active users, sessions, credits, or outcomes. Datadog alone runs several simultaneously: hosts, containers, custom metrics by cardinality, log gigabytes ingested and log events indexed, RUM sessions per thousand, API tests per ten thousand, browser tests per thousand [4].
Axis 2 — How the customer commits. Nothing (pay-as-you-go), a self-serve plan (fixed fee + overage), a contract (committed spend), or a pre-purchase (credits).
Most confusion in pricing conversations comes from conflating these. “Should we go usage-based?” is Axis 1. “Should we require a commitment?” is Axis 2. They’re separate questions, and the nine models are just the common combinations.
A note on billing-plan structure
Datadog offers two billing plans for the same products — HWMP and MHP — and the choice changes which model applies [4]. The pricing unit is identical; the aggregation rule differs.
This is worth copying in your own thinking. The same meter can support multiple commercial models depending on how you aggregate and commit. Changing the aggregation rule is a pricing change that requires no product change.
Fact Check
Vendor pricing and model definitions on this page were verified against the vendor’s own published documentation on 15 October 2026. Vendor pricing changes frequently — treat figures as a snapshot, not a quote.
Verified against vendor sources:
- Stripe’s four recurring pricing models are flat rate, per-seat, tiered, and usage-based — docs.stripe.com/products-prices/pricing-models
- Stripe’s three usage-based sub-models are fixed fee and overage, pay as you go, and credit burndown — same
- Stripe’s Tiered model distinguishes volume-based from graduated pricing — same
- Twilio SMS starts at $0.0083 to send or receive — twilio.com/en-us/pricing, current as of August 2026
- Twilio Voice: $0.0085/min inbound, $0.014/min outbound — twilio.com/en-us/pricing
- Twilio SendGrid Email API: free at 100 emails/day, paid from $19.95/month — twilio.com/en-us/pricing
- Twilio Functions: 10,000 free invocations, then $0.0001/invocation — twilio.com/en-us/pricing
- Twilio Flex and Video: 5,000 hours free, then $1/active user hour or $150/named user/month — twilio.com/en-us/pricing
- Datadog HWMP bills on the maximum of the lower 99% of hourly host readings, excluding the top 1% — docs.datadoghq.com
- Datadog MHP charges a monthly minimum with hourly billing above the commitment — docs.datadoghq.com
- Datadog containers are recorded every five minutes and charged on fractional hours — docs.datadoghq.com
- Datadog Continuous Profiler allows four containers per host free, then $2 per container — docs.datadoghq.com
This page’s own analysis, not sourced claims:
- The “two axes” framing (what you meter × how you commit) — an editorial model for organizing the taxonomy, not vendor terminology.
- The graduated vs volume worked example — illustrative arithmetic using invented rate cards, not vendor pricing.
- The complexity ratings in the comparison table — editorial assessment.
Removed from an earlier version of this page:
- “52% of B2B respondents operate usage or hybrid models” and “46% of SaaS companies use UBP, 15% testing” — the page’s own Sources list contradicted its Fact Check on these figures, and neither could be verified to a primary study.
- “23% higher customer lifetime value” for hybrid pricing — a sibling page in this cluster states 34% for the same claim, and that page’s Fact Check attributes 23% to a different metric entirely.
- “Twilio charges approximately $0.0079 per SMS” — the official page states $0.0083.
- “AWS processes hundreds of billions of usage events monthly” — unsourced.
- “3–5 months of engineering time” — conflicts with 4–8 weeks and 6–12 months elsewhere in this cluster.
- “SaaS companies typically target 70–85% gross margins” and “proration requires two to three engineering sprints” — cited to SEO content sites rather than primary research, and outside this page’s taxonomy scope.
FAQ
What is a consumption-based pricing model?
A structure where the invoice varies with measured usage rather than a fixed subscription fee. Stripe’s billing documentation groups these under “usage-based,” alongside flat rate, per-seat, and tiered models [1].
What are Stripe's three usage-based pricing models?
Fixed fee and overage, pay as you go, and credit burndown [1].
What is the difference between graduated and volume tiered pricing?
Graduated applies each tier’s rate only to the units inside that tier. Volume applies the highest tier reached to all units. Graduated always increases monotonically with usage; volume creates a cliff where more usage can cost less [1].
What is high-watermark billing?
The vendor meters a resource count at intervals and bills on the peak. Datadog’s implementation bills on the maximum of the lower 99% of hourly readings, excluding the top 1% to limit spike impact [4].
What is credit burndown?
The customer purchases a credit balance up front and consumption draws it down. Stripe names it as one of three usage-based models [1]. Common in AI SaaS because it caps customer exposure while preserving per-unit alignment.
Is pay-as-you-go the same as consumption-based pricing?
Yes. Pay-as-you-go is the customer-facing label; consumption-based pricing is the term used in contracts and finance. Twilio’s pricing page leads with “Start for free. Then pay as you go” and describes the same page as “usage-based pricing” [3].
Can one product use several models at once?
Yes, and most large vendors do. Twilio runs pay-as-you-go on SMS and voice, free-allowance-plus-overage on SendGrid and Functions, and per-active-user monthly pricing on Conversations API [3]. Datadog runs host-based, volume-based, and event-count-based units across a single invoice [4].
Sources
- Stripe — Recurring pricing models — https://docs.stripe.com/products-prices/pricing-models
- Stripe — Usage-based billing — https://docs.stripe.com/billing/usage-based
- Twilio Pricing (current as of August 2026) — https://www.twilio.com/en-us/pricing
- Datadog — Billing pricing documentation — https://docs.datadoghq.com/account_management/billing/pricing/
- AWS Pricing — https://aws.amazon.com/pricing/
- OpenAI API Pricing — https://openai.com/api/pricing/
All sources accessed 15 October 2026.