Use cases

Usage infrastructure patterns for AI products.

Where FluxMeter fits in the stack: attribute usage at the customer boundary on the single HTTP Custody path.

Dominant scenario

AI gateways

Upstream problem

One upstream provider account serves many downstream callers. Provider invoices show a single pool — not who consumed which tokens.

Event boundary

Meter at the gateway edge after the model response (or via the FluxMeter gateway proxy hooks), with a stable eventId for dedup.

Customer attribution

customerId maps to the downstream tenant or API key owner; modelId and token fields come from the provider response.

Budget / control

Optional pre-request GET /budget/{id}/check (and reserve/reconcile for streams) before forwarding upstream.

Resulting usage record usage line

Query customer usage via GET /usage/customer/{customer_id}/period/{period}, GET /usage/customer/{customer_id}/day/{date}, and GET /usage/customer/{customer_id}/model/{model_id} for dashboard or export lines.

Starting mode

Base stack

Evaluation and supported deploy use the same HTTP → Kafka → Flink path via make demo.

Supporting patterns

Token resellers

Upstream problem

Prepaid packages and RPM limits must be enforced before burn, not only when the month-end provider bill arrives.

Event boundary

Sync check on the hot path; async POST /ingest after the upstream call with eventId = upstream request id.

Customer attribution

customerId = downstream developer; optional per-key budgets via admin API when keys are issued per client.

Budget / control

Packages, soft webhooks, and optional hard caps — all optional layers on top of metering.

Resulting usage record

Period and model rollups expose what each developer consumed without standing up a warehouse first.

Starting mode

Base stack

Evaluation and supported deploy use the same HTTP → Kafka → Flink path via make demo.

Multi-tenant AI products

Upstream problem

Product tenants share model spend. Finance needs attributable lines; engineering needs a clear ingest contract.

Event boundary

Ingest from the application or worker after each model call; attach customerId (and optional span/session ids).

Customer attribution

Roll up by tenant and period; span ids attribute multi-step jobs without inventing a full job platform.

Budget / control

Optional wallet checks and span caps when prepaid or per-job ceilings matter.

Resulting usage record

Customer period lines become the shared input to billing export or internal cost views.

Starting mode

Base stack

Evaluation and supported deploy use the same HTTP → Kafka → Flink path via make demo.

Patterns describe verified API shapes and the base stack — not production deployments of named companies.