OpenMeter

Open-source metering and billing infrastructure, honestly reviewed. Focused on what you actually get when you ship your own instance.

TL;DR

• What it is: Open-source (Apache 2.0) metering and billing platform — think Stripe Billing, but the event pipeline lives on your server and you define exactly what counts as a billable unit [3][5].
• Who it’s for: Engineers and technical founders at AI, API, or DevTool companies who charge customers by usage (tokens, API calls, compute time) and are tired of building metering from scratch or paying Metronome/Amberflo margins [3][4].
• Cost savings: Competitors like Metronome and Amberflo are closed-source, enterprise-priced SaaS. OpenMeter self-hosted runs on your own infrastructure under Apache 2.0 — no per-event fees, no vendor markup on your own usage data [3].
• Key strength: End-to-end pipeline from event ingestion (CloudEvents format) through real-time aggregation (ClickHouse) to billing, entitlements, customer-facing dashboards, and Stripe integration — in one deployable stack [README][5].
• Key weakness: 1,875 GitHub stars is modest for infrastructure this critical. The project was acquired by Kong, Inc, which introduces strategic uncertainty. Pricing documentation is thin. Not a fit for non-technical founders who don’t have engineers to wire it in.

---

What is OpenMeter

OpenMeter is a real-time event metering and billing engine. You send usage events — an OpenAI API call, a serverless function invocation, a minute of compute time — into it via a REST API in CloudEvents format. OpenMeter aggregates those events into meters using configurable functions (SUM, COUNT, AVG, MIN, MAX), then connects those meter values to billing plans, entitlements, invoice generation, and customer dashboards.

The company was founded by Peter Marton, a former Stripe staff engineer who ran into the exact problem OpenMeter solves while building billing infrastructure there. His co-founder is András Tóth, ex-Cisco [3]. They went through YCombinator in 2023, raised a $3M seed round, and launched on Product Hunt in November 2023 where they hit #3 Product of the Day with 451 upvotes [3][4]. The project has since been acquired by Kong, Inc — the company behind Kong API Gateway — which positions OpenMeter as Kong’s metering layer for API monetization.

Under the hood it’s a Go codebase with a stack purpose-built for volume: PostgreSQL via the Ent ORM handles billing state, subscriptions, and entitlements; ClickHouse handles the high-throughput aggregation workload; Kafka or Redpanda handles event streaming [README][3]. The collector is built on top of Redpanda Connect (previously Benthos), which means it inherits a wide range of inputs — API gateways, Kubernetes, OpenTelemetry, Prometheus, LangChain, Postgres, S3, and more — and strong delivery guarantees [2].

The pitch in the README is direct: “Metering and Billing for AI, API and DevOps.” The homepage says “Fastest Way to Ship Usage-Based Billing.” Both are honest. This is infrastructure for companies that need to turn events into invoices and want to avoid building the pipeline themselves [README].

---

Why people choose it

The context for OpenMeter’s existence is that usage-based pricing (UBP) has become the dominant model for AI and API products. OpenView reported roughly 60% of SaaS businesses now offer some form of it [3]. The problem: building the metering infrastructure to support UBP correctly — real-time, accurate, at scale, feeding both billing systems and customer-facing dashboards — is a 3–6 month engineering project if you do it yourself [4].

Versus building in-house. This is the primary comparison OpenMeter wins. The Product Hunt founder comment from Peter Marton [4] describes what they’re replacing: custom stream processing, APM hacks (which are inaccurate due to sampling), expensive time-series storage, and manual reconciliation with billing providers. The Trigger.dev founder quote on the homepage captures it: “It flawlessly handles us sending a massive amount of events and syncing the metering data with Stripe. We use entitlements to restrict our free tier and use the API to power our usage dashboards.” That’s months of engineering work, externalized.

Versus Metronome, Amberflo, and M3ter. These are the direct competitors — all closed-source, all billing-first, all enterprise SaaS pricing. Marton’s framing in TechCrunch [3]: “Competitors in the usage-based space only cater to the revenue teams with a closed source, billing-first approach. OpenMeter focuses on the new generation of AI companies.” The claim isn’t just about price — it’s about composability. Metronome and M3ter assume you’ll replace your entire billing stack on day one. OpenMeter is designed to be adopted incrementally alongside existing infrastructure [3].

