Hybrid Billing: An Engineering Guide for AI Products

A customer has 40,000 included credits, a prepaid add-on, and postpaid overages enabled. Three agents run at once and exhaust the remaining balance before the usage counter refreshes.

Engineering must decide which requests were covered, which became overages, and which should have stopped.

Hybrid billing combines several pricing models in one account, but the product still needs to resolve each request in real time.

What is hybrid billing?

Hybrid billing is a pricing model that combines two or more payment methods, such as a recurring subscription, included usage, prepaid credits, and postpaid overages, within one customer plan.

It gives customers a predictable base cost while allowing additional charges for variable usage.

Common hybrid billing components include:

• A recurring subscription or platform fee
• An included usage allowance
• Prepaid credits
• Metered overages
• Minimum commitments
• One-time add-ons
• Outcome-based or action-based charges

The exact mix depends on how the product measures usage, manages balances, and handles overages.

How hybrid billing works

The commercial flow behind hybrid billing usually follows a consistent order of operations:

1. Charge the recurring platform or subscription fee
2. Grant the included usage allowance
3. Consume the included allowance first
4. Draw from prepaid credits or committed usage next
5. Apply postpaid overage pricing once those balances run out
6. Export finalized billable usage for invoicing

The consumption order has to be explicit. Two systems can calculate different totals for the same customer if one applies prepaid credits before included usage and the other does the reverse. Define the order once and apply it consistently everywhere.

Hybrid billing vs. other pricing models

It's easy to lump hybrid billing in with its neighbors, so here's how it actually stacks up against the models people tend to confuse it with:

The key distinction is that credits can be one part of a hybrid billing model, but they do not define it.

A credit-based product can exist without using a hybrid model. A hybrid pricing model can also work without credits by combining a subscription with metered overages.

The two concepts are related, but they are not interchangeable.

Common hybrid billing models for AI products

A few hybrid structures appear often in AI products because model calls, agent actions, and compute costs do not fit neatly into a fixed subscription.

Subscription with included AI usage

A coding assistant might charge a monthly platform fee and include 50,000 credits. Once the allowance runs out, new usage moves to a metered overage rate.

This gives customers a predictable base cost while letting heavier users keep working. Engineering still needs a live view of the remaining allowance so concurrent requests do not overspend it.

Prepaid credits with automatic top-ups

Picture a self-service agent platform where customers fund a wallet before running workloads. When the balance falls below a set threshold, the system automatically purchases another credit block.

The technical work sits in the recharge flow. The platform must prevent duplicate top-ups, handle failed payments, and decide whether requests should pause while a new balance is being added.

Annual commitment with metered overages

An enterprise customer may commit to $100,000 of AI usage for the year without consuming it evenly each month. Usage draws down against that commitment until it is exhausted. Anything beyond the contracted amount becomes an overage.

This model requires separate tracking for contract value, consumed usage, remaining commitment, and overage eligibility. Those states may also differ across departments or products.

Platform fee with multiple usage meters

Some AI products cannot reduce everything to one unit. A single workflow may consume model tokens, browser minutes, image generations, and external tool calls.

In that case, the customer pays for platform access, then each meter follows its own rate and aggregation rules. The system must attribute every event correctly and stop retries from appearing as new billable usage.

Prepaid wallet with postpaid fallback

A prepaid wallet gives the customer a clear spending boundary. Enterprise accounts may still need uninterrupted service after the balance reaches zero, so approved usage moves into postpaid billing instead of stopping.

That transition needs an explicit rule. The runtime must know which accounts can cross zero, whether approval is required, and when a hard limit should block the next request.

Why hybrid billing is harder for AI products

Hybrid billing looks manageable on a pricing page. The difficulty appears once real customers, concurrent agents, and changing balances enter the system.

A request can begin under one commercial rule and finish under another, while engineering still needs to decide whether the next step can run.

One workflow can cross several balances

