FluxMeter and Orb

Orb's public materials describe usage-based billing for AI. Raw events are stored immutably; metrics are queries over those events; prices, plans, and subscriptions turn metrics into charges, and invoices follow. Orb supports pricing units such as tokens, agent runs, outcomes, or credits.

FluxMeter's public materials describe LLM token metering, customer-level usage-cost attribution, an optional pre-request hard gate, and export to billing systems. FluxMeter is not a billing UI, an invoice system of record, or a billing engine.

This page compares product categories and integration boundaries. Orb cells cite official Orb docs or Orb-published pages only. Where we couldn't confirm something, the cell says "Not verified in reviewed public docs".

If one product lacks a capability the other has, that is usually a category difference, not a quality judgment. We don't compare price, scale, or latency — not market share.

Orb is a billing platform, and it ingests and meters usage as part of billing. FluxMeter is a metering and control layer. Both use the word "metering". Orb's metering serves pricing and invoices; FluxMeter's serves customer-level attribution and admission on the LLM call path.

FluxMeter complements billing platforms rather than replacing them. It meters and attributes token usage and can gate requests, while Stripe, Lago, Orb, Metronome, or Zuora turn that usage into prices, invoices, and payments.

Interpretation: Orb turns usage into prices, credits, and invoices. FluxMeter produces trustworthy per-customer token usage and optional request-path controls.

Is FluxMeter an Orb alternative? No. It is a different layer, and FluxMeter exports usage to Orb.

Orb documents timestamped events sent to its ingestion API and stored immutably in a columnar store, without aggregation at ingest. Metrics (billable metrics) are queries over raw events, so a new metric can be calculated against history without re-ingestion. Orb also documents SQL-defined metrics and backfilling or amending events.

FluxMeter documents a single path for LLM token events: SDK or Gateway → HTTP Custody → Kafka acknowledgement → Flink usage aggregation → Redis query state → Usage API. Usage is queryable by customer, period, day, model, session, and agent span.

Orb documents prices (including tiered, package, and volume models), plans, subscriptions with customer-specific overrides, dimensional pricing, and invoices with line-item breakdowns. It also documents threshold invoicing, which issues an invoice as soon as a subscription's usage charges reach a set amount.

FluxMeter attributes usage cost using its pricing catalog: what each customer's tokens cost upstream. That is cost attribution, not usage rating against a customer's price plan. FluxMeter does not issue invoices, collect payments, or recognize revenue.

Orb's materials describe prepaid credits that let customers "buy a balance up front and draw it down as they use your product". They also cover a prepaid ledger, top-ups, and credit blocks that can have different effective and expiry dates.

Orb documents commitments in two forms. A postpaid commitment draws down against a minimum spend, and Orb bills any shortfall as a true-up. A prepaid commitment is a credit pool invoiced upfront. Orb's docs say commitments are "currently available to a limited set of customers."

FluxMeter does not keep that ledger. For prepaid drawdown and commitments, FluxMeter supplies per-customer usage and an optional budget signal; the drawdown ledger and true-up live in your billing system. In this pairing, the billing system is Orb.

FluxMeter's optional controls run before or during an LLM call:

FluxMeter's budget checks reduce overspend risk but do not guarantee zero overspend: cached fallbacks, streaming estimates, and concurrent requests can still exceed a limit. Budget checks create no hold, and operators own production hardening.

On the billing side, Orb documents threshold billing plus spend-management alerts: balance-depleted, cost-exceeded, and grouped cost alerts. Your application responds to these alerts by blocking product access or usage. Orb's guide notes a brief delay between depletion and the alert and describes ways to handle it. A gate that sits in the LLM request path and allows or denies each call is not verified in reviewed public docs. The two products act at different points and can be combined.

FluxMeter is Apache 2.0 and self-hosted. It documents one HTTP Custody path started with make demo. Demo authentication may be optional, so enable API keys before public exposure. FluxMeter is not offered here as a FluxMeter-operated SaaS.

Orb's materials describe a managed billing platform. A self-hosted Orb deployment is not verified in reviewed public docs.

Context: Orb states that its acquisition by Adyen closed on July 1, 2026, and that the product "continues to operate as a stand-alone platform" with customers able to keep choosing their payment processing partner.

FluxMeter ships a built-in Orb exporter, alongside its Stripe and Metronome exporters:

What does FluxMeter export to Orb? De-duplicated, per-customer token usage deltas per period (input and output tokens, or attributed usage cost). Orb applies metrics, prices, credit drawdown, commitments, and invoicing.

Field mapping is defined in the engine's integration docs (docs/integrations/orb.md). This is FluxMeter's own exporter. No partnership, certification, or official vendor integration is implied. Background: Metronome & Orb usage export with pre-request budgets.

Orb fits better when billing your AI product is the main problem:

FluxMeter fits better when token attribution and request-path control matter:

FluxMeter meters, attributes, and optionally gates. Its built-in exporter writes usage to Orb, and Orb handles metric pricing, credit drawdown, commitments, and invoicing.

Use FluxMeter to meter and optionally gate token usage (no zero-overspend guarantee); use Metronome/Orb to price, run credits/commitments, and invoice.