Usage-Based Billing for AI and API Products

Flat pricing works until usage starts pulling customers in opposite directions. Your heaviest account drives up infrastructure costs, your lightest account barely touches the product,  but both pay the same monthly fee, so the economics stop making sense.

Usage-based billing gives teams a cleaner way to charge for actual consumption. This article covers the model, the engineering requirements, and the production risks to plan for.

What is usage-based billing?

Usage-based billing charges customers based on how much they use a product. The billing system tracks usage events, applies pricing rules, and creates invoices based on actual consumption during the billing period.

Common usage units include:

• API calls
• Tokens
• Agent actions
• Active users
• Storage
• Compute time
• Outcomes

Usage-based billing is the broader term for pricing that changes with customer behavior. Consumption billing is often used for resource-based models, such as compute hours, token counts, or storage usage.

Usage-based billing components

A production-grade usage-based billing system has six components. Most teams underestimate how many of them need to be built correctly before the model holds up at scale.

The entitlement layer deserves specific attention because most billing tools do not include it. Billing systems aggregate and invoice. The entitlement layer decides whether an action should be allowed before it runs. These are different jobs.

When should you use usage-based billing?

Usage-based billing is the right infrastructure choice when the billing model needs to reflect variable marginal costs and scale with how customers consume the product.

It fits the architecture when:

• Every request has a measurable cost that varies by input: model choice, context length, compute intensity, storage delta
• Usage patterns across customers are wide enough that a flat counter misrepresents the actual cost to serve
• The product needs real-time balance checks in the request path, where every request is evaluated against current usage before it runs
• Tenancy requires per-agent or per-team billing rather than a single org-level balance

The architecture gets harder when:

• Event volume is high enough that the ingestion pipeline becomes a reliability dependency
• Concurrent requests against the same balance require atomic debit operations and consistent cache invalidation
• Mid-cycle plan changes, credits, and overrides need to propagate immediately without breaking existing aggregations

Most AI products end up running a hybrid model: a subscription base covering predictable infrastructure costs, with usage-based billing on top for the variable compute layer.

The engineering implication is that both billing models have to coexist in the same pipeline without conflicting aggregation logic.

How does usage-based billing work?

At the engineering level, usage-based billing is a pipeline. Each stage has its own failure modes.

Event emission

Every billable action in your product should emit a structured event with a customer identifier, event type, quantity, timestamp, and an idempotency key. The idempotency key is the part most implementations skip early and regret later.

Without it, retries and network failures produce duplicate events, and duplicate events produce inflated invoices. At low volume, this is a corner case. At high volume, it becomes a billing accuracy problem.

Ingestion

Events travel to the billing system in real time or in batches. Real-time ingestion keeps balance state current and supports accurate pre-request checks. Batch ingestion is operationally simpler but introduces a lag between usage and billing state.

The tradeoff matters most when you are enforcing limits mid-session. If the balance update lags by five minutes, concurrent requests can overdraw an account before the ingestion pipeline catches up.

At high concurrency, the ingestion layer also needs to handle burst traffic without dropping events or blocking the application.

Aggregation and rating

The billing system groups events by customer and billing period, then applies pricing rules like flat rate per unit, tiered pricing, volume discounts, or hybrid combinations.

However, if a customer disputes a charge or a contract changes mid-cycle, you need to recalculate from raw events rather than adjusting aggregated totals.

Billing platforms that store raw events handle this cleanly, but platforms that discard events after aggregation create a reconciliation problem you can only fix manually.

Entitlement check

Before a billable action executes, the entitlement layer checks whether the customer has sufficient balance or is within plan limits. This runs in the request path before the action begins.

The critical engineering constraint is that the check has to be atomic. Two concurrent requests reading the same balance can both pass individually and together overdraw the account. 

Solving this requires either atomic debit operations at the database level or a cache layer with consistent invalidation. Most in-house implementations skip this and discover it when the first concurrent overdraft lands on an invoice.

Invoice generation

The billing platform produces an invoice from aggregated, rated usage. Proration for mid-cycle plan changes is where most billing platforms introduce edge cases.

If a customer upgrades on day 14 of a 30-day cycle, for example, the invoice has to correctly prorate the old plan, apply the new plan forward, and handle any credits in the right burn order.

Getting this right matters less when it rarely happens and a lot when enterprise customers are changing plans mid-quarter.

Customer visibility

Real-time balance displays are harder to build than they look because they require reading from the same system handling concurrent writes.

A stale balance display is almost as bad as no display at all. Customers making spend decisions based on a balance that lags actual usage will hit limits they did not expect.

The right architecture separates the write path (event ingestion) from the read path (balance display) with a cache layer that invalidates consistently on each debit.

Benefits of usage-based billing

