How does Lago meter AI token usage and turn it into invoices?

Lago meters AI token usage by counting input, output, and cached tokens separately, then maps each metered quantity to a price and rolls the results into invoice line items. The platform is built for usage, subscription, and hybrid pricing, and its own materials frame it as an "AI-native billing platform" used by companies including CoreWeave, Mistral AI, and PayPal. If your product bills on tokens — or on tokens plus a subscription — this is the mechanism you'd be evaluating.

Separating token types at the meter

The first step is not "count tokens" but "count tokens by kind," because input, output, and cached tokens usually carry different prices. Lago's published example meters three streams independently:

Total: 1.19M tokens metered, invoice total $935.75. Notice that output tokens cost more than input tokens at a smaller volume, and cached tokens are cheapest per unit — which is exactly why the meter has to keep them apart rather than summing to a single "tokens" number. The same page also shows an 18-day stacked bar chart where daily usage grows from 24,000 to 135,000 tokens, with each token type plotted as its own band.

The model mix column is worth pausing on. It implies usage can be attributed not just to a token type but to the underlying model, so a single invoice line can reflect that 50% of input tokens ran through one model and 30% through another.

From metered usage to invoice line items

Once usage is metered, the path to an invoice is: quantity × price per unit → line item → subtotal → credits → total due. Lago's example invoice (INV-2026-0042, "AI usage · June") shows this directly:

• Input: 800K tokens → $800.00
• Output: 240K tokens → $720.00
• Cached: 160K tokens → $40.00
• Subtotal: $1,560.00
• Credits applied: $0.00
• Total due: $1,560.00

A second example on the same page runs the same structure with a credit balance in play: 1.2M tokens metered, a spend alert at $1,500, $500 in prepaid credits applied against a $1,560 invoice, leaving $1,060 due. So the invoice isn't just a sum of usage — it's usage minus whatever credit the customer has already paid for.

Controls that sit between usage and revenue

Two mechanisms in the published material act as guardrails rather than billing math:

Prepaid credits. A customer balance is tracked (the example shows a balance of $0.00 credits with "No expiration date"), and credits are applied to the invoice before the amount due is calculated. This is how you'd let customers pre-fund usage instead of invoicing after the fact.

Spend alerts. The example fires an alert when usage reaches $1,500. That's a threshold notification, not a hard cap — the invoice still totals $1,560. If you need to stop usage rather than warn about it, that's a separate design decision you'd have to make on your side.

The engineering-to-finance path

Lago describes the split of concerns as: "Engineering gets granular usage data. Finance gets a clear path from consumption to revenue." Concretely, the same metered data feeds two audiences — a usage view (tokens over time, by type) and a revenue view. The page shows a Finance Assistant turning a plain request ("Get the MRR for the past quarter. Segment it per customer.") into a revenue chart and report, with a quarterly MRR figure of $500,100.00 and a breakout across new, expansion, and lost MRR.

That matters for evaluation: if your token metering lives in one system and your revenue reporting lives in another, you're reconciling by hand. Here the claim is that both read from the same metered source.

What to check before adopting it

• Does your pricing vary by model, not just token type? The example attributes tokens to specific models, so confirm your model mix can be represented.
• Do you need hard usage caps? The published controls are credits and spend alerts; a hard stop isn't shown.
• Is your pricing hybrid? Lago states it handles usage, subscription, and hybrid pricing, which is the common shape for AI products with a base fee plus overage.
• Where does the invoice land? The material covers billing and invoicing; it doesn't list payment platforms, so confirm your payment flow separately.

For the underlying question of what the platform is and how the open-source model works, see the related explainer on Lago's open-source billing infrastructure.