How Consumption-Based Billing Works for AI Products

Consumption-based billing gets harder when AI usage keeps running after the customer should have stopped. A workflow starts on Friday, calls models all weekend, and shows up Monday as thousands of LLM calls and months of credits gone.

Billing recorded the usage correctly, and the invoice is accurate, but the problem is timing. AI products need a way to control usage while it is happening, before compute costs pile up.

What is consumption-based billing?

Consumption-based billing charges customers based on what they use, unlike other methods that use a fixed monthly fee. The billing system ingests usage events, applies pricing rules, and generates an invoice based on consumption during the billing period.

Common consumption units include:

• API calls
• LLM tokens
• Compute minutes
• Storage gigabytes
• Agent actions
• Any measurable event your product can emit

Flat subscriptions charge the same amount regardless of usage. Consumption billing ties the invoice directly to what the customer consumed.

Consumption-based billing vs usage-based billing

Consumption-based billing and usage-based billing usually mean the same thing. Both describe pricing models where customers pay based on what they consume.

You may also hear related terms like metered billing or pay-as-you-go billing. Metered billing often refers to the event ingestion and aggregation layer, while consumption-based billing describes the broader pricing and billing model.

How consumption billing works at the engineering level

Consumption billing works as a usage pipeline that turns product events into invoice line items.

At a basic level, the system has four parts:

• Usage event ingestion: Your product sends an event every time a billable action happens. That event usually includes the customer ID, event type, timestamp, quantity, and any metadata needed for pricing. Events can stream in real time or arrive in batches.
• Aggregation: The billing system groups those events by customer, product, and pricing dimension. For example, it may count the first 10,000 tokens at one rate and the next 100,000 at a lower rate.
• Pricing rule application: The system applies the pricing logic to the aggregated usage. This could be a flat per-unit rate, tiered pricing, volume discounts, committed usage, credits, or a hybrid model.
• Invoice generation: The priced usage becomes invoice line items. The billing platform then generates the invoice and collects payment.

The hard part is keeping that pipeline accurate as usage grows. A simple metering table may work at low volume, but it gets harder when you add concurrent requests, customer hierarchies, credit balances, retries, late-arriving events, and real-time usage visibility.

That is where consumption billing becomes an engineering system that shapes how the product behaves and how usage is enforced.

Types of consumption billing models

There are several ways to structure consumption billing, and most AI products end up combining more than one.

Credit-based models deserve specific attention. They are the dominant pattern for AI products, and the engineering requirements are more complex than a single balance column.

Consumption billing in practice: AI product examples

The clearest examples of consumption billing done well are the infrastructure companies that got there first.

AWS charges per compute hour, per gigabyte of storage, and per API call across hundreds of services. The key engineering decision was separating compute and storage costs entirely, so customers can scale each independently. A team running a data-intensive workload pays for storage without paying for idle compute.

Snowflake went further by charging credits only when virtual warehouses are actively running queries. Idle warehouses incur no compute charges, and the billing model aligns with the product's actual marginal cost profile instead of relying on a proxy metric.

Anthropic charges per input and output token, with different rates by model. A developer running Claude Haiku for summarization pays a fraction of what they would for Claude Opus on a complex reasoning task. The billing model reflects real cost variance per request.

Cursor uses a flat subscription covering a base usage floor, with consumption billing layered on top for requests above the threshold. This is increasingly common for AI-native products that want subscription revenue predictability while still capturing value from high-usage customers.

Across all of these examples, the pricing unit matches the product's cost structure, and the billing model grows alongside customer usage instead of limiting it.

Why AI products specifically need consumption billing

AI products need consumption billing because every LLM call carries a real marginal cost.

That cost changes based on the model, context length, output length, and the number of tool calls an agent triggers. A complex multi-step workflow can cost 50x more than a simple question from the same customer in the same session.

Flat pricing struggles with that variance. You either overcharge light users until pricing feels unfair, or undercharge heavy users until margins start to shrink. Consumption billing, on the other hand, ties revenue closer to the cost you actually incur.

The consumption patterns that matter most for AI products include:

• LLM inference calls: Cost varies by model, context length, output length, and reasoning effort. Billing needs to meter each dimension separately.
• Agent actions: A single agent run can trigger dozens of downstream tool calls, API requests, or workflow steps, each with its own cost profile.
• Embedding generation: Embeddings are high-volume and low-cost per call, so event ingestion needs to handle volume without adding unnecessary overhead.
• Compute time: Fine-tuning, batch processing, and retrieval-augmented generation carry compute costs that map naturally to time-based consumption billing.

The more variable the cost of each action becomes, the more important it is for pricing to follow actual usage instead of forcing every customer into the same flat fee.

What consumption billing cannot do on its own

Consumption billing tells you what was used, but it can’t decide what should have been allowed.

Billing platforms like Stripe, Orb, and Metronome record what happened and generate accurate invoices. The question "Is this customer allowed to run this action right now?" has to be answered before the action executes. However, metering answers it afterward.