Imagine an agent starting with included credits available. Midway through the task, those credits run out. The workflow moves into a prepaid wallet, drains that balance, then reaches an overage state before it finishes.

The system has to track each balance transition without interrupting valid work or charging the wrong source.

You may not know the final cost when the request starts

An agent request rarely maps to one predictable action. It may route between models, retry failed calls, use external tools, or create follow-up steps.

Engineering often has to reserve an estimated amount before execution, then compare that reservation with the final usage. Any unused balance must be released, while any extra usage must still be charged correctly.

Concurrent agents compete for the same balance

A workspace might show 500 credits remaining while five agents start jobs at the same time. If each request reads the same balance, all five may receive approval even though the account cannot cover them together.

Reservations or atomic balance updates prevent several requests from spending the same credits.

The commercial unit can hide changing AI costs

Customers may see one credit, but that credit can represent different models, tools, and amounts of compute. A workflow using a larger model may cost far more to serve than one using a smaller model.

When conversion rules change without clear versioning, customers can burn through balances faster than expected, and historical usage becomes difficult to explain.

One account can contain several control levels

An enterprise customer may receive organization-wide pricing. Each department may still have its own budget, and every agent may carry a separate action limit.

One request can pass the organization-level pricing check and still fail at the department or agent level. The system needs to evaluate each control scope independently without allowing one rule to overwrite another.

The product needs an answer before billing catches up

The billing system can calculate the final overage after the period closes, but the application can’t wait until then.

Before another model call begins, the product needs to know whether the request uses included credits, draws from a prepaid wallet, becomes postpaid usage, requires approval, or must stop.

When hybrid billing fits an AI product

Hybrid billing isn't the default answer for every AI product. It fits when different customer needs or cost structures require more than one component to work together.

The pattern across both columns is the same. Hybrid billing makes sense when a product has several customer needs or cost structures to support at once. If your product has limited variation today, the caution column is likely the more accurate reflection of where you stand.

How to design a hybrid billing model for AI

Most hybrid billing failures start with an undefined rule. Engineering teams should decide what gets consumed, in what order, and at which scope before connecting usage events to billing.

1. Define each commercial component separately

Model the subscription fee, included allowance, prepaid credits, commitments, add-ons, and overage rate as separate objects. Do not collapse them into one account balance.

Each component should have its own identifier, source, effective date, expiration policy, and billing treatment. This makes it possible to explain why a request drew from one balance instead of another.

2. Choose one customer-facing usage unit

Decide what the customer will see and understand. That unit might be credits, tokens, agent actions, inference requests, generated minutes, documents, or outcomes.

Then define how raw usage maps to it. A credit model, for example, may convert input tokens, output tokens, tool calls, and GPU time into one commercial unit. Store the conversion rule with the usage event so historical charges remain reproducible after model costs change.

3. Set a deterministic consumption order

Write down the exact order in which balances are used. A common sequence is:

Consumption priority:

1. Included allowance
2. Promotional credits
3. Purchased credits
4. Contracted commitment
5. Postpaid overage

The same priority must apply in the request path, ledger, customer portal, support tools, and invoice export. If each system resolves the order independently, balances will drift.

4. Separate reset periods from expiration rules

Different components may run on different clocks. Included credits may reset monthly, an annual commitment may draw down across twelve months, and purchased credits may expire one year after purchase.

Store the start time, end time, reset rule, and expiration time for each balance. Avoid inferring them from the invoice period, because one account may contain several active periods at once.

5. Define hard limits, soft limits, and fallback states

A hard limit rejects new usage when the approved balance reaches zero, while a soft limit allows usage to continue while triggering an alert, approval flow, or overage charge.

Also define the fallback. When prepaid credits run out, should the request move to postpaid billing, pause for approval, draw from another wallet, or stop? That decision should be resolved before the expensive work begins.

6. Reserve usage before execution

The final cost of an AI request is often unknown when it starts. Estimate the likely consumption, then reserve enough balance before calling the model or agent.

