--- source_url: "https://www.stigg.io/blog-posts/consumption-based-pricing-model" title: "Consumption-Based Pricing Models: Types and Systems" mirrored_at: 2026-08-13T01:06:44.332Z host: www.stigg.io cited_in_42a: true mirror_canonical: "https://index.42a.ai/www.stigg.io/blog-posts/consumption-based-pricing-model" --- > **Original source:** https://www.stigg.io/blog-posts/consumption-based-pricing-model Somewhere in your stack, there’s a credit check that runs after the request completes instead of before it.  It works fine at low volume, holds up through testing, and fails the first time two agent sessions hit the same balance simultaneously, and both go through because neither read the post-deduction state before committing. This guide covers what consumption-based pricing actually requires in production and where systems like that quietly break down. Consumption-based pricing is a model where customers are charged based on how much of a product they use, measured through units such as API calls, tokens, data transfer, or compute time. **For engineering teams, this introduces two core requirements:** 1. **Metering** accuracy means every unit of consumption must be captured, attributed to the correct customer and feature, and stored in a way that supports both billing and enforcement. Get this wrong and every invoice downstream is wrong too. 2. **Real-time enforcement** means the system needs to check limits and apply rules during the request so usage stays within defined boundaries before cost is created. Enforcement that runs after the request completes is reporting. Control happens before the next request runs. Both requirements push responsibility into the runtime system, where usage, limits, and state need to stay aligned as they change. ## How consumption-based pricing works Consumption-based pricing works by capturing product usage, converting it into billable units, and applying pricing rules to calculate charges. **This happens through a pipeline with three stages:** 1. **Ingestion** collects raw telemetry such as API calls, token usage, storage writes, or agent actions. At scale, this involves high event volumes that need to be normalized before processing. 2. **Metering** transforms raw events into the unit the pricing model uses. Storage activity over time becomes GB-months. Requests get counted toward usage totals. 3. **Rating** applies pricing rules to the metered output to produce charges, covering per-unit pricing, tiered rates, discounts, credit usage, and overage handling. The same pipeline feeds both billing and enforcement, but they rely on it in very different ways. **Billing uses aggregated totals over time**, while **enforcement depends on the current state during each request**. This split introduces a system constraint. One side tolerates delay, the other depends on immediate, consistent reads. ## 6 types of consumption-based pricing models The main types of consumption-based pricing models are **pay-as-you-go, tiered, volume-based, prepaid credits, overage, and hybrid models**. **Each one changes how usage is priced and how the system needs to enforce it in real time:** Model How it works Engineering implication 1\. Pay-as-you-go Charged per unit after usage is recorded Requires accurate metering; no balance check before request 2\. Tiered Rate changes at usage thresholds Needs tier detection during rating and current tier tracking 3\. Volume Unit price decreases as total usage increases Requires aggregation across the full billing period 4\. Prepaid credits Customer prepays and usage draws down the balance Requires real-time balance checks and ledger-based tracking 5\. Overage Usage beyond a limit is charged at a different rate Needs threshold detection and configurable enforcement 6\. Hybrid Subscription base with usage-based components Requires combining plan access with usage enforcement **Hybrid models** become the default because they balance predictability with flexibility. A **subscription** sets the baseline, while [**usage-based components**](https://docs.stigg.io/guides/i-want-to/monetize-my-product-using-usage-based-pricing) handle spikes and variability.  That balance introduces more complexity in the enforcement layer, where plan terms and live usage need to be evaluated together on every request. ## What gets metered in consumption-based pricing Consumption-based pricing meters units such as API calls, data storage, compute time, AI tokens, and agent actions, depending on how the product is consumed. ### 1\. API calls Most products start here. Every request generates an event that gets counted per customer over time. **It’s simple to implement,** **but volume adds up quickly**, so the enforcement layer needs to handle concurrent updates without breaking shared counters. This pushes the system toward high-throughput ingestion and atomic counters at scale. ### 2\. Data storage Storage behaves differently because **usage changes over time instead of per event**. Systems usually rely on snapshots at intervals, which makes consistency tricky when data is deleted mid-period or when timing drifts from billing expectations. The pipeline needs to handle time-based aggregation and reconcile state across intervals. ### 3\. Compute time Anything tied to runtime needs start and end tracking. Jobs can fail, pause, or retry, so the **system needs a clear way to handle partial runs, or the usage record ends up incomplete**. This introduces session tracking and state reconciliation as part of the pipeline. ### 4\. AI tokens **Token usage depends on the model and the request itself**. Input, output, and model behavior all affect the count, so the only reliable source is the model response. Estimating from the request tends to drift as models evolve. The system needs tight integration with model outputs and flexible metering logic that adapts over time. ### 5\. Agent actions User actions often trigger a chain of internal steps. Each step can consume tokens, compute, or storage, which means the system needs to trace the full execution path back to the original user action to keep attribution accurate. This requires distributed tracing and multi-step attribution across the pipeline. The unit you choose will shape how your system evolves. If you change it later, **you will need to migrate historical usage, update pricing logic, and maintain consistency** for customers already on existing plans. ## Why consumption-based pricing is harder in AI products Consumption-based pricing is harder in AI products because **cost, usage patterns, and control requirements all change at once**. Challenge What changes in AI products Engineering implication Cost structure Each token has direct infrastructure cost Metering errors impact margin, not just billing accuracy Usage variability Requests vary widely by model, input, and output Requires real-time tracking and enforcement per request Governance needs Teams need budget allocation and usage controls Requires hierarchical limits and pre-request enforcement These differences show up quickly in production, where a single request or workflow can consume far more than expected, especially with reasoning models or multi-step agents. Without real-time enforcement, **usage can spike before limits are applied, leading to large and unexpected costs**. Enterprise requirements make this harder. Teams need to allocate budgets, control usage by workflow, and stay ahead of limits, which shifts the problem from billing to real-time control. ## Why consumption-based pricing requires usage governance Consumption-based pricing requires usage governance because **tracking usage alone does not control how that usage grows in real time**. As usage increases, especially in AI products, the system needs to do more than measure consumption. **It needs to control it**. Without that layer, usage can exceed limits before anyone has visibility into what is happening. **In practice, governance introduces a set of controls that sit in the request path:** - **Limits and thresholds:** Define how much a customer, team, or workflow can consume within a given period. - **Real-time enforcement:** Evaluate usage during each request so limits are applied before additional consumption occurs. - **Alerts and visibility:** Surface usage as it approaches thresholds so teams can act before limits are reached. - **Budget allocation:** Distribute usage across teams, departments, or features while maintaining a consistent total. For AI products with enterprise customers, g**overnance has to operate across multiple levels simultaneously**. A single organization may need per-agent caps, per-team allocations, and department-level spend limits all enforcing independently, and a flat per-customer balance was never built to support that. **This is where the model shifts from billing to control:** billing records what was consumed, governance decides what can be consumed next, and in AI systems that decision has to happen before the request runs. ## Where consumption-based systems break in production Consumption-based systems break in production when **usage, state, and enforcement fall out of sync under real load**. At small scale, a simple setup works. As concurrency increases and plans evolve, gaps appear fast. Failure mode What happens Why it breaks the system Concurrent usage conflicts Multiple requests update the same balance at the same time Creates race conditions and incorrect usage tracking Stale state during enforcement Cached usage or entitlement data becomes outdated Decisions are made on incorrect or delayed state Delayed enforcement Usage is recorded after the request completes Allows overconsumption before limits are applied Incorrect attribution Multi-step workflows or agents are not fully attributed Usage is assigned to the wrong customer or feature Plan changes mid-cycle New limits or credits are introduced during active sessions Enforcement does not reflect the latest plan state Lack of auditability Balances are updated directly instead of being recorded as events Makes reconciliation and debugging difficult The auditability failure surfaces last and costs the most to fix. When balances update directly instead of recording events, there is no transaction history to reconcile against and no way to trace a credit deduction back to the request that caused it. A **mutable balance column** tells you where things ended up. A **ledger** tells you everything that happened to get there, which is what dispute resolution and revenue recognition both depend on. Most of what looks like a billing problem at this stage is a system design problem where metering, enforcement, and state were never built to stay in sync. ## Billing vs. enforcement in consumption-based pricing **Billing and enforcement are not the same system**, and treating them as one is where most consumption-based architectures break down. **Billing** aggregates what was consumed and generates invoices. It can process yesterday's usage events this morning and still do its job correctly.  **Enforcement** has no such tolerance. It runs in the request path, checks current usage against plan limits, and makes a decision before the action proceeds. A read on stale state means the request goes through when it shouldn't. ‎ Billing Enforcement When it runs After consumption Before consumption What it reads Aggregated usage over time Current usage state Tolerates delay Yes No Primary concern Accuracy, invoicing, revenue recognition Access control, limit enforcement [Usage-based billing](https://www.stigg.io/blog-posts/usage-based-pricing) tools are precise, finance-grade, and good at what they do, but they were **built to record consumption and generate invoices**, not enforce limits inside the product at request time. The layer that decides what's allowed before the next request runs belongs upstream of billing in the stack. Stripe handles payments, [**Stigg**](https://docs.stigg.io/documentation/getting-started/welcome-to-stigg) **handles what's allowed**. ## The control layer between product and billing The control layer sits between the product and billing systems, evaluating entitlements and usage state before each request proceeds. Without it, billing calculates charges correctly but the product has no mechanism to stop usage as it happens. **This layer is responsible for:** - **Real-time entitlement checks** that evaluate whether a request is allowed based on current usage and plan limits - **Usage state management** that keeps balances and quotas consistent across concurrent requests - **Limit enforcement** that applies hard limits or overage rules during the request - **Attribution that maps every unit of usage** to the correct customer and context - **Plan resolution** that determines which rules apply when plans or credits change mid-cycle Each component is **independently deployable**. If you already have metering in place, you can add entitlement enforcement without replacing it. If credits are the immediate problem, that's a single integration point. A dedicated runtime handles all of this without pushing the complexity into application code. The Sidecar runs in the customer's cloud as a [Docker container](https://docs.stigg.io/documentation/high-availability-and-scale/sidecar/overview) with a local Redis cache for entitlement data, so **most checks resolve immediately from local state** rather than making a network call on every request. When the cache misses, it fetches from **Stigg's Edge API at** [**around 100ms**](https://docs.stigg.io/documentation/high-availability-and-scale/high-availability-architecture)**, with a configurable timeout** so upstream latency never cascades into the application. For teams with data residency requirements, **the Sidecar deploys inside your own VPC:** - Entitlement state stays within your infrastructure boundary - Enforcement decisions run independently of external uptime - Data residency requirements are met without architectural changes AI products generate millions of entitlement checks per day across concurrent sessions, agent workflows, and org hierarchies. **The enforcement layer handles this through:** - Local resolution via persistent Redis cache with no network call on every request - Throughput that holds as usage complexity and org hierarchy depth grow - Concurrent session isolation so agent workflows don't contend for the same state If the upstream service loses availability, the local cache keeps enforcement running without interrupting requests or opening access. [Webflow](https://www.stigg.io/blog-posts/this-is-how-webflow-engineered-its-high-scale-pricing-packaging-infra-to-the-next-level-with-stigg) has used this setup for years to roll out pricing changes, localization, and credits without routing every change through engineering. ## Real examples of consumption-based pricing models Consumption-based pricing models show how different products meter usage and enforce limits based on what customers actually consume. - **Cursor:** [Cursor prices](http://cursor.com/docs/models-and-pricing) AI usage against an included dollar-value usage pool consumed at per-model API rates, with pay-as-you-go overage once the pool is exhausted. This requires the system to apply different entitlement rules at the same time based on the feature tier. - **Anthropic:** [Anthropic charges per million](https://claude.com/pricing) input and output tokens, with different rates per model. Each request needs to capture token counts from the model response and attribute them accurately to the correct customer and API key. - **AWS:** [AWS](https://aws.amazon.com/) applies consumption-based pricing across multiple dimensions such as compute, storage, and data transfer. Each request needs to be evaluated against free tier limits, included allowances, and usage-based rates to determine how it is billed. Across these examples, the pattern is consistent. The pricing model depends on accurate metering and real-time enforcement so the system can apply the correct rules as usage happens. ## Running consumption-based pricing reliably at scale Most consumption-based pricing implementations **get metering right and treat enforcement as an afterthought**.  The usage data is accurate, and the billing system reconciles cleanly. But the moment concurrent sessions draw down a shared balance, the gap between recording usage and controlling it shows up as overages and disputes. Stigg is the usage runtime that closes that gap. It **resolves entitlements, credits, and spend governance in the request path** before compute runs. If you are building this layer: - Entitlement reads hit local Redis cache first, with Stigg's Edge API as the fallback at around 100ms on misses, so enforcement never adds latency the application can't absorb - Every credit deduction writes an immutable ledger event against the correct balance pool, making concurrent overdraw impossible and giving finance a transaction history that traces to individual requests - Per-user, per-agent, per-team, and per-department budget controls are first-class primitives, so enterprise hierarchy requirements that arrive with the first big contract don't need a schema migration to support - The Sidecar runs inside your own VPC so data residency requirements are met and enforcement keeps running when the upstream service doesn't - Usage events flow to Stripe, Zuora, or any existing billing provider while the enforcement layer operates independently of the payment path If entitlements are eating sprint capacity, **see** [**how Stigg structures the enforcement layer**](https://www.stigg.io/book-a-demo) to fit into a multi-tenant stack without replacing the billing infrastructure you already have. ## FAQs ### 1\. How do companies track usage for consumption-based pricing? Companies track usage by capturing product events such as API calls, tokens, or compute time and converting them into billable units. This data moves through a metering pipeline that feeds both billing aggregation and real-time enforcement, and every event needs a unique identifier so duplicate processing doesn't inflate usage counts. ### 2\. What happens when usage exceeds the limit? When usage exceeds the limit, the system either blocks further usage or allows it and records overage based on plan configuration. That decision has to be enforced during the request against current balance state, not derived from aggregated totals after the billing cycle closes. ### 3\. Why do consumption-based systems fail under load? Consumption-based systems fail under load when usage, limits, and state become inconsistent across concurrent requests. The most common cause is enforcement running after the request rather than before, which leaves a window where limits are applied too late to prevent overconsumption. ### 4\. How do teams control spending in usage-based systems? Teams control spending by setting limits, allocating budgets by team or agent, and enforcing those controls synchronously in the request path. An alert that fires after a threshold is crossed is useful for visibility. Enforcement that runs before the request is what actually stops the spend. ### 5\. Do you need real-time enforcement for usage-based pricing? Yes. Usage needs to be checked before each request proceeds, not reconciled afterward. A system that meters accurately but enforces after the fact will record every event correctly while still allowing overconsumption, which is the failure mode that produces unexpected overages and billing disputes.