For engineering teams building AI products, usage-based billing has four concrete advantages over flat pricing.

1. Revenue scales with product usage.

When a customer's usage grows, the billing model captures it automatically. That means there’s no re-pricing sprint, plan migration, or sales touchpoint. The expansion path is built into the infrastructure.

2. Pricing experiments stay out of the codebase.

If the billing and entitlement layers are properly abstracted, pricing changes become configuration updates.

For example, before abstracting its entitlement layer, Webflow had to reject around 80% of pricing and packaging requests from stakeholder teams. After integrating Stigg, they could support them all.

3. The same infrastructure serves every customer tier.

A developer hitting 500 API calls a month and an enterprise customer hitting 5 million run on the same billing model. The usage metric handles segmentation automatically, which removes the need for custom plans, separate pricing tables, or manual account overrides.

4. Margins reflect what each customer actually costs.

Flat pricing forces you to pick an average and absorb the variance. 

Per-request cost varies widely by model and complexity. A GPT-4o inference call costs roughly 2-3x what a Claude Haiku call does, and a complex agent run with multiple tool calls can cost many times more than a single-model query.

Usage-based billing brings pricing closer to the cost of serving each account.

Usage-based billing best practices

These are the engineering decisions that determine whether usage-based billing works in production or creates more problems than it solves.

Choose a usage metric that maps to your cost structure

The billing unit should reflect what it actually costs you to serve a customer. Tokens and API calls work for LLM products because they correlate to inference costs.

Active users work when the cost is mainly operational. Proxy metrics that do not correlate to costs create margin problems at scale.

Build enforcement alongside metering

Metering tells you what happened, and enforcement controls what happens next. Building one without the other means usage limits exist on paper but not in the request path.

Every AI product that has shipped a usage cap without an enforcement layer has eventually discovered this the expensive way.

Give customers real-time balance visibility

Customers who can see their usage in real time manage their own behavior. That visibility builds trust in the billing model and reduces frustration when invoices arrive.

Design tenancy before you need it

The first version of usage-based billing is almost always per-user. The first enterprise customer will ask for per-team allocations, and the second will ask for department-level spend caps. Building tenancy into the data model early is far cheaper than retrofitting it after.

Separate billing from enforcement

These are architecturally separate concerns. Billing aggregates and invoices, while enforcement resolves access decisions in the request path.

Trying to do both in the same system creates latency problems when enforcement runs at billing-system speed, and accuracy problems when billing runs at enforcement speed.

Handle concurrent usage carefully

Two requests that start at the same time against the same credit balance can both pass an initial check and overdraw the account together. Preventing that requires atomic debit operations and consistent cache invalidation.

Control usage before compute turns into cost

Consumption billing shows what a customer used after the work is done. AI products also need a control point before the model runs.

Stigg is the usage runtime for AI products. It checks entitlements, credits, usage limits, and spend rules in the request path, so compute only runs when the customer is allowed to use it.

• Sidecar: Runs as a Docker image inside your own VPC, so entitlement checks stay inside the customer’s infrastructure boundary.
• Performance and reliability: On a cache hit, entitlement checks resolve instantly from the local Redis cache. On a cache miss, the Sidecar fetches from Stigg's Edge API at around 100ms, with a configurable timeout.
• Credit ledger: Tracks credits with block-level expiry, paid vs. promotional burn order, and hard or soft depletion by use case.
• Tenancy controls: Enforces per-agent, per-team, and per-department spend caps through configuration.
• Billing integrations: Integrates with Stripe, Zuora, and Chargebee without replacing your billing system.

Each component works independently. A startup can add AI Credits with a single line of code and expand into entitlements, governance, and spend controls as the product grows.

Most teams discover the problem when a single session burns through a customer's monthly budget before the next invoice runs. If compute is already running before credits, limits, or spend caps are checked, the Stigg docs show how to move that decision into the request path.

FAQs

1. What is the difference between usage-based billing and subscription billing?

The main difference between usage-based billing and subscription billing is that usage-based billing changes with consumption, while subscription billing charges a fixed recurring fee. Usage-based billing works better when customer usage and cost vary widely.

2. How does usage-based billing work?

Usage-based billing works by tracking billable events, grouping them by customer, applying pricing rules, and generating an invoice. The engineering challenge is making sure events are accurate, deduplicated, and tied to the right customer or account.

3. What are examples of usage-based billing?

Examples of usage-based billing include charging per API call, LLM token, compute minute, storage gigabyte, message, transaction, or agent action. AI products often use usage-based billing because each request can carry a different cost.

4. Is usage-based billing good for AI products?

Yes, usage-based billing works well for AI products when usage maps clearly to customer value and cost. It is especially useful for products that charge by token, credit, inference call, compute time, or agent action.