Usage-Based Pricing Model: How to Forecast Consumption Revenue

A usage-based pricing model charges customers based on how much of your product they actually consume, whether that's API calls, compute hours, data processed, or transactions completed. If you're building an API-first, AI, or infrastructure product, this is likely your revenue model, and forecasting it correctly requires different mechanics than a traditional subscription. The distinction matters now more than ever: according to SaaStr's July 2026 analysis, Anthropic scaled from roughly $9 billion in run-rate revenue at the end of 2025 to $30 billion by April 2026, all driven by consumption-based API pricing.

What Is Usage-Based Pricing?

Usage-based pricing (also called consumption-based or pay-as-you-go pricing) is a model where customers pay in proportion to their actual usage of a service. The "unit" varies by product: API calls for developer tools, tokens processed for AI models, gigabytes stored for cloud platforms, or transactions completed for payment processors.

This differs fundamentally from seat-based SaaS, where revenue is tied to how many users are on the account. In a usage-based model, a single customer can generate $500 one month and $50,000 the next, depending on how deeply they integrate your product into their workflows. That variability is both the upside and the modeling challenge.

The model works particularly well when your product delivers value in direct proportion to consumption. If a customer makes 10x more API calls, they're getting 10x more value, so charging 10x more feels fair. When value and usage decouple (say, a dashboard product where one login gives access to all data), usage-based pricing creates friction rather than alignment.

Why Founders Are Shifting to Usage-Based Pricing

Two forces are driving the shift. First, the rise of AI and API-first products naturally lends itself to metered billing. When your core product is an inference endpoint or a data pipeline, the unit of value is inherently countable. Second, usage-based pricing removes adoption barriers. Customers start small, pay only for what they use, and scale spending as they get results.

Anthropic's trajectory illustrates this at extreme scale: run-rate revenue jumped from $9 billion to $14 billion in just two months, then doubled again to $30 billion by April 2026. That kind of expansion isn't possible with fixed-seat pricing. It happens when customers ramp usage as they deploy your product to more workloads.

Here's the thing: usage-based pricing also changes which metrics you watch. Traditional MRR tracking still applies, but you need to add consumption-specific KPIs.

Metric	What It Measures	Target Range
Revenue per Unit	Price efficiency per API call, token, or GB	Varies by vertical
Usage Expansion Rate	MoM growth in per-customer consumption	5-15% MoM
Cost per Unit (COGS)	Infrastructure cost to serve one unit	Below 40% of price
Gross Margin	Revenue minus direct delivery costs	50-70%
Net Revenue Retention	Revenue retained and expanded from existing customers	Above 120%

The net revenue retention number is especially telling for usage-based businesses. Because customers naturally ramp consumption over time, well-positioned products often see NRR above 130%. That means your existing customer base grows 30%+ annually before you close a single new deal.

How to Model Usage-Based Revenue: Step by Step

Step 1: Define Your Billable Unit

Pick the unit that most directly maps to customer value. For an AI inference API, this might be tokens processed. For a data platform, gigabytes scanned. For a payment processor, transactions completed. The key test: does doubling the unit count roughly double the value the customer receives?

Step 2: Estimate Volume Per Customer

Break customers into cohorts by size or use case. A startup integrating your API for one feature might make 50,000 calls per month. An enterprise embedding it across their product suite might make 50 million. Model each segment separately, because average-customer math will mislead you.

Monthly Revenue = Active Customers × Avg Units per Customer × Price per Unit

Step 3: Model Usage Growth (Expansion Revenue)

This is the part most founders underestimate. In usage-based businesses, expansion revenue from existing customers often exceeds revenue from new customer acquisition. Model a monthly usage growth rate per cohort. A conservative assumption is 3-5% MoM per customer. Strong products see 8-15%.

Month N Revenue = Month 1 Revenue × (1 + Usage Growth Rate) ^ (N - 1)

Step 4: Subtract Unit Economics

Every unit you serve has a cost. For AI startup models, inference compute is the primary COGS line. For data products, it's storage and processing. Calculate your cost per unit and subtract it to get gross margin.

Gross Profit per Unit = Price per Unit - Cost per Unit
Gross Margin (%) = (Gross Profit per Unit / Price per Unit) × 100

A gross margin below 50% signals that your pricing doesn't leave enough room for operating expenses, sales, and profit. Margins below 40% are common at early scale but become a problem if they don't improve as volume grows and you negotiate better infrastructure rates.

Calculate Your Usage-Based Revenue

Usage-Based vs. Subscription Pricing

Most companies don't choose one model exclusively. The hybrid approach (a base platform fee plus usage-based overages) is increasingly common. Here's how the two models compare across the dimensions that matter most for financial modeling.

Dimension	Subscription (Seat-Based)	Usage-Based	Hybrid
Revenue predictability	High	Low to medium	Medium to high
Expansion potential	Limited by seat count	Uncapped	Strong
Acquisition friction	Higher (annual commit)	Lower (start free/small)	Moderate
Churn visibility	Clear (cancel event)	Gradual (usage decline)	Mixed signals
Gross margin profile	70-85% typical	50-70% typical	60-80%
Best for	Workflow tools, dashboards	APIs, AI inference, data	Platform + API products

The honest answer is that pure usage-based pricing works best when your unit costs scale linearly (or better) with revenue. If serving the marginal unit gets more expensive as volume grows rather than cheaper, you'll face margin compression at exactly the moment revenue looks most impressive. That's the trap to watch for.

For your financial model, the practical difference is this: subscription models let you forecast revenue as a function of customer count and ARPU. Usage-based models require you to forecast both customer count and per-customer consumption trajectories, adding a second variable that compounds uncertainty. If you're building a SaaS financial model, layer in usage-growth assumptions as a separate input. Don't embed them in a single blended ARPU number.

Common Mistakes in Usage-Based Revenue Models

1. Using a single "average customer" projection. Usage distribution across customers follows a power law, not a bell curve. A handful of large customers will drive 60-80% of revenue. Model your top 10% separately from the long tail, or your projections will be wrong in both directions.

2. Ignoring cost scaling. Revenue growing 5x is exciting until your infrastructure bill grows 6x. Model COGS as a function of volume, not as a flat percentage. Talk to your engineering team about where unit costs plateau and where they spike.

3. Confusing usage with commitment. A customer making 1 million API calls today might switch providers or build in-house next quarter. Usage-based revenue lacks the contractual stickiness of annual subscriptions unless you pair it with a minimum commit. Factor this into your churn rate modeling.

Key Takeaways

• Usage-based pricing charges per unit consumed (API calls, tokens, GB, transactions) and is the dominant model for AI, API, and infrastructure products
• Expansion revenue is the engine: strong usage-based businesses see per-customer consumption grow 5-15% MoM, driving NRR above 120%
• Model customer cohorts separately, not as a blended average, because a power-law distribution means your top accounts drive most revenue
• Watch unit economics closely: target 50-70% gross margins, and model COGS as a function of volume rather than a flat percentage
• Consider a hybrid model (base fee plus usage) to combine revenue predictability with expansion upside

Your revenue model should reflect how your customers actually pay. If you're building an API or AI product, start with the consumption math, not the subscription math. Build your usage-based financial model in Revenue Map to project consumption revenue, stress-test margin scenarios, and track the metrics that matter for your pricing structure.