Usage-Based Pricing Examples: 5 Models Explained

Tracking usage, enforcing limits, and handling credits each introduce their own failure points, and they compound fast as you scale.

These five usage-based pricing examples break down what each model actually requires under the hood:

1. AWS: Multi-dimensional metering across independent pipelines
2. Snowflake: Separating compute and storage billing cleanly
3. Twilio: Per-unit pricing with volume tiers and committed-use contracts
4. Supabase: Hybrid subscription plus overage enforcement
5. Relevance AI: Production credit systems for AI workloads

For each one, we cover the infrastructure it depends on and where in-house builds tend to break.

5 usage-based pricing examples: At a glance

1. AWS: Pure consumption across multi-dimensional metrics

AWS charges based on actual resource consumption with no flat fee. Customers pay for compute time, storage volume, data transfer, and access frequency, each measured and billed independently.

Amazon S3 is a clear example. Pricing depends on how much data is stored and how often it is accessed. AWS offers multiple tiers, including S3 Standard for frequent access, S3 Standard-IA for infrequent access at a lower storage cost, and intelligent tiering that adjusts pricing based on observed access patterns.

Infrastructure requirement

Each pricing dimension needs its own metering pipeline. AWS tracks not just what a customer stores, but when and how often they access it. That requires:

• Event-level usage capture across multiple services
• Real-time aggregation across dimensions
• Pricing logic that evaluates multiple signals for a single request

Where it breaks for most teams

Teams usually build metering for one dimension first, then bolt others on later. Each addition feels manageable in isolation, but the pipelines end up inconsistent.

When storage, access frequency, and transfer are tracked separately with no shared attribution layer, small discrepancies across streams compound into billing errors that are hard to trace and harder to explain to customers.

2. Snowflake: Separating compute and storage billing

Snowflake splits billing into two independent metrics. Storage is billed per byte per month, while compute is billed in credits based on usage and plan tier.

This separation allows different usage patterns to be priced correctly. A customer storing large datasets but running few queries pays very differently from one running heavy compute workloads on small data.

Infrastructure requirement

Compute and storage must be tracked independently but resolved under the same customer account. This requires:

• Separate metering pipelines for storage and compute
• Shared customer attribution across both streams
• Independent rate logic applied to each dimension

Usage can spike unpredictably during queries or experimentation. Enforcement needs to happen before usage exceeds limits, not after billing.

Entitlements layer

Snowflake uses credits as prepaid compute capacity, but the system does not just check a balance. It has to resolve multiple inputs before allowing a query to run.

For each request, the system needs to evaluate:

• Current credit balance
• Plan tier and associated rates
• Warehouse size or compute configuration
• Whether sufficient credits remain for the expected workload

This check happens in real time, inside the query execution path. If the system gets it wrong, queries can run without coverage or get blocked incorrectly.

The failure mode is specific to Snowflake's model: a query cannot be paused mid-run because credits ran out. The entitlement check has to be accurate before execution starts, not reconciled afterward.

A wrong decision in either direction is costly. Too permissive and compute spend runs away, too strict and workflows break.

3. Twilio: Per-unit pricing with volume discount tiers

Twilio charges per communication event. This includes each SMS, voice minute, or text-to-speech request. Customers can use pay-as-you-go pricing, volume discounts, or committed-use contracts.

This model works well across both small and large customers. Startups can experiment at low cost, while high-volume users benefit from discounted rates.

Infrastructure requirement

Every event must be captured and priced correctly based on the customer’s contract. This includes:

• Event-level attribution for each message or call
• Rate resolution based on pricing tier
• Tracking cumulative usage within a billing period

The challenge is that pricing is not static. The cost of a single event depends on how much the customer has already used in that billing cycle.

Volume discounts require the system to maintain running totals and adjust pricing as thresholds are crossed. Committed-use contracts go further. The system must first check if usage should be deducted from a prepaid balance before applying standard rates.

What engineers underestimate

Committed-use pricing means a single event cannot be priced in isolation. The correct rate depends on how much the customer has already consumed that cycle and what their contract says at that exact moment.

Engineers tend to build the happy path first: deduct from commitment, then fall back to standard rates. The edge cases come later.

What happens when a commitment expires mid-cycle? When a customer upgrades while a high-volume send is already in progress? Each scenario requires the pricing state to be current and consistent at the time of the request, not eventually caught up.

4. Supabase: Hybrid subscription plus overage

Supabase combines a base subscription with usage-based overages. Customers get a fixed allocation as part of their plan, and any usage beyond that is billed per unit.

This model works well for infrastructure products where teams need predictable baseline costs but still want to scale usage without upgrading immediately.

Infrastructure requirement

Hybrid pricing is not just tracking usage. It is deciding which pricing path applies at any point in time. The system needs to:

• Track usage against included allocation
• Detect when usage crosses the plan threshold
• Switch from included usage to overage pricing without gaps or double counting

Both paths must rely on the same usage source. If they drift, customers either get blocked too early or charged incorrectly. The system also needs to resolve in real time:

• Remaining allocation
• Current usage
• Whether the next request is still included or billable

Entitlements layer

The challenge is not just tracking usage, but resolving state at the boundary. The moment a customer crosses their limit, the system must decide how to handle the next request.

That means the entitlement check needs to return both access and pricing context. It is not just “allowed or blocked.” It is:

• Allowed within plan
• Allowed with overage
• Blocked or requires upgrade

This decision has to stay consistent across backend enforcement and frontend messaging.