Versus Stripe Billing directly. Stripe is the obvious default for early-stage founders. It handles subscriptions and invoices well. What it doesn’t handle is the upstream metering problem: collecting millions of granular usage events per second, deduplicating them, aggregating them in real time across multiple dimensions, and making that data available both to Stripe and to your customers’ dashboards simultaneously. OpenMeter sits upstream of Stripe and feeds it [5][README].

On open source. The Apache 2.0 license is a genuine differentiator. Not “source available,” not “Fair-code,” not a restrictive BSL — Apache 2.0 means you can self-host, embed in your own product, or resell it without a commercial agreement [README]. For companies building billing infrastructure into a multi-tenant platform, this matters.

---

Features

Based on the README and technical documentation:

Event ingestion and meters:

• CloudEvents format for all ingested events [README][2]
• Simple REST API: one POST /api/v1/events call, one event [README]
• Flexible meter definitions: SUM, COUNT, AVG, MIN, MAX aggregations [README]
• Real-time queries: sub-second read latency on aggregated usage [4]
• Window-based querying (hourly, daily, custom periods) [README]

Billing and subscriptions:

• Usage-based billing — generate invoices directly from meter values [README]
• Tiered, graduated, and flat-fee pricing support [README]
• Product catalog: plans, add-ons, features, rate cards [README]
• Mid-cycle subscription changes with prorating and alignment [README]
• Automated invoice lifecycle management [README]
• Prepaid credits with priority-based burn-down and expiration [README]

Entitlements and limits:

• Real-time usage quotas per feature with balance tracking [README]
• Boolean feature flags [README]
• Grace periods [README]
• Low-latency limit enforcement — described as usable at the edge [homepage]

Customer-facing:

• Token-based self-service customer portal — customers see their own usage [README]
• Embeddable React hooks for usage dashboards in your product [4][5]

Notifications:

• Webhook-based alerts with configurable rules [README]
• Threshold triggers for usage and billing events [README][4]

AI/LLM-specific:

• First-class LLM cost tracking: meters AI token usage and computes model-specific costs [README]
• LangChain collector out of the box [2]
• Specifically cited by users for OpenAI/ChatGPT token metering [homepage]

Collector ecosystem:

• Built on Redpanda Connect — connects to Kubernetes, OpenTelemetry, Prometheus, Postgres, S3, ClickHouse, Nvidia, Run:ai, and more [2]
• Plugin architecture for extending collector functionality [2]
• Available as binary, container image, or Helm chart [2]

SDKs: Go, JavaScript/Node.js (@openmeter/sdk), Python (openmeter on PyPI) [README]. OpenAPI spec available for any other language.

Infrastructure features: Docker Compose for local dev, Helm chart for Kubernetes, SOC 2-compliant managed cloud option, RBAC and SSO on cloud tier [README][homepage].

---

Pricing: SaaS vs self-hosted math

Pricing transparency is one of OpenMeter’s weaker points. The TechCrunch article from March 2024 noted pricing was “still being worked out” [3]. The current pricing page is not detailed in the provided data, so specific tier numbers are not available here — check https://openmeter.io/pricing directly.

What is clear from the public record:

OpenMeter Cloud: There is a free tier to start, with managed cloud hosted by Kong. The homepage says “Start for free and begin metering and billing in minutes” [README]. Enterprise and custom deal pricing via sales.

Self-hosted (Community Edition): Apache 2.0 license, $0 software cost [README]. You bring your own infrastructure:

• ClickHouse instance (the main cost driver at scale — ClickHouse Cloud starts ~$0.02/GB storage)
• PostgreSQL (cheap, easily managed)
• Kafka or Redpanda (can use managed Redpanda Cloud or self-host)
• Application server: 2–4 GB RAM VPS is likely enough for early-scale workloads

Competitor comparison for context: Metronome raised $43M and targets enterprise customers [3]. Amberflo and M3ter are similarly positioned. None of them publish transparent per-event pricing publicly, but they are enterprise SaaS — expect five-figure annual contracts at meaningful scale.

The math that matters: If you’re an AI startup routing 10M events per day through a billing pipeline, the difference between paying percentage-of-revenue or per-event fees to a closed SaaS vendor versus running your own Apache 2.0 stack is significant. The Requestly co-founder quote: “What used to be complex manual work now runs smoothly in the background.” The complexity cost is real — OpenMeter offloads it — but so is the vendor cost if you use the managed alternatives.

---

Deployment reality check

The quickstart is genuinely quick. Three commands to a running local instance:

