2.2k stars · Apache-2.0 · v1.0.0-beta.232 (2026-08-04) · Track this in Rising ↗
Real-time usage metering with entitlements and balances — built for products whose unit of cost is a model call.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 26 Oct 2026, the same day before this check.
Latest release v1.0.0-beta.236 on 9 Oct 2026.
Public since June 2023, a little over 3 years.
2,411 stars and 230 forks.
450 commits and 15 new issues in the last 90 days.
36 contributors. 452 pull requests merged in 90 days.
A security policy says how to report a problem. 2 published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 27 Oct 2026 from the repository on GitHub. Covered in Edition 11.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You send it a usage event for each billable action. It aggregates those events continuously rather than at the end of the month. From that running total it answers two questions: how much has this customer used, and are they still inside their allowance. An allowance here is called an entitlement, meaning a limit attached to a customer that the software checks before letting an action through. It also keeps balances, so prepaid credit can be drawn down. Because the totals are current, a product can show a live figure such as "62 of 100 documents used", which is useful both as a warning and as a prompt to upgrade. It is aimed at products billed by tokens, requests, or megabytes. What it does not do is produce invoices or charge a card: it counts and it gates, and something else bills.
Why it matters
Who it suits. Products with a free tier and a marginal cost per use, where the allowance check happens on the hot path and has to be cheap. It also suits any product that wants to show a customer their remaining allowance inside the interface rather than in a monthly email. Skip it if the pricing is a flat fee with no limits, and skip it if invoices are the actual requirement, because that is entry 1.
Verdict. The right choice when gating matters more than billing, and a genuine gem at 2,248 stars. Two honest reservations. It is still tagged 1.0.0-beta, now at beta.236 dated 9 October 2026, so the project has not yet promised a stable interface after more than two hundred releases. And the light footprint shown in the quickstart is the development one; production wants ClickHouse and Kafka, the same weight as entry 1. Apache-2.0 is the practical advantage over Lago here: this can sit inside a paid feature without a licence conversation.
Summary (Key Points)from the README
Key features
- Usage metering: Ingests CloudEvents, attributes usage to customers, aggregates it in real time, and queries it by time window or dimension.
- Product and pricing models: Defines versioned plans, features, add-ons, and flat, recurring, per-unit, tiered, package, or dynamic prices, then assigns customer subscriptions.
- Access control: Calculates feature access and usage-limit balances for your application to enforce, with one-time or recurring entitlement grants.
- Usage billing: Rates flat and usage-based charges, manages customer credit balances and subscription changes, and runs the invoice lifecycle.
- Composable API: Offers an OSS REST API plus JavaScript, Python, and Go SDKs, so you can use the whole path from usage to invoice or only the parts your stack lacks.
- Provider integration: Sends webhooks and connects external invoicing providers, and works with the payment and tax providers you already use.
- Proven metering engine: The README says the metering engine has run in production for years and processed billions of usage events.
- Local evaluation stack: A Compose setup runs the API and workers with Kafka, ClickHouse, PostgreSQL, Redis, and Svix, and includes an `api_requests_total` meter for a first request.
Ways to install
| Platform or method | What it needs | Effort |
|---|---|---|
| Docker Compose local evaluation stack | Git and Docker with Compose | Not stated |
| Bash (curl) quickstart example | curl and the running local stack | Not stated |
| TypeScript SDK | Node.js 22+ and `npx tsx` | Not stated |
| Python SDK (preview) | Python 3.9+ and pre-releases enabled | Not stated |
| Helm chart for Kubernetes | A Kubernetes cluster | Not stated |
Important
- Beta status: Releases are beta and can include breaking changes, so review releases and migration guides before upgrading.
- Python SDK preview: The Python SDK is in preview and must be installed with pre-releases enabled.
- Not production-ready setups: The Compose stack is a local evaluation setup, not a production topology, and the Helm chart is intended for development deployments only.
- Required infrastructure: The core runtime needs Kafka, ClickHouse, and PostgreSQL. Redis is optional, and Svix is needed only when webhook delivery is enabled.
- Asynchronous processing: Event processing is asynchronous, so a metered value may not appear immediately after sending an event.
- Not a full stack: It is not a bundled operator UI, payment processor, tax engine, or general accounting system. For fixed recurring subscriptions alone, the README suggests a direct payment-provider integration is simpler.
- Data removal: Cleaning up the local stack removes the containers and their local data volumes.
Written by an AI model from the project’s README; not part of the review, and it can be wrong.
- Built for allowances and balances, not just end-of-period invoicing.
- Apache-2.0, so it can live inside a commercial product without a licence problem.
- Active and small: beta.236 on 9 October 2026, with code on 8 September 2026.
- Still a beta after 236 tags, with no promise of a stable interface.
- The production deployment wants ClickHouse and Kafka, so the quickstart understates the real cost.
- 2,248 stars and a young company behind it, which is a bet on the vendor as well as the code.
The remaining balance reads straight into the React header; the totals feed Lago or Polar for the actual charge.
git clone https://github.com/openmeterio/openmeter.git cd openmeter/quickstart docker compose up -d