When the work completes, reconcile the reservation against actual usage. Release unused credits, charge any additional amount, and record both operations in the ledger. This prevents concurrent requests from spending the same remaining balance.

7. Make every usage operation idempotent

Retries should not create duplicate consumption. To avoid this, assign an idempotency key to each reservation, usage event, reconciliation, refund, and top-up.

If the same event arrives twice, the system should return the original result instead of applying the financial change again. This rule matters across API retries, queue redelivery, worker restarts, and webhook replay.

8. Define failure and refund behavior

A failed request should release its unused reservation. A partially completed workflow may need a partial charge, and a customer refund should create a new ledger adjustment rather than rewriting the original event.

Keep the history append-only. Record what happened, then record the correction. Support and finance should be able to reconstruct the account without guessing which records were changed later.

9. Set the aggregation scope for every rule

Specify whether each balance, limit, and overage rule applies to a user, agent, team, workspace, department, organization, wallet, or billing account.

Do not assume every rule shares the same scope. Organization-wide pricing can coexist with department budgets and agent-level limits. The request path must evaluate each layer independently and return a clear reason when one of them blocks usage.

10. Version every pricing and contract change

A plan update should not change how earlier usage is interpreted. Store every pricing rule with an effective date, version, and contract reference.

When a request runs, resolve the version active at that moment. When a dispute happens later, the ledger should point back to the exact allowance, conversion rule, balance priority, and overage policy that applied.

The infrastructure requirements for hybrid billing in AI products

The tiered pricing version of this problem has one moving part, which is determining the rate that applies.

Hybrid billing introduces several more, including which balance pays, the order balances are used, and what happens when one runs out mid-request. That creates a different infrastructure problem, with each component taking on responsibilities specific to hybrid billing.

The theme running through that right column is sequencing. A single-metric system answers one question per request. A hybrid system, meanwhile, has to answer several, in a specific order, and get that order right even when three requests are trying to drain the same balance at the same moment.

How an AI request is authorized and settled under hybrid billing

A hybrid billing system cannot wait until invoicing to decide how usage should be funded. Each request needs an approved balance, a spending limit, and a fallback rule before the expensive model or agent work begins.

A typical request moves through eight stages:

1. Identify the account context. Resolve the customer, user, agent, team, workspace, and active contract.
2. Load the commercial rules. Retrieve the plan, entitlements (the commercial allowances that define what a customer can access and how much they can use), available balances, usage limits, and overage settings.
3. Estimate the likely usage. Calculate how many credits or billable units the request may consume.
4. Select the first eligible balance. Follow the configured priority, such as included usage, purchased credits, committed spend, then postpaid overage.
5. Reserve usage and authorize the request. Hold the estimated amount so concurrent requests cannot spend the same balance.
6. Execute the workload. Run the model, tool call, generation job, or agent workflow and record the actual usage.
7. Reconcile the final amount. Release unused credits or move excess consumption into the next eligible balance or an approved overage.
8. Update downstream systems. Write the final ledger entries, refresh the customer-facing balance, and export settled usage to the billing system.

The following simplified TypeScript example shows balance priority, usage reservation, reconciliation, and postpaid fallback in one request flow:

type HybridRequestResult =

  | {

      status: "completed";

      result: {

        unitsConsumed: number;

        output: unknown;

      };

    }

  | {

      status: "denied";

      reason: string;

    };

async function handleHybridRequest(

  customerId: string,

  estimatedUnits: number,

  idempotencyKey: string

): Promise<HybridRequestResult> {

  const billingContext = await resolveBillingContext(customerId);

  const balances = await resolveBalancePriority({

    customerId,

    planId: billingContext.planId,

  });

  // Example order:

  // [includedUsage, purchasedCredits, committedUsage, postpaidOverage]

  const reservation = await reserveFromBalances({

    customerId,

    units: estimatedUnits,

    balances,

    allowPostpaidFallback: billingContext.allowPostpaidOverage,

    idempotencyKey,

  });

  if (!reservation.allowed) {

    return {

      status: "denied",

      reason: reservation.reason,

    };

  }

  try {

    const result = await runModelOrAgent(customerId);

    const actualUnits = result.unitsConsumed;

    await reconcileReservation({

      reservationId: reservation.id,

      actualUnits,

      allowPostpaidFallback: billingContext.allowPostpaidOverage,

      idempotencyKey,

    });

    return {

      status: "completed",

      result,

    };

  } catch (error) {

    await releaseReservation({

      reservationId: reservation.id,

      idempotencyKey,

    });

    throw error;

  }

}

