What usage-based billing is (the pricing model)

Usage-based billing charges customers for what they actually consume instead of a fixed fee. 

You'll also see it called consumption-based pricing, the term most enterprise and cloud vendors prefer, and pay-as-you-go billing, the label AWS made famous. Same idea, different names.

Most usage-based pricing models fall into four shapes. Let me define each with a real number:

• Per-unit: a flat rate on every unit. Cursor's Auto mode charges about $6 per million output tokens.

• Tiered: the rate changes once you cross a threshold, so the first 1,000 units cost one price and the next 10,000 cost less.

• Volume: cross a tier and your whole bill re-prices at the new rate, every unit, even the ones you'd already used.

• Overage: a flat allowance, then a metered rate for anything past it. You get 10,000 calls included, then pay per call after.

The one that causes the most billing disputes is volume pricing, because customers rarely expect their entire bill to re-rate the moment they cross a threshold. That surprise lands on an invoice, and that's a conversation nobody enjoys having.

How metered billing and usage-based billing work together

Neither layer produces revenue alone. Usage-based billing is the decision to charge for consumption, and metered billing measures that consumption and turns it into an invoice. One can't work without the other, which is a big part of why people conflate them.

The distinction that actually decides your architecture

The same usage-based price can run on two completely different systems, and this is the part no explainer spells out.

• The first is a post-hoc tally. You measure usage as it happens, add it up, and bill at the end of the month. Simple, and fine when the stakes are low.

• The second checks a balance in real time, before each request runs. This is where Credits and Wallets come in. The system looks at a customer's remaining balance and decides whether the next expensive call is allowed, instead of tallying quietly and hoping the month-end invoice lands.

Same $0.05-per-minute price. Two entirely different architectures underneath.

Why does the second one matter? I thought you'd never ask. Because at AI and API scale, a single runaway job can burn serious cost before any invoice exists. A developer on r/microsaas put the failure plainly: with invoice-based metering, one heavy user can run up a month of inference before you ever send them a bill. If you're billing AI usage, a post-hoc tally charges the same rate as the real-time engine but behaves nothing like it under pressure.

This is also where hybrid billing lives. Combining a subscription base, metered usage, and credits on a single invoice is what Billing and Invoicing handles, and it leans on both layers working cleanly. We've covered hybrid pricing separately.

I'll be honest about the messy part. Most teams don't discover which implementation they needed until the wrong one has already burned them.

Where usage-based billing actually breaks, the metering layer

Billing errors in a usage-based model almost always start in the metering layer, not the pricing configuration. When an invoice comes out wrong, the instinct is to check the pricing rules. 

Almost every time, that's the wrong place to look. The bug is upstream, in the layer that captures and counts events.

Here are the failure modes I see break teams, and what stops each one:

• Duplicate events. Networks retry and SDKs retry, so the same event often arrives twice. Idempotency means the system counts it once no matter how many times it shows up. Without it, every retry becomes a double charge. Flexprice handles this with exactly-once delivery.

• Event loss under load. When traffic spikes, weak pipelines drop events, and every dropped event is revenue you'll never invoice. Auto reconciliation catches the gaps instead of letting them vanish silently.

• No visibility. If you can't see what got ingested, you can't debug a wrong invoice. The built-in event debugger shows every event that came in, so you're not guessing.

• Dashboard lag. If your usage dashboard runs hours behind reality, customers hit limits they can't see coming. Real-time aggregation keeps the number current.

Underneath all of this is the metering engine itself, Flexprice's Usage Metering and Entitlements, running on a Go and Kafka setup at 60,000+ events per second with under 60ms P99 latency.

P99 just means 99 out of every 100 events get processed in under 60 milliseconds. That speed is the part that makes "measure it before the request" possible rather than aspirational.

CASParser felt this directly. Their AWS API Gateway metering lagged 15 to 30 minutes for large accounts, which meant quotas updated too late to be useful. After moving to Flexprice, that lag dropped to near-zero. 

