What is usage-based billing?
Usage-based billing charges customers for what they actually consume — API calls, compute time, tokens, gigabytes — instead of a flat fee that’s the same whether they barely touch the product or run it hard all month. It’s the default model for infrastructure, API, and AI products, because it ties what a customer pays directly to the value or cost tied to their usage.
How usage-based billing works
Every usage-based system runs the same basic pipeline, whether it’s built in-house or bought:
A single unit of usage — an API call, a token — is captured the moment it happens.
Events aggregate into running totals per customer, deduplicated so retries aren't double-billed.
A rate — flat, tiered, or credit-based — applies to the metered total per the current plan.
An invoice generates, or a prepaid wallet balance updates, reflecting exactly what was consumed.
The step that’s easy to underestimate is the second one. A usage event carries an idempotency key so a retried delivery is recognized and dropped rather than counted twice, and lands in an append-only ledger rather than a counter that can silently drift out of sync with reality. See metering for how that’s implemented.
Usage-based vs. subscription vs. hybrid pricing
| Subscription | Pure usage-based | Hybrid | |
|---|---|---|---|
| What sets the price | A fixed recurring fee, regardless of usage | Metered consumption — tokens, calls, compute | A base fee plus metered usage beyond an allowance |
| Revenue predictability | High — same number every period | Low — scales with customer activity, can vary widely | Moderate — a predictable floor, variable upside |
| Alignment to customer value | Weak — a light user and a heavy user pay the same | Strong — pay scales with what's actually consumed | Strong above the allowance, flat below it |
| Buyer's ability to budget | Easy — known cost in advance | Hard — the bill isn't known until usage happens | Moderate — capped downside, open-ended upside |
| Billing infrastructure required | Simple — recurring charge scheduler | Complex — real-time metering, idempotent ledger | Complex — subscription logic plus a metering ledger |
| Typical fit | Seat-driven tools with stable per-user value | Infrastructure, API, and AI/inference products | Most usage-based products once they scale past early customers |
Most usage-based products don’t stay in the “pure usage-based” column for long — they add a base fee once they have enough data on typical usage to price an allowance around it.
Common usage-based pricing structures
The rate drops at defined volume thresholds — a lower per-unit price after the first N units.
Credits / prepaid wallets →A customer buys a balance upfront that usage burns down, rather than an invoice after the fact.
Commit + overage →A minimum committed volume at a discount, with usage beyond it billed separately, often at a higher rate.
Per-unit / pay-as-you-go →A flat rate per unit consumed, with no base fee or allowance — the simplest and most cost-aligned structure.
The billing infrastructure usage-based pricing requires
Choosing a usage-based model is a pricing decision. Making it real is an infrastructure problem, and it’s usually bigger than teams expect on the first pass:
- ✓Real-time event ingestion — see metering.
- ✓An append-only ledger so totals are computed from real history, not a drifting counter — see ledger.
- ✓A prepaid wallet or invoicing flow depending on the pricing model chosen — see wallets & invoicing.
- ✓Entitlement checks that stay in sync with live usage and balance, not a nightly batch job — see entitlements.
- ✓A pricing engine that can change rates and tiers without an engineering deploy — see pricing engine.
Who uses usage-based billing
The categories where usage-based pricing has become the default rather than the exception share one trait: the seller’s own cost scales meaningfully with how much a customer uses the product. Cloud infrastructure (compute, storage, bandwidth) was the earliest large-scale adopter. Developer-facing APIs followed, since a call to an API has a directly attributable cost. AI and inference products are the newest and fastest-growing category, because token and compute costs are inherently usage-shaped in a way flat per-seat pricing was never designed to capture.
How to implement usage-based billing
Two paths, and the choice usually comes down to how much of the metering-ledger-wallet-entitlements stack you want to own as engineering surface area versus configuration.
Building it means owning idempotent ingestion, an append-only ledger, late-event handling, wallet balance tracking, and entitlement checks — each solvable individually, but together a meaningful, ongoing engineering commitment as pricing models change. Buying itmeans configuring that same stack instead of building it, at the cost of some flexibility for speed and reliability that’s already been proven at scale. For a deeper look at what building this yourself actually involves, see billing for AI companies.
FAQ
What is usage-based billing?
Usage-based billing is a pricing model that charges customers for what they actually consume — API calls, compute time, tokens processed, gigabytes transferred — instead of a flat recurring fee that stays the same whether a customer barely touches the product or runs it hard all month. It's the default model for infrastructure, API, and increasingly AI products, because it ties what a customer pays directly to the value or cost associated with their usage. In practice it's rarely pure metering — most companies run a hybrid, combining a base subscription with metered usage on top.
Is usage-based billing the same as pay-as-you-go?
They overlap but aren't identical. Pay-as-you-go usually implies no base fee at all — you pay only for what you use, from zero. Usage-based billing is the broader category: it includes pure pay-as-you-go, but also covers hybrid models where a base subscription includes an allowance and only usage beyond that allowance is metered. Most products marketed as "usage-based" today are actually this hybrid shape rather than pure pay-as-you-go.
What's the difference between usage-based pricing and the billing system underneath it?
Pricing is a business decision: what to charge for, and how — per token, per seat, per API call, in tiers or flat. Billing is the system that makes that decision real: measuring usage accurately in real time, applying the right rate, and producing an invoice or updating a wallet balance that a customer and your finance team can both trust. A company can pick the right pricing model and still fail if the metering and billing infrastructure underneath it can't be trusted — a ledger that double-counts retries or drops late events produces a wrong invoice regardless of how well the pricing tiers are designed.
What infrastructure does usage-based billing actually require?
At minimum: an event-ingestion pipeline that captures usage the moment it happens; an idempotency mechanism so a retried delivery isn't billed twice; an append-only ledger so totals are computed from real event history rather than a counter that can silently drift; a tolerance window for events that arrive late; and either an invoicing flow or a prepaid wallet with real-time balance tracking, depending on the pricing model chosen. Entitlement checks — whether a customer is currently allowed to use a feature, based on their live balance or plan — are usually needed too, since access and billing need to stay in sync without a separate manual reconciliation step.
Why do some usage-based products use prepaid credits instead of an invoice at the end of the month?
A prepaid credit wallet gives the customer a visible, self-imposed spending cap and gives the seller revenue up front rather than billing after costs have already been incurred. It's especially common where usage is bursty or hard to predict — a customer would rather fund a wallet they control than receive an open-ended invoice that could land anywhere. The tradeoff is that a wallet needs real-time balance tracking and a top-up flow; without one, a balance hitting zero mid-task becomes a service interruption instead of a billing event.
How do I decide between subscription, usage-based, and hybrid pricing?
Start from how directly your costs and value scale with usage. If a customer's use of your product costs you roughly the same regardless of how often they use it (most traditional software), subscription pricing is simpler and easier to sell. If your infrastructure cost scales meaningfully with usage — as it typically does for AI, API, and data-infrastructure products — pure or hybrid usage-based pricing keeps your margin aligned as customers scale. Most companies that start on a flat plan and later see usage vary widely across accounts end up adding a usage component rather than staying purely flat.