TL;DR: Implement in this order — instrument, then meter, then price, then bill — and each step is verifiable before the next depends on it. The order matters more than the tooling: teams that pick a billing vendor first end up instrumenting to fit the vendor's model, and then cannot change vendor without re-instrumenting. Below is the sequence, what "done" means at each step, and the three decisions that are expensive to reverse.
AI usage billing spans four layers, and almost every implementation that goes badly went badly because they were built in the wrong order.
The sequence
1. Instrument, and emit nothing anywhere yet
Tag every model call at the point it happens with the dimensions you will need later: tenant, workspace, model, input tokens, output tokens, cached reads, and a stable identifier for the call itself.
Do this before choosing anything downstream. Events emitted from your product should describe what happened, not what your billing vendor's schema wants — that is what keeps the vendor swappable. If your instrumentation encodes a plan id or a subscription item, you have coupled your product code to a specific billing system and made leaving it a re-instrumentation project.
Done means: you can answer "how many output tokens did tenant X consume on model Y last Tuesday" from your own logs, before any billing system is involved.
2. Meter, with idempotency decided up front
Send events to a metering layer. The parts that matter, and that are painful to add later:
- An idempotency key per event, scoped per account. Not per request — per event. If event identity is derived from the request (
request_id:index), the same logical event resent in a different batch counts twice. - A known dedupe window. After it expires, the same key is treated as new. Know the number in seconds, because it determines how long a client may safely retry.
- A late-event policy, written down. An event timestamped inside a closed period either folds in, is rejected, or is attributed to now. All three are defensible; not choosing is not.
Done means: you can replay a day of production traffic twice and the totals do not move.
3. Price, as configuration rather than code
Now map meters to charges. Two rules carry most of the value:
Version prices; never edit them in place. Closing the old version with an end timestamp and writing a new one means a past period can be re-rated at the price that was in force then. Overwriting means the moment someone fixes a typo in a unit price, every invoice raised under the old value becomes unreconstructable and every dispute about them unwinnable.
Keep the billing unit separate from the measured unit. Meter tokens, because that is your cost. Bill in credits, requests or outcomes, because that is what the customer understands. With a rating step between them, changing what you charge is a configuration change instead of a product change — see tokens, credits, requests or outcomes.
Done means: a price change ships without a deploy, and you can re-run last month at last month's prices and get last month's numbers.
4. Bill
Push rated line items into whatever charges the card — Stripe Billing, Metronome, Orb, Lago, Chargebee. This is the layer to buy rather than build: invoices, tax, dunning and retries are commodity work, they are genuinely hard, and they are nobody's differentiator.
Done means: the number on the invoice can be decomposed back into the events behind it, on request, without an engineer.
The three decisions that are expensive to reverse
- Whether raw events are retained. You cannot un-sum a total. If a dispute needs the events behind a line and you kept only rollups, the answer no longer exists. Decide retention before you need it, because by definition you need it retroactively.
- Whether prices are versioned. Cheap before you have rating, nearly impossible afterwards — the data required to rebuild history is exactly what the overwrite destroyed.
- Whether the aggregation is part of the rollup's identity. If it is not, changing a meter from
sumtocountmid-period continues incrementing on top of the previous total, and a meter sitting at 4.2 million units starts reporting 4,200,001 "events". Include it in the key, or refuse the change mid-period.
Where the layers can live
Steps one and four are yours and your biller's respectively, and that does not vary. Steps two and three are the choice: one platform doing both (Lago, Metronome, Orb, Flexprice), or a metering layer feeding a separate biller.
The argument for splitting them is that metering and invoicing fail differently. A wrong invoice is visible and correctable — you issue a credit note. An event that was never counted is gone, because the traffic has passed and there is nothing to replay. The argument against is equally honest: two systems, two integrations, and a reconciliation job you now own. If your pricing is one meter and a flat overage, splitting is over-engineering.
UsageBox covers step two and part of step three — meters, a product catalog and append-only price versions — and nothing in step four. It has no rating engine, no invoicing and no credits.