Usage-Based Pricing 101
A complete breakdown of usage-based pricing — the models, the mechanics, and how to tell if it's the right fit for your product.
What is usage-based pricing?
Usage-based pricing charges customers for what they actually consume, not a fixed amount every month. Some teams call it consumption-based pricing — same model, different name — and it has become the default way SaaS and AI companies price anything with a variable cost to serve.
What counts as "usage" depends on the product. It might be an API call, a token if the product runs AI features, a transaction like a payment or a message, or any other unit that maps to real value delivered. Whatever the unit is, the bill just follows it around: use more, pay more; use less, pay less.
For the full mechanics of usage-based billing end to end — metering, rating, invoicing, and revenue recognition — see the complete usage-based billing guide.
- API calls — each request made to a service endpoint
- Tokens — the units an AI model consumes per request
- Transactions — a payment, a message, or any other completed action
What are the different usage-based pricing models?
There's no single way to run usage-based pricing. Most companies land on whichever structure matches how their customers derive value — and plenty combine more than one.
Pay-as-you-go is the simplest version: a flat rate per unit, no minimum, no commitment. Tiered pricing works the same way but rewards volume, so the more a customer uses, the cheaper each additional unit gets. Credit and token-based pricing has customers buy a pool upfront and draw it down as they go — the default structure for AI products, since inference cost is so variable. Overage pricing bundles an allowance into a plan and charges per unit once a customer goes past it, often alongside add-on allowance packs customers can buy before they hit that ceiling. And hybrid pricing blends a subscription base with usage stacked on top.
Most companies don't stop at one model. They land on hybrid — seats plus usage — because it keeps the predictability of a subscription while still capturing the upside as customers grow.
- Pay-as-you-go — a flat rate per unit, no minimum
- Tiered — a volume discount built in, so cost per unit drops as usage grows
- Credit and token-based — a pre-purchased pool customers draw down, standard for AI products
- Overage — an included allowance, then per-unit charges (or add-on packs) above it
- Hybrid — a subscription base with usage stacked on top
Why do companies switch to usage-based pricing — and what does it take to get right?
The appeal is straightforward: pricing that tracks the value a customer actually gets, instead of a number set once and left alone. But the part that gets glossed over is that usage-based pricing isn't technically easy — it asks more of your metering and billing infrastructure than a flat subscription ever did.
| Why teams switch |
|---|
Lower barrier to entry — nobody has to commit to much just to try you out |
Built-in expansion revenue — the bill grows with usage, with no upsell campaign required |
Higher customer trust — nobody feels they're paying for something they're not using |
| What it takes to get right |
|---|
Every usage event has to be captured accurately, or you're bleeding margin without knowing it |
Multi-seat accounts need usage attributed to the individual user, not just the account |
Feature access has to check entitlements in real time, not on a batch delay |
Billing gets more complex — tiers, proration, sometimes multiple currencies |
Is usage-based pricing right for your product?
Honestly, it's less an industry question than a fit question. Three things decide it.
First, does the value your product delivers actually grow the more someone uses it? Second, can you measure that usage accurately in real time, not just tally it up at the end of the month? And third, how do you want the pricing itself to work — most teams end up picturing a pricing page with plans built around different usage limits, which means deciding what those limits should be for each feature worth metering.
The fit test isn't your industry. It's whether value and usage move together inside your product.
- Does value scale with usage, not just with seats?
- Can usage be measured accurately, in real time?
- What usage limits will each plan and feature actually need?
What are some real-world examples of usage-based pricing?
Most people have already used a product priced this way without thinking about it.
Snowflake charges per compute credit — customers pay for the queries they actually run, not for capacity sitting idle. AWS basically invented the cloud version of this, metering compute hours, storage, and data transfer down to the unit. Datadog bills on hosts monitored and logs ingested, so cost scales with a customer's infrastructure footprint. Twilio charges per SMS sent, voice minute, or API call — communication treated as a metered utility. And OpenAI and Anthropic bill per token, the model behind most of the AI tools in use today.
Any product shipping its own AI-driven features runs into the same math: token consumption costs scale with usage, and passing that through with usage-based pricing of your own is the natural fit.
How does usage-based pricing actually work?
Under the hood, it comes down to three steps. Every billable action gets captured the instant it happens — that's the event. A rating engine applies pricing logic to it — per unit, in tiers, against credits, however the model is configured. And billing turns that rated usage into an actual invoice, synced to whatever billing system is already running.
That pipeline — metering, rating, billing — is what Nalpeiron's Monetization Engine (Zenmeter) handles end to end, already processing 300M+ transactions a month across customers running exactly this flow. It works alongside Licensing & Entitlements when a plan needs seats and usage living together.
See the full breakdown of every usage-based pricing model on the Zenmeter usage-based pricing hub, or book a demo to see the Monetization Engine running against your own pricing model.
Video transcript
Auto-generated from the video and lightly edited for readability.
You know that customer who corners your sales team every quarter and asks why they're paying full price for a product they only use so much of?
Yeah — that conversation is the reason usage-based pricing exists, so that pricing can be linked to what's used, and therefore linked to the value delivered to the customer.
Here's what usage-based pricing actually means stripped down.
Instead of one flat number every month, you pay for what you actually use. Some people call it consumption-based pricing — same thing, different label.
What "use" means depends on your product, it could be an API call, a token if you're doing anything with AI, or a transaction — a payment, a message, whatever the real unit of value is.
A usage-based pricing bill just follows that unit around.
There's more than one way to actually structure this, so let's run through some options.
Pay as you go. This is the simplest version: a flat rate per unit, no minimum, no strings attached.
Tiered pricing is basically the same but with a volume discount built in, so the more you use, the cheaper each unit gets.
Credit and token-based pricing has customers buy a pool upfront and burn through it — pretty much the default for AI products right now.
Overage gives you an allowance built into your plan, then charges per unit once you go over it. Of course, the other common way of dealing with overages is to offer add-on allowances that customers can buy when they hit the usage limit of their particular plan.
And hybrid blends a subscription with usage stacked on top.
Most companies need to blend the way they price and package their products, in a hybrid way, with a seats plus usage approach. Why? Because it gives them the predictability of a subscription and the upsides of usage-based at the same time.
So why do companies actually make the switch to usage based? A few reasons keep coming up.
It lowers the barrier to entry — nobody has to commit to much in the way of costs just to try you out.
It builds in its own expansion revenue too: when a customer's usage grows, their bill grows with it, and nobody had to run an upsell campaign to expand that account.
And customers tend to trust it more, because they're rarely paying for something they're not using.
But — and this is the part people gloss over — it isn't technically easy.
Every single usage event has to be captured accurately, or you're quietly bleeding margin without knowing it.
Multi-user business accounts need precise usage attribution down to each individual user, to gather the whole picture of usage across a company.
Access control to the features being metered needs to take place in real time, referencing a system that knows if the user still is within their usage limit allowances.
And billing itself gets more complicated: tiers, proration, sometimes multiple currencies, all of this has to work, every time.
So — is usage based pricing actually right for you? Honestly, it's less an industry question and more a fit question.
Does the value your product delivers actually grow the more someone uses it?
Can you measure that usage accurately, in real time — not just tally it up at the end of the month?
And how will you want your pricing to work? You might have already imagined a pricing page offering plans for your product that include different usage limits, and you'll need to think about what those limits would be for each of the different features you'd want to meter.
The fit test isn't your industry. It's whether value and usage can move together inside your product.
You've probably already used a product built this way without thinking about it.
Snowflake charges per compute credit — you're paying for the queries you actually run, not for capacity sitting idle.
AWS basically invented the cloud version of this: compute hours, storage, data transfer, all metered down to the unit.
And OpenAI and Anthropic bill per token, which is exactly the model behind most of the AI tools you're using right now.
Perhaps you're releasing, or have already released AI-driven features within your own product. This is a prime example of where the high token consumption costs you're incurring need to be passed on to the customer, and doing this with usage-based pricing of your own is of course a natural fit.
Okay, so how does this actually work under the hood? Three steps, really.
Every billable action gets captured the instant it happens — that's the event.
A rating engine then applies your pricing logic to it: per unit, in tiers, against credits, however your model works.
And billing takes that rated usage and turns it into an actual invoice, connected with whatever billing system you're already running.
That whole pipeline — metering, rating, billing — is what our monetization engine Zenmeter handles end to end. It works alongside our licensing when you need seats and usage living in the same plan.
If you want the deep-dive version of all this you can read more on our website.
Or if you'd rather just see our Monetization Engine in action, and how it can work for your business specifically, go to nalpeiron.com and book a demo for you and your team today.
Decouple your
monetization today
Join the enterprises scaling their revenue without rebuilding their stack every year.
Unleash the monetization potential of your software / SaaS / Hardware