Glossary of LLM token metering & AI monetization terms

LLM token metering is recording how many input and output tokens each request consumes, attributing them and their cost to the right customer or tenant, and making that usage queryable and exportable. It is the data layer underneath usage-based pricing for AI products. Metering measures what was used by whom; it does not set prices, draw down credits, or issue invoices.

In FluxMeter: FluxMeter is an open-source LLM token metering layer. It attributes tokens and cost per customer and exports usage—it is not a billing platform.

Related: Architecture · Docs · FAQ · llms-full.txt

Usage rating turns metered usage into billable amounts under a customer's price plan, commitments, discounts, and credits. Metering measures and attributes usage; rating prices that usage. FluxMeter meters and attributes usage cost using a pricing catalog for cost visibility; rating engines and invoices belong to billing systems such as Stripe, Lago, Orb, or Metronome. FluxMeter is not a rating engine.

In FluxMeter: Complementary—FluxMeter meters; billing systems rate and invoice.

Related: FAQ · Compare: Lago · Compare: OpenMeter

Prepaid drawdown (or prepaid credits) means a customer buys a balance of usage up front, and each billable unit reduces that balance until true-up or renewal. For prepaid drawdown, FluxMeter supplies per-customer usage and an optional budget signal; the drawdown ledger and true-up live in your billing system. FluxMeter can optionally refuse a request before it runs when the customer is out of budget. Budget checks do not guarantee zero overspend.

In FluxMeter: Supplies usage plus an optional budget signal; the ledger stays in billing (Stripe, Lago, Orb, Metronome, and similar).

Related: Gateway docs · FAQ: prepaid drawdown · Compare: Lago · Compare: Metronome · Compare: Orb

In usage-based billing, a commitment is a contractual promise to consume a minimum amount of usage or spend over a period, often with overage rates and true-ups. FluxMeter does not store or enforce the commitment ledger. It exports clean per-customer usage so billing platforms such as Metronome or Orb can apply commitments, discounts, and true-ups.

In FluxMeter: Not a commitment ledger—exports usage for billing platforms to apply commitments. (Billing sense of “commitment,” not git.)

Related: FAQ · Compare: OpenMeter · Compare: Metronome · Compare: Orb · llms-full.txt

A hard gate is a pre-request budget or prepaid admission check that decides whether a model call may run under the current customer budget. FluxMeter exposes an optional check on the Gateway path (estimate → gate → reserve → upstream). Budget checks create no hold and do not guarantee zero overspend: cached fallbacks, streaming estimates, and concurrency can still exceed a limit.

In FluxMeter: Optional pre-request admission on the Gateway; it reduces overspend risk and does not promise zero overspend.

Related: Gateway docs · Architecture · FAQ: runaway agent costs · Stop runaway agent costs

Customer attribution in LLM metering means attaching every token event and its attributed usage cost to the correct customer or tenant, usually via auth-derived tenant context and tenant-aware keys. Without it, provider invoices stay account-level and cannot support per-customer pricing or budgets. FluxMeter attributes tokens and cost per customer on a stable event identity so Usage API queries and billing exports stay auditable.

In FluxMeter: Core job—per-customer token and cost attribution with a stable event identity.

Related: Architecture · Usage API · FAQ: customer attribution · Upstream invoice vs customer usage

Usage aggregation combines many raw token events into per-customer, per-dimension totals that the Usage API can query and that billing systems can ingest. In FluxMeter, Flink is the usage aggregation engine: it aggregates metered token events per customer and attributes usage cost using the pricing catalog; Redis holds query state. Aggregation is not invoicing; invoices come from your billing system.

In FluxMeter: Flink is the usage aggregation engine (never a “billing and aggregation engine”); it attributes usage cost using the pricing catalog.

Related: Architecture · Docs · llms-full.txt

AI monetization (or token monetization) is turning model usage into revenue through metering, pricing, and billing. A practical stack is: meter and attribute tokens per customer, optionally gate requests against budget, then rate and invoice in a billing system. FluxMeter covers metering, attribution, optional admission, and export; Stripe, Lago, Orb, Metronome, or Zuora cover pricing, rating, commitments, and payments.

In FluxMeter: Stack narrative meter → rate → bill. FluxMeter is the meter (plus optional gate and export), not the billing platform.

Related: Compare · Market map · FAQ: metering vs pricing vs billing · Use cases · AI monetization market map (blog)

Reserve and reconcile is the streaming pattern that estimates tokens before or during a stream, optionally holds budget capacity for the estimate, then adjusts to actual usage when the stream ends. FluxMeter Gateway supports reserve and reconcile on the same Custody path as metering. Reserves reduce overspend risk on long streams; they still do not guarantee zero overspend under concurrency or estimate error.

In FluxMeter: Gateway streaming control on the Custody path; still no zero-overspend guarantee.

Related: Gateway docs · Architecture · FAQ

Upstream provider invoices from OpenAI, Anthropic, and similar vendors are aggregated at your account on the provider's pricing, timing, and rounding. Customer-facing usage depends on how you attribute each request. FluxMeter meters each request with a stable event identity and attributes tokens and cost per customer, giving an auditable record to reconcile against the provider invoice.

In FluxMeter: Per-customer metered record to reconcile against account-level provider invoices—see the deep dive linked below.

Related: Upstream invoice vs customer usage · Architecture · FAQ