As founder Sameer Kumar put it: "It just magically works behind the scenes. There's almost negligible lag around updation of the quotas."

An engineer on r/SaaS described the same class of problem from the inside: the hard part is deciding when something "counts" as a billable event, and idempotency windows that let partial runs and retries double-count. That's a metering problem. No amount of pricing configuration fixes it, and it's almost impressive how consistently teams audit the pricing rules first anyway.

So the practical takeaway is this. Before you finalize a pricing model, ask whether your metering layer can execute it at your event volume, with your accuracy requirement. Verify the measurement first. Design the price second.

What metering looks like for an AI product

For an AI product, metering has to do more than count. It has to know which model ran, what that model costs, and whether the customer can afford the next call before it fires.

Token metering per model is the base. A request to a larger model costs more to serve than a smaller one, so a flat per-token rate across all of them either loses you money on the big models or overcharges on the small ones. You meter per model so the rate matches the real cost.

Per-model cost tracking is the next layer. It's the difference between knowing your revenue and knowing your margin, per model, per customer. Plenty of AI teams find out too late that their most active customer is also their least profitable.

Then there's real-time credit gating, checking a balance before an expensive inference call rather than after. That shift from "count it later" to "check it before the call" is the real dividing line for AI billing, and it's exactly the real-time implementation I described earlier.

Segwise learned where that line sits. They spent three weeks trying to build credit-based pricing in-house, then shipped it in three days with Flexprice, and now track 100+ enterprise customers with zero engineers dedicated to credit infrastructure. 

Founding engineer Kush Daga said it plainly: "Our core product is not credits. We build creative analysis and generation technology, not billing infrastructure, and that is where my focus needs to be."

Should you build or buy your metering layer?

The metered-versus-usage-based question is really a build-or-buy decision about your metering layer. Once you accept that metering is the hard part, the next question is whether you build that measurement engine or buy it.

Here's the rough test I'd apply. Build if your event volume is low, your pricing is simple, and a small counting error won't hurt you. Buy if you're metering AI or API usage at scale, iterating on pricing regularly, and can't afford silent leakage on every invoice.

The build path costs more than it looks, and the cost is mostly maintenance. Simplismart spent 1.5 to 2 months building a metering engine on top of an open-source tool, lost 20 to 30% of a developer's daily bandwidth keeping it alive, and still watched it break under load. After switching to Flexprice, they got back 30% of their engineering bandwidth. 

Head of Engineering Shubhendu Shishir was blunt about it: "When we started building our own billing engine on top of Lago, it took us around 1.5 to 2 months to build something which is not something you would like to build."

So sequence the decision correctly. Design the pricing model you want, then confirm your metering layer can actually execute it before you commit to charging customers on it.

Is metered billing outdated? No, and here's where that myth comes from

Metered billing isn't outdated. It's the live measurement layer under every usage-based model, including the newest AI token pricing, and it's doing more work now than it ever has.

The "metered billing is old and low-volume" idea has a specific origin, and it's worth naming. It comes from billing vendors describing their own legacy metering features that way, in their product docs, to steer existing users toward a newer product. 

That's product-marketing language for a deprecated feature, and it got repeated online often enough that AI Overviews now present it as a neutral definition.

It's a little galling, honestly. One vendor's decision to sunset an old feature turned into a "fact" about an entire category. Metering didn't get old. One product did.

The distinction that decides whether your billing survives

Metered billing measures, usage-based billing prices, and the implementation you pick underneath decides whether either one survives contact with real AI traffic. 

A post-hoc tally holds up until a runaway job or a dropped event turns into a wrong invoice. A real-time measurement engine is what holds up when the stakes are high. 

If you're running usage-based pricing and want the real-time version rather than a month-end guess, you can start free with Flexprice, and the docs walk engineers through the metering setup step by step.