git clone git@github.com:openmeterio/openmeter.git
cd openmeter/quickstart
docker compose up -d

Then a single curl to ingest your first event and another to query it [README]. For local development and proof-of-concept, this is as smooth as it gets.

What you need for production:

• Kubernetes cluster (Helm chart provided) or managed equivalents [README]
• ClickHouse — either self-hosted or managed (ClickHouse Cloud, Altinity). This is the part with the highest operational surface area
• PostgreSQL — standard managed RDS, Cloud SQL, or self-hosted
• Kafka or Redpanda — again, managed options simplify this considerably
• TLS termination and authentication

Realistic effort: A developer comfortable with Kubernetes and Helm can get a production-grade instance running in a day. The complexity ceiling is higher than “run a Docker container on a $6 VPS” — ClickHouse + Kafka is real infrastructure. This is not a weekend project for someone who hasn’t run distributed systems before.

The Kong acquisition factor: OpenMeter is now part of Kong, Inc [homepage]. The cloud offering is hosted on Kong’s platform (cloud.konghq.com). What this means for the self-hosted path long-term is unclear. The Apache 2.0 license protects existing deployments, but community direction and roadmap visibility are now Kong-dependent. This is worth tracking for anyone planning a long-term bet on the project.

What can go sideways:

• ClickHouse is powerful but not operationally trivial. At low scale it’s fine; at high scale it requires tuning.
• The collector (Redpanda Connect) has a learning curve. The configuration is YAML-based with its own mapping language (bloblang). Non-trivial data transformations require some investment [2].
• No self-hosted documentation for the full billing stack (invoicing, customer portal) is surfaced in the provided materials — the quickstart covers event ingestion only.

---

Pros and cons

Pros

• Apache 2.0 license. Genuinely open source. Embed it, fork it, resell it — no commercial agreement [README]. Compared to closed-source competitors, this is a meaningful differentiator for companies building metering into their own platform.
• Real engineering pedigree. Built by ex-Stripe and ex-Cisco engineers who hit the exact problem firsthand [3][5]. YC-backed, $3M raised — not a side project.
• End-to-end stack in one deploy. Ingestion → aggregation → billing → entitlements → customer portal → Stripe sync. Most alternatives require stitching together multiple tools [README][5].
• LLM-native. First-class token metering, LangChain collector, model-specific cost attribution — built for AI products from the start, not retrofitted [README][2].
• Composable, incremental adoption. Designed to sit alongside existing billing infrastructure rather than demanding a full cutover [3].
• Real production users. Trigger.dev, Requestly, Lever.co are cited by name with specific use case details — not vague testimonials [homepage].
• CloudEvents standard. Using an open event format means you’re not locked into OpenMeter’s event schema [README][2].
• SDKs in three languages with OpenAPI spec for the rest [README].

Cons

• Kong acquisition uncertainty. Strategic direction is now Kong’s call, not an independent open-source community’s. The project could evolve toward Kong’s enterprise sales motion in ways that don’t serve self-hosters [homepage].
• 1,875 GitHub stars is modest for production billing infrastructure. Metronome and Lago (another open-source billing player) have stronger community signals. Small community = fewer battle-tested edge cases documented publicly.
• ClickHouse dependency raises the ops floor. This is not a stateless app with a Postgres backend. You’re committing to running ClickHouse in production, which has real operational overhead [README].
• Not for non-technical founders. There’s no managed UI for non-engineers to configure meters and plans without touching code or APIs. The target user is explicitly an engineer [4][5].
• Thin public documentation on billing features. The quickstart covers ingestion clearly. The billing, subscription management, and customer portal features are mentioned in the README but not as thoroughly documented in available sources.
• Pricing not publicly documented. For a tool that helps other companies do transparent pricing, OpenMeter’s own pricing page lacks the specifics that would let you evaluate cloud cost at scale [3].
• No dedicated UI for meter/plan configuration in the community edition appears to be managed primarily via API — which is fine for engineers but slows down non-dev product and finance teams [5].

---

Who should use this / who shouldn’t

Use OpenMeter if:

• You’re a technical founder or engineering team at an AI/API company that charges by usage and has outgrown “manually reconcile usage events in a spreadsheet and send Stripe invoices.”
• You want Apache 2.0 infrastructure that you can embed in your own multi-tenant SaaS product.
• You’re metering LLM token usage, API calls, or compute minutes and need real-time visibility for both your billing pipeline and customer-facing dashboards.
• You have or can hire an engineer comfortable with Kubernetes/Helm and aren’t afraid of running ClickHouse.
• You want to avoid Metronome/Amberflo pricing while getting equivalent metering capabilities.

