Usage-based

What this model actually means

Pure usage-based pricing, also called pay-as-you-go or consumption-based pricing, means the customer pays only for what they consume. Every API call, every token processed, every automation run, every gigabyte stored generates a charge. There is no subscription floor. A customer who uses the product once a week pays only for those uses. A customer who uses it continuously pays proportionally more.

This is structurally honest. Your cost to serve a high-usage customer is genuinely higher than your cost to serve a low-usage one. Usage pricing reflects that reality. It also lowers the barrier to starting: there is no monthly commitment to justify before a new customer has seen the product work in their context. They can try it, get value, and pay for exactly what they got.

For developer tools and API products, this is the native pricing language. Developers expect to pay per call, per token, or per compute unit. They have tools for tracking and predicting those costs. A flat subscription on a developer product creates artificial friction because developers want to know what they will pay before they commit to building on top of it.

Why you land here

The Pricing Unit Picker routes you to usage-based pricing when your product type is an API or developer tool, your cost structure is genuinely variable with consumption, and your buyers have the sophistication to manage a metered cost. These are typically engineers or technical buyers who are comfortable with cost control at the consumption level and who would resist a flat subscription that felt like paying for capacity they might not use.

The model also fits products where usage varies dramatically across customers. A customer running a nightly batch job looks very different from a customer running continuous real-time inference. Trying to fit both into a flat subscription requires either overcharging the batch customer or undercharging the real-time one. Usage billing handles heterogeneous demand without requiring tiered plans that never quite fit anyone.

What it is often confused with

The most common conflation is with flat subscription pricing. Both feel like "you're paying for software," but the economic relationship is completely different. A flat subscription says: the cost is certain, the usage is unlimited (or practically unlimited). A usage model says: the cost is proportional, the budget responsibility lies with the customer.

The important distinction is where the risk lives. In a flat subscription, the vendor takes the demand risk: a power user and a light user both pay the same price, and the vendor hopes the average works out. In a usage model, the customer takes the cost risk: their bill goes up when they use more, and they are responsible for managing that.

For the right customer, taking cost responsibility is fine. For the wrong customer, it is a reason not to use the product.

The meter suppresses exploration

This is the most counterintuitive failure mode of pure usage pricing. Logically, paying only for what you use should make customers more comfortable using the product, not less. In practice, the visible meter creates a cognitive tax on every interaction.

When each action has an explicit price, users start making micro-decisions about whether the action is worth the cost. They do not run a query they are only half-sure about. They do not ask the AI a speculative question. They do not explore an edge case that might not be worth a few cents. Each of these micro-hesitations is individually small. Collectively, they reduce the customer's surface area of use, which reduces their experience of value, which increases churn.

Products built for exploration, ideation, and iterative work suffer from this the most. A writing assistant where you might try fifteen variations of a prompt before finding the right one is a terrible fit for pure usage billing. Every iteration costs something, and the cost of iteration is exactly what gets people to stop iterating. A product built for precise, high-confidence single-run tasks is a better fit: there is no exploration tax if you are not exploring.

The bill shock problem

Usage billing's second major failure mode is the unexpected large invoice. A customer's automation runs more than expected one month. A developer makes an error in a loop that generates thousands of unnecessary API calls. A teammate accidentally triggers a high-cost operation. The customer opens their invoice and sees a number they were not prepared for.

This is not a billing failure. It is a trust failure. The customer does not feel cheated exactly, but they feel surprised, and surprise in a billing context tends to read as "I do not have control over what I am spending here." That feeling persists long after the specific incident is resolved. Some customers never fully recover it.

The mitigation is spending controls: hard caps that stop billing when a limit is hit, soft alerts that warn before a limit is reached, and clear usage dashboards that let customers see their current trajectory at any time. These are not nice-to-haves in a usage-based product. They are the primary customer experience features that determine whether the model builds trust or erodes it.

Risks and failure modes

No floor means no baseline revenue. A slow month, a seasonal dip, or a customer going dark during a project transition drops your revenue to zero from that account. Pure usage models have inherent revenue volatility that makes financial planning harder. This is manageable with a diverse customer base but can be serious with concentrated revenue.

Cost prediction anxiety. Enterprise buyers in particular often need a budget number before they can approve a vendor. "We charge per API call and usage varies" is harder to approve than "we charge $X per month." If your sales process involves procurement, consider whether the absence of a base fee creates a structural obstacle at the signing stage.

Race to the bottom on unit price. Because usage pricing is inherently comparable (you can directly compare $0.002 per call versus $0.003 per call), it invites price competition in a way that subscription pricing does not. If your unit price is your primary differentiator, that is a fragile position.

What to do from here

If pure usage pricing is the right model for your product, the most important investment is in cost visibility tooling. Customers should be able to see their usage, their current spend, and their projected month-end cost from inside the product at any time, not just in an email at the end of the month.

Consider whether a hybrid model with a low base fee would serve you better without meaningfully changing the customer experience. A $19/month base with usage on top solves the revenue floor problem, solves the budget approval problem, and usually does not change how developer customers think about the product. The question is whether the base changes the adoption calculus for your specific buyers. For some, it does. For most developer tools, it does not.

Pick the usage metric that customers intuitively understand as "more of this means I'm getting more value." API calls, tokens, runs, rows processed: the right answer depends on what your product does and how customers think about their own usage. The metric that requires the least explanation in a sales conversation is usually the correct one.