Where it gets complex

The trouble starts when customers change plans mid-cycle. Usage is already in progress, the allocation just changed, and the system has to figure out what to do with the gap. A few questions come up immediately:

• Did previous overage get wiped out or does the customer still owe it?
• Where does the new limit kick in, right now or at the next cycle?
• How do you avoid double-counting usage that spans both states?

Throw in legacy plans and custom limits, and the branching paths multiply quickly. None of them are impossible to handle individually, but together they all have to resolve correctly at the boundary, every time.

5. Relevance AI: Dual-meter credit pricing for AI workloads

Relevance AI uses a dual-meter model. Actions count each tool run by an agent. Vendor Credits cover model inference and tool costs, passed through at provider cost with no markup. Customers can top up either meter, or bring their own API keys to bypass Vendor Credits entirely. This is common in AI products where per-request compute costs vary.

Infrastructure requirement

A production credit system is more than a counter. With two meters running in parallel, the system has to handle:

• Block-level expiry for each credit allocation
• Cost basis tracking per credit block
• Separation of paid and promotional credits
• Defined burn order across credit types
• Clear depletion behavior for usage limits
• An append-only ledger for all transactions

Each deduction must be recorded with full traceability for finance and audit purposes.

Where teams fail

Most teams start with a simple counter: deduct on use, top up on purchase. It works fine in early testing.

The problems show up later when a credit block expires and the system has no record of which charges drew from it, or when a promotional credit gets burned before paid credits because nobody defined a burn order, or when finance needs to reconcile revenue and there is no transaction history to work from.

A counter tells you how many credits remain. A ledger tells you everything that happened to get there. You need the second one to run a billing system that holds up under real customer scrutiny and finance audits.

What is usage-based pricing?

Usage-based pricing charges customers based on consumption rather than a fixed fee. The unit varies by API calls, tokens, storage, compute time, and credits.

The implementation challenge is the same across all of them. Engineering teams need to:

• Track usage at the event level
• Attribute it to the right customer
• Keep usage updated in near real time
• Enforce limits before usage gets out of control

Billing systems generate invoices after usage happens, so the enforcement logic has to live elsewhere, in a separate layer that combines usage data, plan limits, and current state to make decisions at request time. Mid-cycle plan changes, retries, and partial failures all run through that same layer without breaking accuracy.

The infrastructure layer usage-based pricing requires

Across all these usage-based pricing examples, the same gap shows up. Billing systems handle invoices and payments, but they do not control what happens during a request.

Miro's in-house system made every plan update a multi-week cross-functional effort. With Stigg, Miro shipped a full AI credit model with enforcement, automatic resets, and seat-scaled allocations in under 6 weeks.

This logic runs inside the request path. Before executing a request, the system needs to resolve access and limits. Entitlements handle this by combining plan configuration, add-ons, trials, and promotions into a single runtime decision.

Each request triggers a check that returns:

• Access status, meaning whether the request can proceed
• Usage limit, the cap derived from the resolved entitlement
• Current usage, consumption recorded in the current period
• Unlimited flag, indicating whether the entitlement is uncapped

This response drives both sides of the system. The backend uses it to allow or block requests. The frontend uses it to show limits, usage, and upgrade states.

What engineering teams need to get right

Across all five models, the failure point is the same: enforcement that runs after usage has already happened. Stigg is the usage runtime that moves decisions into the request path, resolving entitlements, credits, and spend limits before compute runs.

For teams who recognize the pattern:

• Entitlement checks run from a local Sidecar cache. Cache hits resolve immediately, and cache misses fall back to Stigg's Edge API at around 100ms, with a configurable timeout to keep upstream latency out of the request path.
• Credit ledger tracks every deduction against the correct block, with burn order, expiry, and concurrent write safety built in from the start
• Budget controls apply independently at the user, agent, team, and org level, so enterprise hierarchy requirements don't require a data model rewrite
• BYOC Sidecar runs inside your own VPC, keeping enforcement live during upstream interruptions with no external data dependency
• Sits above your existing billing stack and syncs usage events to Stripe or any existing provider without touching payment infrastructure

If you only need the credit ledger or entitlement enforcement layer, you can adopt either component independently with no requirement to use the full stack.

Getting this layer right before the first enterprise deal or the first overage incident is the cheaper path. See how Stigg approaches the runtime layer and fits into each of these pricing models.

FAQs

1. When should a company use usage-based pricing?

Companies should use usage-based pricing when product value scales with consumption, such as API calls, compute, or storage. It works best when usage is measurable, variable, and directly tied to customer outcomes.

2. Is usage-based pricing better than subscription pricing?

The main difference between usage-based pricing and subscription pricing is flexibility. Usage-based pricing adapts to actual consumption, while subscription pricing provides predictable costs. Many SaaS companies combine both to balance flexibility and stability.

3. What are the risks of usage-based pricing?

Usage-based pricing can lead to unpredictable costs, billing disputes, and engineering complexity if usage is not tracked or enforced correctly. Without real-time enforcement, systems can allow overuse that only shows up after billing.

4. How do you prevent overages in usage-based pricing?

You prevent overages by enforcing limits in real time during the request, not after billing. This requires tracking current usage, resolving entitlements, and blocking or flagging requests before limits are exceeded.

5. How does credit-based pricing work in SaaS?

Credit-based pricing works by requiring customers to prepay for usage and then deducting from that balance as they use the product. It is commonly used in AI products where costs vary per request and need upfront control.