The short answer: Chargebee can do metered billing, and for a lot of products that is genuinely enough. It stops being enough at a threshold most teams cross without noticing: when usage events arrive faster than a subscription platform was designed to absorb them, when retries create duplicates, and when customers expect to see their spend before the invoice.
The question is not whether Chargebee supports usage charges. It does. The question is whether your event volume and your customers' expectations put you on the wrong side of that threshold.
People arrive at this question from a specific place: they already run Chargebee for subscriptions, they have just shipped an AI feature that bills on tokens or requests, and they would very much prefer not to add another vendor. That is a reasonable instinct. Adding billing infrastructure you do not need is expensive in a way that does not show up on an invoice.
So here is the honest boundary.
What metered billing means in a subscription platform
In a subscription platform, metered billing usually means this: you report a quantity against a subscription item, the platform accumulates it over the billing period, and at period end it prices that quantity according to the plan and puts it on the invoice. Tiered, volume and stairstep pricing are typically supported. For a product where a customer consumes tens or hundreds of units a month, this works exactly as advertised and needs no additional machinery.
The assumptions baked into that design are worth stating out loud, because they are the assumptions that break:
- Usage arrives in manageable quantities, often pre-aggregated by you before it is reported.
- Reporting the same usage twice is your problem to prevent, not the platform's to detect.
- The authoritative number appears at invoice time, not continuously.
- Recomputing a period is rare and cheap.
An AI product violates all four, usually in its second year.
The four thresholds
1. Volume
A chat product can generate a usage event per request, and an agentic product generates one per tool call, which means a single task can produce dozens. Multiply by an enterprise customer's daily activity and you are no longer reporting quantities, you are ingesting a stream. Subscription platforms are built to handle a modest number of writes against a subscription, not a firehose. The usual workaround is to pre-aggregate in your own systems and report a daily total, which works, right up until someone disputes a number and you have to explain how it was derived.
2. Duplicates and late events
Your producers retry. Networks fail mid-request, workers restart, queues redeliver. If the same event is reported twice, a naive accumulator bills it twice, and the customer notices before you do. Reliable metering needs idempotency keys and a deduplication window, plus a defined policy for events that arrive after the period closed. This is genuinely hard and it is not what a subscription platform is for. We went through the mechanics in idempotent usage metering.
3. Real time visibility
AI customers expect to see spend as it accrues, because they have been burned. The bill shock stories of the last two years trained an entire market to distrust invisible consumption. If your users need a live balance or a spend cap that actually stops work, you need continuous aggregation, which is a metering capability rather than an invoicing one. Hard caps in particular are a different problem from alerts, as we covered in hard spend caps and kill switches.
4. Reconciliation
At some point your finance team will ask why the invoice total differs from the vendor bill you are passing through, or from what the dashboard showed. Answering that requires the raw events, retained, queryable, and tied to the aggregate that produced the invoice line. If the raw events only ever existed in your application logs, that answer takes days.
A decision table
| Signal | Chargebee metered billing is fine | You need a metering layer |
|---|---|---|
| Events per customer per day | Hundreds | Tens of thousands and up |
| Who aggregates | You, daily, and it is simple | Continuously, with correctness guarantees |
| Duplicate risk | Low, single reliable producer | Retries, multiple producers, queues |
| Customer expectation | Sees usage on the invoice | Expects a live number and caps |
| Dispute handling | Rare, resolved by hand | Needs event-level evidence on demand |
The middle path most teams end up on
You do not have to replace Chargebee to fix this, and most teams should not. The common production shape is to keep the subscription platform for what it is good at, the contract, the plan lifecycle, dunning, invoicing, and put a metering layer in front of it that owns the counting. The metering layer ingests raw events, deduplicates them, aggregates them, exposes the live number to your customers, and hands a single trustworthy quantity per period to the subscription platform.
That boundary is clean, it keeps your invoicing where your finance team already works, and it puts the hard correctness problem in a system designed for it. It also means the answer to "do we rip out Chargebee" is usually no.
The honest take
If your AI feature is a modest add-on to a seat-based product, use the metered billing you already have and spend the engineering effort elsewhere. Adding a metering layer to a product generating a few thousand events a month is solving a problem you do not have.
If consumption is becoming the business, the counting stops being a billing detail and becomes the product's financial spine. The warning signs are consistent and easy to spot: a monthly close that keeps getting slower, invoice totals that need explaining, and an engineer with a spreadsheet reconciling numbers by hand. When those appear, the answer is not a better report. It is that the counting needs to live somewhere built for counting.