Usage-Based Pricing: How to Price SaaS by Consumption

Choosing a consumption metric is a pricing decision disguised as a technical one. Two AI products can meter the identical workload and end up with unit prices 30x apart, because one charged for the resource it consumed and the other charged for the result its customer received.

This guide covers the pricing side: how to pick the metric, how to set the rate, where the cost floor actually sits, and which guardrails keep a consumption model from collapsing into bill shock. The engineering mechanics are covered separately in Usage-Based Billing: How It Works.

The one decision that determines everything: what do you count?

Your consumption metric does three jobs at once. It has to correlate with the value your customer receives, be measurable accurately enough to survive a billing dispute, and be legible to someone reading an invoice at month-end.

A metric that satisfies only the first two produces accurate bills customers resent. A metric that satisfies only the first and third produces resentment you can’t audit.

Test your metric against four questions:

  1. If a customer uses twice as much, do they genuinely get twice as much value?
  2. Can you defend a line item on this metric to a customer who didn’t generate it deliberately — a retry loop, a runaway script, a background job?
  3. Can the customer predict next month’s bill from this number?
  4. Does the metric survive a change in your implementation? If you migrate to cheaper hardware, does your price become indefensible?

That last one is where most founders get caught, and it’s the reason the next section matters.

"Per image" is not a price

It’s tempting to price the output artifact: per image, per report, per API call. The problem is that the same artifact can cost you wildly different amounts to produce.

Replicate’s published pricing makes this concrete. It bills most public models by the time they take to run, with the rate set by the hardware in use [2]:

Hardware

Price per second

Price per hour

CPU (small)

$0.000025
$0.09

CPU

$0.000100
$0.36

Nvidia T4

$0.000225
$0.81

Nvidia L40S

$0.000975
$3.51

Nvidia A100 (80GB)

$0.001400
$5.04

Nvidia H100

$0.001525
$5.49

A workload on an H100 costs 61x the same workload on a small CPU [2]. If you priced “per generation” at a single rate, your margin depends entirely on which hardware the job lands on.

The same distortion appears in output-based pricing. On Replicate, one output image costs $0.003 on flux-schnell, $0.025 on flux-dev, $0.04 on flux-1.1-pro and recraft-v3, and $0.09 on ideogram-v3-quality [2]. That’s a 30x spread on what the invoice would call the same unit.

Video shows it most cleanly: the same model family prices at $0.09 per second of output at 480p and $0.25 per second at 720p [2]. Resolution is the only variable.

The pricing implication: if you meter outputs, you must either price by variant — which is honest, and what Replicate does — or price a blended average, which quietly cross-subsidizes your heaviest workloads.

Find your cost floor before setting a price

Your floor is marginal cost per unit, and it is rarely the number founders assume.

For an AI product, marginal cost includes the model inference, the infrastructure around it, and the support burden the usage generates. Replicate’s private models illustrate the support-cost problem: unlike public models, most private deployments run on dedicated hardware, so you pay for setup time, idle time waiting for requests, and active processing time — not just the work itself [2]. Idle capacity is a real cost that a naive per-request price ignores entirely.

Two structural details worth pricing deliberately:

  • Idle and cold-start exposure. Replicate bills setup and idle time for most private models, with an exception for “fast booting fine-tunes,” which bill only active processing time [2]. If your product runs dedicated capacity per customer, idle time belongs in your cost model.
  • Committed capacity is priced differently. Replicate lists multi-GPU configurations — 4x, 8x A100, H100 and H200 — as available through committed spend contracts rather than on-demand rates [2]. Volume commitments change your floor, which means they should change your customer-facing price too.

Price to value, not cost-plus

Cost-plus pricing on a consumption metric caps your margin at whatever you negotiated with your infrastructure provider. Value-based pricing sets the rate against what the unit is worth to the customer.

Worked example:

Suppose your product generates competitive-analysis reports, each consuming roughly 200,000 input tokens and 20,000 output tokens. Using Replicate’s deepseek-r1 rates as a stand-in — $3.75 per million input tokens and $0.01 per thousand output tokens [2] — the model cost is approximately:

input: 0.2M × $3.75/M = $0.75 output: 20K × $0.01/1K = $0.20 model cost per report ≈ $0.95

Add infrastructure, retries, and support overhead and your floor might be $1.25 per report.

Now price it. If an analyst spends 90 minutes producing that report manually at $60/hour, the report is worth roughly $90 in labor. Charging $1.50 is not conservative — it’s leaving 98% of the captured value on the table, while exposing you to the full volatility of your inference costs.

A defensible range here starts around $5–$15 per report. Your floor protects margin; your customer’s alternative sets the ceiling.

The trap to avoid: passing upstream token costs through 1:1 positions you as a commodity reseller. Your customers will find the cheaper wrapper. Price the outcome, and let the token cost sit inside your margin where you can absorb or optimize it.

Four pricing structures, and when each fits

1. Pure pay-per-use. No base fee, no commitment. Fits when your buyer is technical, expects metered billing, and can monitor spend programmatically. Twilio’s positioning is exactly this: “Start for free. Then pay as you go,” with volume discounts unlocked as you scale [1].

2. Free tier plus paid floor. The dominant pattern in developer tools. Twilio’s SendGrid Email API starts free at 100 emails/day, with paid plans from $19.95/month [1]. Functions start with 10,000 free invocations, then $0.0001 per invocation [1]. TaskRouter gives away the first 100 tasks each month, then $0.06 per task [1]. The free tier is an acquisition cost; the paid floor protects you from customers who consume near-zero but still cost you to serve.

3. Metered plus named-seat, offered side by side. This is the most underused structure and the most instructive. Twilio prices both Flex and Video at 5,000 free hours, then $1 per active user hour or $150 per named user per month [1] — the same product, two pricing models, customer’s choice.

