TL;DR: Flexprice is the credits-native option: AGPL-3.0, self-hostable, publicly priced at $500/month Starter and $1,000/month Premium, with a Postgres–Kafka–ClickHouse–Temporal stack behind it. It is the best data-model fit if your pricing is a prepaid wallet, and the thing to weigh against it is maturity rather than capability. The alternatives are Lago, OpenMeter, Amberflo, Metronome, Orb, Chargebee, or building the credit ledger yourself on top of a plain meter — which is more work than it looks.
Flexprice occupies a narrower position than most of this market, and the narrowness is the point: it treats credits as the primary object rather than as something bolted onto a subscription. Recurring grants on plan renewal, one-time promotional grants, prepaid top-ups, expiry windows per grant, rollover caps. If that list reads like your pricing page, you are the intended customer.
This page is for the case where it is not quite right, and for working out which part is not right — because "credits are hard" and "this vendor is wrong" are different problems.
What it actually is
- Licence: AGPL-3.0, self-hostable. Copyleft with a network clause, so embedding a modified version in a service you sell is a legal conversation, not a free choice.
- Stack: PostgreSQL, Kafka, ClickHouse and Temporal — the same shape Lago arrived at, which is a reasonable signal that it is the shape this problem has.
- Scale claims: over 20 billion usage events per month processed, with an ingestion layer rated at a million events per second.
- Pricing: published — $500/month Starter for billing, metering, wallets and a customer portal; $1,000/month Premium. In a market where nearly everyone says "book a demo", publishing a number is worth something.
The honest counterweight: it is younger than Lago and has fewer public references at enterprise scale. That is not a defect, it is a stage. Whether it disqualifies Flexprice depends entirely on whether your procurement needs logos.
Work out which complaint you have
| The complaint | The honest answer |
|---|---|
| "We need more mature invoicing, tax and dunning" | Chargebee, or Stripe Billing as the rail with a meter in front. |
| "We are not actually credits-based" | Lago. Broader scope, longer track record, same licence. |
| "AGPL does not work for how we ship" | OpenMeter, which is Apache 2.0 — but it stops before the invoice. |
| "We need enterprise references and a big-vendor contract" | Metronome or Orb — noting that both are now inside payment companies. |
| "We only need the counting; we have a biller" | A standalone metering layer. You are buying too much product. |
| "Self-hosting turned out to be a lot" | Not a Flexprice problem. Kafka, ClickHouse and Temporal is the going rate for this workload anywhere. |
The alternatives
Lago — broader, older, same licence
Full billing across subscription, usage, prepaid and hybrid, AGPLv3, processor-agnostic, around 9,500 GitHub stars and a long release history. The default comparison, and the right one if credits are part of your pricing rather than the whole of it. Same caveat as everywhere: the cheap self-hosted stack is not the one behind the throughput figures.
OpenMeter — Apache 2.0, metering only
Kong's since September 2025. Meters and does entitlements and balances, then hands off for invoicing. Its balances can stand in for simple credits, but they are not a full ledger — no grant identity, no per-grant expiry semantics out of the box. The trade is a permissive licence and a narrower, cleaner scope.
Amberflo, Metronome, Orb, Chargebee
Amberflo for metering with a cost-governance slant. Metronome for high-volume multidimensional pricing, now a Stripe product. Orb for sophisticated managed billing, now Adyen's since 1 July 2026. Chargebee when usage is the minority of the bill and invoicing maturity matters more than metering depth.
Building the credit ledger yourself
Tempting, because "a balance that goes down" sounds like an afternoon. It is not, and the gap between the two is where most home-grown credit systems fail:
- Grants have identities. A monthly allowance, a promo grant and a purchased top-up expire differently and refund differently. Merged into one integer, you cannot answer "what expires at month end".
- Drawdown order is a policy decision. Expiring credits first or purchased first? The difference is money, and the customer can see it.
- Concurrency will go negative. Ten parallel agent calls against a balance of five all pass a naive check. Reserve, allow a bounded overdraft, or hard-stop — and note that a hard stop mid-task is worse for the customer than a small overdraft.
- Refunds run backwards. A failed generation needs its credits back, so the debit must be individually addressable and reversible. A decremented counter is not.
- Expiry is the top complaint about credit pricing. Whatever the policy is, it has to be visible in the customer's dashboard before it fires, not in the terms afterwards.
All of it is cheap to build up front and expensive to retrofit, because the retrofit needs history the integer never kept. That is the strongest argument for a credits-native vendor — see prepaid credits: drawdown and expiry.
Where UsageBox fits, stated plainly
It does not compete with Flexprice. UsageBox is a metering layer — idempotent ingest, a documented dedupe window, late-event handling, monthly rollups — with no rating engine, no invoicing and no credits. If credits are your pricing model, Flexprice does something UsageBox does not do at all. The only overlap is the narrow case where you already have a biller and what you need in front of it is a defensible count.
The questions to ask any of them
- Can you export raw events continuously, in a documented format? Events, not invoices.
- What is the dedupe window, in seconds, and is the key scoped per account? "It's idempotent" is not an answer.
- Do grants keep their identity through drawdown? The question that separates a ledger from a counter.
- Are prices versioned? If a price edit overwrites history, no past invoice can be reconstructed.
- What happens to a balance under concurrent spend? Ask specifically. The answer is often "we have not tested that".