OpenMeter

Metering

Open-source real-time metering on Kafka with idempotent ingestion, backfills, and entitlement enforcement.

Overview

OpenMeter is an open-source usage metering system for engineering teams that need to count product usage accurately at high volume — API calls, tokens, compute seconds — and expose it to billing, dashboards, and entitlement checks in real time. Built on a Kafka-based streaming pipeline, it deduplicates events, aggregates them into meters, handles late-arriving and corrected data, and answers balance queries fast enough to gate a request. It appeals to AI and infrastructure companies that want to own the metering layer rather than couple it to a billing vendor.

Capabilities on the RevOps map

Which of the capability map's modules OpenMeter covers — each links to the module's own page, with every tool that supports it.

Module Phase Depth Note
Fulfill & Bill
Usage Event Ingestion (API) Consume & Meter Core
Streaming Ingestion (S3/Kafka/SFTP) Consume & Meter Core Kafka-native pipeline built for high-throughput event streams.
Idempotency & Deduplication Layer Consume & Meter Core
Aggregation & Rollups Consume & Meter Core
Event Correction & Replay Consume & Meter Supported
Late-Arrival Event Handling Consume & Meter Supported
Entitlement Management (Feature Flags, Caps, Access) Fulfill & Activate Supported Real-time balance and feature checks enforced from usage data.

Critical requirements scorecard

Scored against UsagePricing's Usage-based billing & metering rubric v1.0 (0 weak · 1 adequate · 2 strong), assessed July 2026. Requirements we couldn't verify from public material stay unscored — never guessed. Read the method.

Requirement Score Why
Real-time balances & drawdown

Can a customer (and your product) see an accurate credit or spend balance mid-period?

2 · Strong Real-time balances and entitlements are the core product.
Correction & re-rating

When a meter was wrong, can you fix history without hand-editing invoices?

1 · Adequate Reprocessing over the event store within operational bounds.
Commits, credits & custom rate cards

Can it express how enterprise AI deals are actually signed?

1 · Adequate Credits and entitlement grants; negotiated commit contracts are early.
Billable-metric flexibility

Can finance define a new meter without re-instrumenting the product?

1 · Adequate Meter definitions over streamed events with standard aggregations.
Invoice & proration correctness

Do mid-cycle changes, consolidation, and multi-currency come out right?

1 · Adequate Billing features are young next to the metering core.
Rev-rec & ERP handoff

Can the numbers survive an audit once they leave the billing system?

0 · Weak Exports only — finance tooling is out of scope today.
Ingestion scale & integrity

Does the meter stay correct at production event volumes?

2 · Strong Streaming-first, open-source metering built on event infrastructure.
Price-change velocity

How fast can you ship a pricing change safely?

1 · Adequate Plans decoupled from meters; no simulation layer.

What makes it different

Two things stand out: it is genuinely open source, so the meter — the system of record for what customers consumed — can live in your own infrastructure under your own control, and it treats real-time entitlement enforcement as a first-class use of usage data rather than a billing afterthought. That combination suits teams whose product must check limits on the hot path.

How OpenMeter prices

Open-source core plus usage-priced cloud. Self-hosting is free; cloud is priced on events and features.

Who runs OpenMeter in the corpus

1 of the companies the Blueprint tracks — from public job posts, engineering blogs, and filings. Every claim links to its evidence on the company page.

Frequently asked questions

Is OpenMeter a billing system?

No — it is the metering layer underneath one. It produces accurate, deduplicated usage totals and balances; rating those into prices, invoices, and taxes happens in a billing platform or your own code downstream. That separation is deliberate: meters outlive pricing models.

Why not just count usage in my application database?

Counting is easy until it has to be correct: duplicate events from retries, late data, backfills after an outage, and real-time balance reads at scale all break the naive approach. A dedicated metering pipeline exists to make usage numbers you can bill on and enforce limits with.

Closest alternatives

By overlap on the capability map — computed, not curated.

Back to stack & tools