The breakeven is arithmetic: $150 ÷ $1/hour = 150 hours per month, or roughly seven hours a day. Light users pick metering and pay less. Heavy users pick the named seat and get budget certainty. You capture both segments without custom negotiation.

4. Hybrid: base subscription plus overage. A base fee covering an included allowance, with per-unit charges beyond it. This is the right default for most early-stage SaaS, because it gives a finance team something to approve while preserving expansion revenue.

Designing volume tiers

Twilio’s model is instructive here: volume discounts are published as a standard part of the offer rather than negotiated per deal [1]. Tiered rates give you three things at once — they reward growth without capping it, they replace bespoke enterprise pricing with a published structure your sales team can defend, and they let a customer self-select into a higher commitment.

Keep tiers coarse. Three to four bands is enough. More than that and the invoice becomes unreadable, which defeats the transparency that makes consumption pricing acceptable to buyers in the first place.

Guardrails that prevent bill shock

Bill shock is the primary failure mode of consumption pricing, and it is solvable with structure rather than goodwill.

  • Minimum commitment. A floor — even $20/month — prevents a customer using two units a month from consuming more in support cost than they pay.
  • Customer-set caps. Let buyers set a maximum spend. This converts your largest source of disputes into a feature they control.
  • Progressive alerts. Notify at 50%, 80%, and 100% of quota. Alerts at a single threshold arrive too late to act on.
  • Legible invoices. Line items showing included usage, overage usage, and the rate applied. An invoice that says “$2,000 — usage” generates a support ticket; one that itemizes generates a payment.

Common pricing mistakes

Pricing the resource instead of the result. Charging per token when your customer bought an answer. You inherit your supplier’s cost volatility and capture none of your own value.

Assuming one unit, one cost. As the hardware table above shows, the same output can cost 30x more to produce depending on model and configuration [2]. A single blended rate is a bet that your workload mix stays constant.

Ignoring idle and setup cost. If you run dedicated capacity, you pay for time the customer isn’t using you [2]. Price it or restructure it.

No floor. Pure pay-per-use with no minimum attracts customers who cost more to serve than they pay.

Copying AWS. AWS can price pure consumption because it has scale, hundreds of services, and committed-spend products layered on top. A 12-person SaaS company copying the structure without the scale gets revenue whiplash.

Fact Check

Claims on this page were verified against vendor pricing pages on 15 October 2026. Vendor pricing changes frequently — treat figures as a snapshot, not a quote.

Verified against vendor sources:

  • Twilio SMS $0.0083 to send or receive — twilio.com/en-us/pricing
  • Twilio Voice $0.0085/min received, $0.014/min to make a call — same
  • SendGrid Email API free at 100 emails/day, paid from $19.95/month — same
  • Twilio Functions 10,000 free invocations, then $0.0001 each — same
  • TaskRouter first 100 tasks/month free, then $0.06/task — same
  • Twilio Flex and Video: 5,000 free hours, then $1/active user hour or $150/named user/month — same
  • Twilio volume discounts available as you scale — same
  • Replicate bills most public models by run time, rate varies by hardware — replicate.com/pricing
  • Replicate hardware rates from $0.000025/sec (CPU small) to $0.001525/sec (H100) — same
  • Replicate per-image rates: $0.003 (flux-schnell, $3.00/1,000 images) to $0.09 (ideogram-v3-quality) — same
  • Replicate video: $0.09/sec at 480p, $0.25/sec at 720p — same
  • Replicate deepseek-r1: $3.75/million input tokens, $0.01/thousand output tokens — same
  • Replicate private models bill setup, idle, and active time on dedicated hardware; fast booting fine-tunes bill active time only — same
  • Multi-GPU capacity available via committed spend contracts — same

Derived, not quoted:

  • Report cost floor of ~$0.95 and the $150 ÷ $1 = 150-hour breakeven — arithmetic performed on the vendor figures above, not stated by the vendors.

Removed from the previous version of this page:

  • SendGrid overage fees of $0.50–$1.30 per 1,000 emails — not present on the cited pricing page.
  • Replicate range of “$0.01–0.015 per 1K LLM tokens” — only $0.01 per thousand output tokens is published; the $0.015 figure and the input/output conflation are unsupported.
  • All Stripe metering claims — the previously cited URL returned “Page not found.” This page makes no Stripe claims.

FAQ

What is usage-based pricing?

A model where customers pay according to how much of your product they consume — per API call, per GB stored, per message sent — rather than a fixed recurring fee. Also called consumption pricing or metered billing.

They describe the same mechanic. “Usage-based” usually refers to activity inside a SaaS product; “consumption-based” more often describes infrastructure-level resources. The distinction is semantic.

Establish your marginal cost per unit including infrastructure, retries, idle capacity, and support. Then price against the customer’s alternative — what the outcome is worth to them — not against your cost plus a markup.

Price by whichever unit the customer recognizes as value, and make sure that unit’s cost to you is stable enough to defend. If it isn’t, price by variant rather than blending.

Hybrid: a base subscription covering an included allowance, with metered overage beyond it. It gives buyers budget predictability while preserving expansion revenue.

Yes, and offering them side by side lets customers self-select. Twilio prices Flex and Video at either $1 per active user hour or $150 per named user per month [1].

They matter as a published structure rather than a discount. A tier rate card replaces per-deal negotiation and lets customers grow into higher commitments without a sales cycle.

Sources

  1. Twilio Pricing (current as of August 2026) — https://www.twilio.com/en-us/pricing
  2. Replicate Pricing — https://replicate.com/pricing
  3. Stripe — The Meter object (API reference) — https://docs.stripe.com/api/billing/meter

    4. All sources accessed 15 October 2026.