For an AI product where a single session can overdraw the account, that problem comes up on every concurrent request.

Three specific scenarios where it shows up:

• Credit overdraft: A customer runs out of credits mid-session. The session continues until the next metering cycle catches the deficit. By then, the cost is already committed.
• Concurrent requests: Two agent workflows start simultaneously against the same credit pool. Both pass an initial balance check, but their combined consumption overdraws the account before either completes.
• Enterprise spend caps: A department head sets a monthly AI budget. Without a check on each request, the cap is visible in the dashboard but enforced nowhere in the stack.

This means the enforcement layer has to be in the request path before compute runs.

What production-grade consumption billing requires

Moving from a basic metering table to production-grade consumption billing involves more engineering than most teams estimate upfront.

Event ingestion at volume

At high request volumes, the ingestion pipeline has to absorb bursts without dropping or duplicating events.

Both mistakes are expensive. If usage is undercounted, revenue leaks. If usage is overcounted, the customer gets an invoice they don’t trust, and your team gets pulled into a dispute.

Credit management

If you are running a credit-based model, the data model is more complex than a single balance column. Credits come in blocks with individual expiry dates and cost basis.

Promotional credits and paid credits burn in a defined order: promotional before paid, expiring before non-expiring.

Depletion behavior is either hard (blocks the action when the balance hits zero) or soft (allows the action and flags the overdraft). All of this requires an append-only ledger for reconciliation.

Real-time balance resolution

When the system checks a customer's balance, it needs a real-time view of usage. As request volume grows and more requests run at the same time, keeping that balance accurate becomes much harder.

Without careful cache invalidation and concurrency handling, two requests can draw from the same balance and let usage exceed the limit before the system catches up.

Enforcement in the request path

You need a check that runs before the action executes, resolves against a current balance, and returns fast enough that adding it to the request path does not degrade the product experience.

Tenancy

Enterprise customers do not just need an org-level balance. They need per-team allocations, per-agent budgets, per-product spend caps, and the ability to set hard limits at any level of the hierarchy independently.

Where in-house consumption billing breaks down

Building consumption billing in-house is the default decision, and for a single product with straightforward usage patterns, it is often the right one. A credits table, a decrement function, and a usage events log get you further than you might expect.

The system starts breaking under specific conditions. Not at a particular ARR or headcount, but when:

• Enterprise customers ask for team-level allocations with hard spend caps
• Concurrent agent workflows draw from the same credit pool
• A pricing change requires updating consumption logic across multiple services
• Finance needs an audit trail that reconciles balance changes to individual transactions
• Enforcement has to happen synchronously before a request executes, not after

Miro hit this point when they added AI credits to a product that already had a complex hybrid pricing model. A plan introduction that should have been straightforward became a multi-month cross-functional initiative.

After moving to Stigg, they recovered over 5,000 engineering hours and freed engineering from stepping in every time packaging changed.

Stop runaway usage before it reaches billing

Stigg is a usage runtime that gives AI products a control point before usage turns into cost. It checks entitlements, credits, limits, and spend rules while the request is still moving through the system, so compute only runs when the customer is allowed to use it.

After the model call, billing can only record the damage. In the request path, Stigg can still stop the runaway session.

• Stigg Sidecar: Runs as a Docker image inside your own VPC. On a cache hit, reads are immediate. On a cache miss, the Sidecar fetches from Stigg's Edge API at around 100ms, with a configurable timeout to prevent upstream latency from cascading into your application.
• Credit ledger: Append-only, with block-level expiry, paid vs. promotional burn order, and hard or soft depletion per use case
• Tenancy controls: Per-agent, per-team, per-department spend caps enforced through configuration
• Billing integrations: Sits above Stripe, Zuora, and Chargebee without replacing them
• You can use each component independently, which means metering without entitlements, and credits without replacing your billing stack, or adopt the full platform as needs grow

If invoices are where you first discover runaway usage, the Stigg docs show how to move enforcement into the request path.

FAQs

1. What is the difference between consumption billing and subscription billing?

The main difference between consumption billing and subscription billing is that subscriptions charge a fixed amount regardless of usage, while consumption billing charges based on what was actually consumed.

For AI products with variable marginal costs per request, consumption billing aligns revenue with the cost of serving each customer.

2. What is a credit-based billing model?

A credit-based billing model lets customers purchase a balance upfront and draw it down with each billable action. Credits come in blocks with expiry dates, cost basis, and defined burn order. Hard depletion blocks the action when the balance hits zero; soft depletion allows it and flags the overdraft.

3. Can consumption billing enforce usage limits in real time?

No, consumption billing records what was consumed and invoices after the fact. Real-time enforcement requires a separate layer that runs checks in the request path before actions execute.

For AI products where a single session can generate high cost, that distinction is the architecture decision worth getting right before the first runaway overage hits an invoice.

‍