Skip it if:

• You’re a non-technical founder. This is explicitly built for engineers [4][5]. You’ll need dev help to integrate and operate it.
• Your billing model is simple subscriptions or one-time payments — Stripe Billing handles that without the infrastructure overhead.
• You need a managed, hands-off cloud solution today and want full pricing transparency before committing — check the current pricing page and compare Metronome and Lago before deciding.
• You’re concerned about the Kong acquisition trajectory and need guaranteed independent open-source governance.
• Your scale is early (fewer than a few thousand customers, low event volume) — the infrastructure complexity isn’t justified yet; Stripe’s usage-based billing features or a simple event counter will cover you.

---

Alternatives worth considering

• Lago — open-source billing platform (AGPL + commercial), more focused on subscription and invoice management than high-volume event metering. Stronger self-hosted community, more transparent pricing. Pick Lago if your billing is subscription-first with light usage components; pick OpenMeter if you’re primarily a high-volume event processing problem.
• Metronome — the funded VC-backed competitor. Closed source, enterprise SaaS, raised $43M [3]. Better-resourced team and likely more polished for non-engineering stakeholders. Pick if budget isn’t the constraint and you want a vendor relationship.
• Amberflo — another closed-source usage metering SaaS. Similar positioning to Metronome.
• M3ter — SaaS metering and billing for enterprise. Closed source, sales-led.
• Stripe Billing (usage records) — if your event volume is low and your billing logic is simple, Stripe’s built-in usage-based billing features may cover you without any additional infrastructure. Limits apply at high volume.
• Building in-house — viable but expensive. The Product Hunt launch thread [4] describes exactly what you’d build: scalable ingestion, real-time aggregation, Stripe sync, customer dashboards. Plan for 3–6 months of a senior engineer’s time.

For a technical AI startup with meaningful event volume and a usage-based pricing model, the realistic shortlist is OpenMeter vs Lago vs Metronome. OpenMeter wins on Apache 2.0 license and LLM-native features. Lago wins on billing-first maturity and community transparency. Metronome wins if you want to outsource the ops entirely.

---

Bottom line

OpenMeter solves a real problem that every AI and API company eventually hits: how do you collect millions of granular usage events per second, aggregate them accurately, enforce limits in real time, bill customers correctly, and show them their usage — without a 6-month engineering detour? The technical stack (Go + ClickHouse + Postgres + Kafka) is solid, the Apache 2.0 license is genuinely open, and the founding team built this from first-hand pain at Stripe [3][4]. Real production companies use it for real billing [homepage].

The caveats are honest ones: the Kong acquisition introduces long-term uncertainty about community independence; 1,875 stars is modest for infrastructure this critical; and this is explicitly an engineering tool — non-technical founders need not apply. If you’re building an AI product, charging by tokens or API calls, and your current metering story is “we query our logs every night,” OpenMeter is worth a serious evaluation. If you’re a solo founder without a backend engineer, come back when you have one.

---

Sources

1. Product Hunt — OpenMeter: Usage Metering for Engineers (1 review, 5.0/5). https://www.producthunt.com/products/openmeter
2. OpenMeter Documentation — How It Works (Collector) — openmeter.io. https://openmeter.io/docs/collectors/how-it-works
3. Ingrid Lunden, TechCrunch — “OpenMeter makes it easier for companies to track usage-based billing” (March 12, 2024). https://techcrunch.com/2024/03/12/openmeter-makes-it-easier-for-companies-to-track-usage-based-billing/
4. Hunted.space — OpenMeter Product Hunt Launch Dashboard (451 upvotes, #3 Product of the Day, November 15, 2023). https://www.hunted.space/dashboard/openmeter/launches/openmeter
5. Autonoly — OpenMeter Review (4.5/5, 42 reviews). https://www.autonoly.com/ai-apps/681b870c625620af694a59c8/openmeter

Primary sources:

• GitHub repository and README: https://github.com/openmeterio/openmeter (1,875 stars, Apache-2.0 license)
• Official website: https://openmeter.io
• Pricing page: https://openmeter.io/pricing
• Documentation: https://openmeter.io/docs