‍

The balance priority determines how every unit of usage is funded. Without one ordered rule shared across the request path, ledger, customer portal, and billing export, different systems can apply different balances and produce different totals for the same usage.

Reservation and reconciliation keep that order reliable under concurrency. The reservation protects the available balance before execution, and reconciliation then replaces the estimate with actual usage, releases unused funds, and applies any approved fallback.

Two hybrid billing examples in AI products

Hybrid billing already appears in AI coding products, where a recurring plan may include monthly usage but longer or more complex agent workloads create additional charges. Cursor and Replit show two versions of this model.

Their published pricing explains what customers buy and consume, and the engineering analysis below describes what a system supporting those rules must resolve at runtime.

Cursor: Subscription usage with on-demand overages

Cursor combines a recurring subscription with an included monthly model-usage allowance. Once that allowance is exhausted, customers with on-demand usage enabled can continue working, with the additional consumption billed in arrears.

Cursor also separates usage into model pools and prices third-party model consumption according to the selected model.

The critical transition can happen mid-session. An agent request may begin with included usage available and finish after the account moves into on-demand billing.

The system must record where that boundary occurred, prevent concurrent sessions from consuming the same remaining allowance, and enforce any configured spending limit before approving additional usage.

Replit Agent: Subscription credits with usage-based consumption

Replit’s paid plans include monthly credits that can fund Agent usage and other platform services. Replit Agent uses effort-based pricing, so a larger task can consume more credits than a simple change because its cost reflects the time and computation required.

Replit has also documented usage-based charges beyond plan allotments.

The difficult part is settling a variable-cost agent task because the final charge may be unknown when execution begins.

A hybrid billing system may need to reserve an estimated amount, track consumption during the task, reconcile the final cost, and decide whether any excess consumption draws from additional credits, moves to paid usage, or stops at a budget limit.

These examples are more credible than invented scenarios because they show hybrid billing already operating in AI coding products, where long-running agents and variable model costs make real-time balance decisions necessary.

Common hybrid billing implementation failures

A handful of mistakes show up across most in-house hybrid billing builds:

• Leaving the balance consumption order undefined, so different parts of the system apply it differently.
• Running separate usage counters for product access and invoicing, which drift apart over time.
• Letting concurrent requests overspend the same wallet before a reservation catches it, or charging estimated usage without ever reconciling it against what actually ran.
• Burning promotional credits after purchased ones instead of before, or applying plan changes without versioning so no one can tell what rule applied on a given date.
• Treating retries as new billable usage, and failing to release a reservation when a request fails.
• Enforcing a user-level limit against an organization-level balance.
• Moving customers into postpaid overages with no approval step, or hiding balances and overage status until a large bill arrives as a surprise.
• Letting the invoicing system act as the runtime source of truth for access decisions it was never built to make in real time.

A few of these compound. If you leave the consumption order undefined and hide overage status from the customer, a billing dispute becomes a debugging session instead of a quick lookup.

Hybrid billing in-house vs. dedicated infrastructure

Most teams start hybrid billing with a few tables and a middleware check. For one subscription, one allowance, and one overage meter, that is often the right decision. The logic stays understandable, and the team keeps full control.

The strain appears gradually. Maybe a customer needs a second wallet, enterprise usage needs to roll up across departments, or several agents start drawing from the same balance.

Soon, the original billing logic is also responsible for concurrency, contract rules, audit history, and request-time access decisions.

