If you are shipping anything AI-shaped — an agent, an API, a copilot — the pricing question arrives before the product is even good. You can't charge $20 a seat for something whose marginal cost is a stack of tokens that varies 100x between a light user and a heavy one. So you reach for usage-based billing: meter what people actually consume, and invoice against it.
For two years the answer to "who runs that meter for me" was one of three companies: Metronome, Orb, or Lago. In the first half of 2026, that shortlist quietly changed shape.
The one thing that actually changed in 2026#
Two of the three are no longer independent.
- Stripe completed its acquisition of Metronome on 14 January 2026 — a deal widely reported around $1B. Metronome is the metering engine behind usage billing at OpenAI, Anthropic, Databricks, and NVIDIA, charging on tokens and GPU-seconds.
- Adyen announced on 11 June 2026 that it will acquire Orb for $335 million, a deal expected to close 1 July. Orb's pitch was storing the full usage event-stream and decoupling ingestion from invoicing.
Inside six months, the two leading independent metering layers were both bought by payment giants. Metering isn't a standalone category anymore — it's being pulled into the payment rails.
That leaves Lago — open-source, AGPL-3.0, self-hostable — as the last big neutral option. Which reframes the whole decision. It used to be "which SaaS has the nicest API." Now the first fork is architectural: does your billing logic live inside a payment company's cloud, or does it live next to your own product?
What "usage-based" actually means#
Strip the vendors away and every one of these does the same three jobs:
- Ingest events. Your app emits a metered event —
tokens_used: 5120,agent_run: 1,gpu_seconds: 42— tagged to a customer. - Aggregate against a price. The platform rolls events up over a billing period and applies your pricing (per-unit, tiered, package, credits).
- Invoice and collect. At cycle end it reconciles the total into an invoice and hands off to a payment processor.
The invoice-based platforms (Metronome, Orb, Lago) capture events during the cycle and settle at the end. That's the right default. Real-time balance platforms that authorize-and-debit at the moment of usage exist too, but you only need them if you're pre-paid-credits or hard-cutoff by design.
The three you'll shortlist#
| Platform | Billing model | Hosting | Best for |
|---|---|---|---|
| Metronome (Stripe) | Invoice-based, high-cardinality metering | Managed, inside Stripe | Infra sold on enterprise contracts; token & GPU-second billing |
| Orb (Adyen) | Invoice-based, full event-stream stored | Managed, moving into Adyen | DX-first usage pricing, backtesting, scale |
| Lago | Real-time, event-based | Self-host or Lago Cloud | Control, data residency, no lock-in (AGPL) |
So which one?#
Metronome if you're selling infrastructure on negotiated enterprise contracts, you already live in Stripe, and you need metering that shrugs at high-cardinality event floods. Being inside Stripe now means one less integration seam between meter and money.
Orb if you want the most polished developer experience for complex usage pricing and the ability to backtest a price change against real historical events before you ship it. The Adyen acquisition is the asterisk: great near-term, but you're now betting on a payments roadmap, not an independent one.
Lago if independence, data residency, or cost control outweigh not-running-infra. It's the only one you can docker compose up and own end-to-end — the escape hatch from exactly the consolidation the other two just went through. The tradeoff is real: you operate it, and AGPL-3.0 is a copyleft license you read carefully before building a commercial product around it.
Build the meter before you pick the vendor#
Here's the part every migration horror story has in common: the company picked the vendor first and defined the billable event second.
Do it the other way. Before you sign anything:
- Define the billable event precisely. "An agent run" — does a retry count? A failed run? A sub-agent? Write it down. This definition ends up in a customer contract; ambiguity here becomes a refund later.
- Make ingestion idempotent. Give every event a stable key so a network retry doesn't bill twice. This is non-negotiable and it's your job, not the vendor's.
- Decouple metering from invoicing. Store the raw event stream yourself. Then a price change is a re-aggregation, not a re-instrumentation — and switching vendors is an export, not a rebuild.
Do that, and the vendor question gets a lot smaller — because you've made it swappable. In a market where two of your three finalists changed owners in a single half of a year, swappable is the only safe thing to be.
