Consumption Revenue Explained for AI Products

In AI products, every request costs money, so each one has to be metered, priced, and checked against the customer's limits before the bill runs away from you. Here's how consumption revenue works in practice.

What consumption revenue means for AI products

Consumption revenue ties what a customer pays to what they use. Charges may be based on tokens processed, images generated, compute time, API calls, or completed tasks.

This model fits products with variable serving costs because each request incurs real infrastructure costs. As usage grows, revenue grows with it, helping keep pricing aligned with the cost of delivering the service.

Consumption revenue often uses metering, credits, or usage-based rates to track consumption and calculate what the customer owes.

How consumption revenue works

Consumption revenue works by metering usage, applying pricing rules, checking entitlements, and enforcing the result before or after a request completes. Each layer has a distinct responsibility, and they work together to turn product activity into billable usage.

Each layer answers a different question, and keeping those responsibilities separate makes the system easier to scale and maintain. Here's how the pieces fit together:

Metering records what happened

Everything starts with an event.

Every billable action produces a usage event. That might be tokens processed, an image generated, a minute of audio transcribed, or an API request completed.

Each event captures enough context to describe what happened, including the customer, feature, quantity, timestamp, and any metadata needed for pricing or reporting.

Metering should stay objective. Its job is to capture usage accurately, without assigning prices or deciding whether a request should be allowed.

Rating calculates what the event is worth

Once an event exists, the pricing engine determines its commercial value.

A thousand tokens might cost $0.002, while image generation might consume 5 credits. Enterprise customers might pay different rates from self-serve customers. Rating applies the correct pricing rules based on the customer's plan, contract, discounts, or negotiated terms.

Without a dedicated rating layer, pricing logic quickly spreads across services, making even small pricing changes difficult to ship safely.

Entitlements determine what a customer is allowed to use

Metering records usage, rating prices it, and entitlements decide whether the request should proceed at all.

An entitlement defines the commercial limits attached to a plan, such as available features, monthly quotas, model access, or credit balances. Before a request executes, the application checks whether the customer still has permission to perform that action.

A single entitlement check often combines multiple sources of truth. The effective limit may come from the customer's subscription, purchased add-ons, promotional grants, trial allowances, or enterprise overrides. The runtime resolves those policies into one decision before the request continues.

Enforcement makes the decision in real time

An entitlement only matters if it can be enforced consistently.

For workloads with real infrastructure costs, the application needs to decide whether to allow a request before compute is consumed. Waiting until invoice generation means the customer has already used the resources.

That puts enforcement directly in the request path. Every decision has to stay fast enough that users never notice it, while remaining reliable under concurrency and high request volumes.

Credits introduce another layer of state

Many consumption-based products package usage into credits.

Each credit block can have its own balance, expiry date, source, and accounting treatment. Paid credits, promotional credits, and trial credits often need to remain separate for refunds, reporting, and compliance.

When usage occurs, the runtime applies burn-order rules to determine which balance to consume first. A common policy spends promotional credits before paid credits and expiring balances before non-expiring ones.

Those deductions also need to be atomic. 

If two requests arrive simultaneously, both cannot spend the same credits. Production systems solve this with an append-only ledger that records every debit and credit as an immutable transaction, making balances reproducible at any point in time.

Benefits of a consumption revenue model

A consumption revenue model gives product, engineering, and finance a shared view of what customers use, what that usage costs, and where margins start to move.

1. Margin follows usage

When every request carries a variable infrastructure cost, flat pricing can hide unprofitable customers. Consumption pricing keeps revenue closer to the cost of serving each workload.

A customer processing ten million tokens should contribute more revenue than one processing ten thousand. The model makes that relationship explicit.

2. Usage becomes a product signal

Metered events show which features customers rely on and which ones consume the most compute.

That helps teams answer practical questions. Is the premium model driving retention? Are image generation costs exceeding what customers pay for them? Is one workflow responsible for most of the margin pressure?

3. Enterprise customers get clearer spend controls

Large customers often want usage broken down by team, department, workspace, or agent. The same metering and credit system can power those views without a separate reporting pipeline.

That makes it easier to support internal budgets, chargebacks, usage alerts, and department-level limits.

4. Pricing changes move faster

A well-structured catalog lets teams change credit rates, add usage tiers, or launch hybrid plans without having to rewrite billing logic across multiple services.

A new model can cost eight credits instead of five. A new enterprise tier can include a larger monthly allowance. Those changes remain in the configuration, which reduces deployment risk.

5. Forecasting gets closer to infrastructure reality

Revenue tied to consumption maps more directly to compute, storage, and model costs than revenue based only on seats.

Finance gets a clearer view of gross margin, engineering gets a better basis for capacity planning, and product can see which customer behaviors create the most value and the most cost.

6. Packaging becomes more flexible

Consumption revenue supports prepaid credits, included allowances, overages, hard limits, and committed spend within the same model.

That gives teams room to serve both self-serve users and complex enterprise accounts without building a separate commercial system for each.

Where consumption revenue shows up in AI products

The unit being metered varies by product type, and so does the failure mode to watch for.

The common thread across all five is that the unit of consumption is not the unit of value the customer thinks they're paying for. A customer thinks in resolved tickets or finished renders.

Your system has to translate that into tokens, compute seconds, or API calls without the translation leaking into a confusing bill.

Engineering challenges behind consumption revenue

Consumption revenue turns pricing into a runtime systems problem. The hard parts show up under concurrency, high request volume, tenant complexity, and constant changes to plans and credit state.