An in-house system usually needs another review when:

• One request can move across included usage, prepaid credits, commitments, and postpaid overages.
• Shared balances must support concurrent agents, reservations, refunds, and automatic top-ups.
• Pricing and limits apply at different levels, such as the organization, department, team, and agent.
• Customer-specific contracts, data residency, and audit requirements make every decision harder to reproduce.

At that point, the team is maintaining more than billing logic. It is operating a balance engine, policy layer, ledger, and real-time control system.

The original decision to build in-house may still have been correct. The better question is whether that system still fits the product you operate today.

How to enforce hybrid billing rules in real time

Enforcing hybrid billing in real time requires one control layer to resolve included usage, prepaid credits, overages, and access limits before each request runs.

Without it, one service may approve the request, another may update the balance, and the billing system may calculate a different result later.

Stigg provides the runtime infrastructure to resolve those commercial rules before AI usage happens, while keeping billing connected downstream.

• Centralized product catalog: Store plans, included allowances, credit grants, limits, overage rules, and effective dates in one versioned configuration. Teams can update pricing rules without deploying application code.
• Request-time enforcement: Evaluate entitlements, wallet balances, and overage permissions synchronously before a model call or agent workflow begins.
• Credits and wallet ledger: Record grants, reservations, consumption, refunds, expirations, and adjustments as auditable entries rather than relying on a decrementing balance.
• Multi-level usage governance: Apply pricing and controls across users, agents, teams, departments, workspaces, and organizations without forcing every rule into one account-level scope.
• Scale and low-latency enforcement: Resolve entitlements from a local cache so decisions stay fast under load, with self-hosted (BYOC) deployment for teams with data-residency or throughput requirements.

On a cache hit, entitlement checks resolve instantly from local Redis; on a cache miss, the Sidecar fetches from Stigg's Edge API at around 100ms, with a configurable timeout

• Billing stack integration: Send finalized usage and overages to the existing billing provider. Stigg handles what usage is allowed, while the billing system handles payment and invoicing.
• Modular adoption: Start with metering, entitlements, the credits engine, or a single SDK integration. Teams can use each component independently, then adopt more of the usage runtime as requirements grow.

Without a shared request-time control layer, concurrent AI usage can drain the wrong balance, trigger an unapproved overage, or continue after a limit should have stopped it.

Explore the Stigg Docs to see how the architecture supports hybrid credits, entitlements, metering, wallets, and real-time usage enforcement.

FAQs

1. Can hybrid billing combine prepaid and postpaid usage?

Yes, hybrid billing can combine prepaid and postpaid usage. A common structure has customers draw down a prepaid balance first, then move into postpaid overage billing once that balance is exhausted, often with an approval step in between for enterprise accounts.

2. What happens when included AI credits run out?

Once included AI credits run out, the system typically moves to the next balance in the consumption order, purchased credits, a committed balance, or a postpaid overage rate, depending on what the account has configured.

What happens next needs to be defined explicitly rather than left to whichever system checks the balance first.

3. How does hybrid billing handle unused credits?

The way hybrid billing handles unused credits depends on the credit type and its configured rollover rules. Some credits expire at the end of a billing period, some roll over into the next period, and some carry a fixed expiration date set at the time they were granted.

Purchased and promotional credits often follow different rules on the same account.

4. Can customers have different credit expiration dates in one plan?

Yes, customers can have different credit expiration dates in one plan.

Included, purchased, and promotional credits can each carry their own expiration and rollover rules within the same plan, which is why a shared burn order (which balance gets consumed first) matters as much as the expiration rules themselves.

5. How are refunds handled in a hybrid billing model?

In a hybrid billing model, a refund typically needs to reverse the specific balance it drew from, whether that's releasing a reservation, crediting back a prepaid balance, or adjusting a postpaid overage line before it's invoiced. 

Refund handling should carry the same idempotency and audit trail as the original charge, so a reversed transaction doesn't get counted twice.