Usage-based pricing

The four pieces, and only one of them is a pricing decision

Seat pricing asks how many people use the product. Usage-based pricing asks how much this account made us do. That sounds like a pricing question and is mostly an engineering one, because the model has four parts and three of them are systems you have to build before you can name a number.

• The unit — the thing you count. A call, a message, a credit, a generated asset, a gigabyte, an active record. Pick something the customer already thinks in, or every invoice becomes a translation exercise.
• The meter — the system that records every unit as it happens, per customer, durably enough to bill from. If this is missing or approximate, nothing else on this list is possible.
• The rate — price per unit, almost always with an included allowance so a quiet month is not an insulting invoice and a busy one is not a surprise.
• The cap — what stops a runaway account from generating a bill nobody can pay. Optional in theory. Load-bearing in practice, especially where an automated workflow can loop.

Only the rate is a pricing decision. The other three are infrastructure, which is why teams that announce usage pricing before the meter is trustworthy end up arguing with customers about their own invoices.

Pure usage, hybrid, and credits

Three shapes cover almost everything shipping today, and the differences matter more to your revenue forecast than to your customer.

• Pure usage. Pay for what you use, no floor. Honest, and unnerving: revenue is hard to forecast, and a quiet month for your customer is a quiet month for you.
• Hybrid. A subscription with an included allowance, then overage above it. This is the common answer because it gives you predictable revenue and gives the customer a predictable floor.
• Credits. The customer buys a balance and actions draw it down. Popular for AI products because one number can cover actions with wildly different underlying costs, and because it lets you re-price a model without re-pricing the plan.

Credits carry a specific trap worth naming: the moment a credit becomes the unit your enforcement code reads, every future rounding decision and every conversion rate turns into a billing bug rather than a display change.

What we learned pricing our own product this way

AgentCeres — the AI Growth Officer at agentceres.com — meters model spend per customer and shows it to them as credits. Two decisions came out of that, and both are the opposite of the obvious one.

The first: the entire ledger runs in dollars, and credits exist only at the last moment before a number reaches a screen. Every gate, every stored balance, every invoice line is in currency; one conversion boundary turns it into the credits a customer sees. That looks like pointless indirection right up until you notice the alternative — enforcing in credits — converts a rounding decision into a money bug, permanently and everywhere at once.

The second: our included allowance is deliberately not the plan price converted at our own rate. Converting exactly would have produced allowances nobody can hold in their head, so we round up to a legible number and accept the margin that costs — and we wrote the reason next to the constant, so the next person does not tidy it away. That is the part a pricing page never shows: the price and the allowance are two decisions, not one, and treating them as one is how copy goes stale the first time either moves.

When not to use it

Usage-based pricing is not automatically the more modern choice. Four situations where a flat plan is simply better:

• Your marginal cost is near zero. If one more action costs you nothing, metering it mostly buys you a customer watching a counter instead of using the product.
• Your buyer needs a fixed number. Procurement at a mid-size company will happily overpay a predictable amount rather than defend a variable invoice every quarter.
• You cannot meter it yet. An estimate is fine for a dashboard and disqualifying for a bill.
• The unit is not one the customer controls. Charging for something they cannot see themselves causing reads as arbitrary, however fair the arithmetic actually is.

If you are working out the number itself rather than the model, how do I price an AI product covers arriving at a rate when the underlying cost moves. If the meter is the missing half, Flexprice is an open-source place to see what one contains before you build it. And if the reason you are here is that you are considering building the whole agent yourself, that decision has its own page.