• Atomic debits. Two requests can hit the same credit balance at once. A read-then-write pattern can approve both when only one should clear, so debits need to happen atomically against the ledger instead of two separate steps that can race each other.
• Cache and fallback behavior. Entitlement checks sit in the same path as the model call, so they need to resolve quickly. Cache hits stay local, while misses fall back to the source of truth with a configurable timeout.
• Multi-tenant allocation. Entitlements need to resolve per user, per team, per agent, and per product at the same time. Department-level budget controls depend on that level of allocation.
• Reconciliation. Finance needs the ledger to match what the model provider actually charged. Any drift between metered usage and the underlying inference bill turns into a spreadsheet exercise nobody signed up for.
• Grandfathering and mid-cycle changes. A customer who upgrades mid-month, or who sits on a legacy plan from two pricing versions ago, still needs entitlement resolution to pick the right limit without a special case buried in application code.

Real examples of consumption revenue in production

Consumption revenue is tested when usage spikes, pricing changes, or a new credit model goes into production. These examples show where the model breaks and what changes once enforcement moves into the runtime layer:

Webflow: Pricing stops being an engineering project

Pricing changes have a habit of turning into software projects. New plans, regional pricing, promotional credits, and grandfathered customers all introduce another branch of billing logic.

Webflow replatformed onto a dedicated entitlements layer, and that changed how the business evolved. Instead of rebuilding pricing every time the commercial model changed, the team could update product configuration.

An internal estimate suggested a homegrown implementation would have required five engineers for six months.

Before the entitlements layer, Webflow had to turn down around 80% of pricing and packaging requests from other teams. After Stigg, they could support them all, and many pricing changes became catalog updates instead of deployments.

Miro: Adding AI credits without rebuilding billing

AI features introduced a second commercial model alongside Miro's existing seat-based subscriptions. The challenge wasn't invoicing. It was introducing credits, limits, and new entitlement rules without disrupting everything already in production.

The team launched its credit system in under six weeks and avoided an estimated 5,000 engineering hours that would otherwise have gone into building and maintaining the infrastructure internally.

The existing entitlement layer provided them with a place to add new pricing logic rather than rewrite the billing system.

Build vs buy in consumption revenue infrastructure

A simple credit system is easy to build. One balance table and an atomic decrement can support an early product with a few plans and one credit type.

Dedicated infrastructure starts to make sense when the system needs to support:

• Multiple credit types and burn rules
• Team or department budgets
• Real-time spend visibility
• Atomic debits under concurrency
• Mid-cycle plan changes and grandfathered pricing
• Consistent enforcement across millions of requests

At this stage, the work extends beyond tracking balances. The system also needs reliable entitlement resolution, cache invalidation, fallback behavior, ledger accuracy, and tenant-level allocation.

Stigg is the usage runtime for AI products. It enforces entitlements, credits, usage limits, and spend governance synchronously in the request path. Teams can adopt metering, credits, or entitlements separately through the SDK, then add more components as their requirements grow.

What to look for in consumption revenue infrastructure

Consumption revenue infrastructure needs to remain fast and correct as pricing models, tenant structures, and request volume grow.

Stigg provides:

• Real-time entitlement checks confirm access and available usage before compute is consumed, helping prevent unauthorized or unprofitable requests.
• An atomic credit ledger tracks every debit and credit, with block-level expiry and a configurable burn order to keep balances accurate under concurrent updates.
• Hierarchical allocations let teams assign and track usage across users, agents, teams, departments, and products.
• Hybrid pricing support combines subscriptions, included credits, and usage-based charges in a single product catalog.
• BYOC deployment runs the Sidecar in your cloud, keeping enforcement close to the application and ensuring it remains available during upstream interruptions. Checks are resolved from a local cache, while misses fall back to the Edge API after around 100 ms, with a configurable timeout.

The Stigg docs show how these components fit together in a production architecture, from entitlement resolution and credit accounting to request-time enforcement.

FAQs

1. Does consumption revenue replace subscription pricing entirely?

No, consumption revenue rarely replaces subscription pricing entirely in AI products. Most companies pair a base subscription with usage charges above the included allowance, since a pure consumption model leaves sales unable to forecast revenue and customers exposed to unpredictable bills.

2. How is consumption revenue different from usage-based billing?

Consumption revenue is the pricing model itself; usage-based billing is the mechanism that turns usage into an invoice.

Tools like Orb or Metronome track usage and generate bills. Consumption revenue also needs an entitlements layer that decides, in real time, whether a customer can keep consuming before the invoice is even cut.

3. How do you calculate consumption revenue for an AI product?

You calculate consumption revenue by multiplying a per-unit rate by verified usage for a given period: rate per token, per API call, or per credit, times units consumed.

A product charging $0.002 per 1,000 tokens with 10 million tokens processed in a month generates $20 in consumption revenue from that customer alone.

4. Why does consumption revenue need real-time entitlement checks?

Consumption revenue requires real-time entitlement checks because AI usage incurs marginal costs that compound within minutes, not over a full billing cycle. A synchronous check, evaluated in the same request that triggers the cost, blocks or throttles usage before it turns into an unexpected bill.

5. What are common examples of consumption revenue in AI products?

Common examples of consumption revenue include token-based pricing for LLM APIs, credit-based pricing for image and video generation, and per-minute pricing for voice transcription.

Anthropic's API, Cursor, and ElevenLabs all run variations of this model, in which usage draws down a credit or token balance rather than hitting a flat monthly cap.