Overnight, one tenant’s agent enters a tool loop: retrieve, call, write back—again and again. Upstream provider traffic climbs on schedule. The dashboard curve looks impressive and alarming—and it is still a pool total. When you need to answer which customer is burning tokens, and at what scale, that same upstream board barely helps. By the time the month-end invoice lands, the damage and the dispute are often already set.
The gap is usually not “we need a bigger invoice PDF.” It is customer-level visibility before month-end. Agent runaway magnifies the failure: usage spikes in a short window, stacks across sessions and tools, and if you only watch the upstream pool, you learn who ran away far too late.
What the upstream dashboard shows vs what the customer side needs
The contrast is about grain, not about which view is “more complete.”
Upstream provider dashboards. They aggregate model, tokens, and spend by account, project, or key. Useful for procurement and for spotting pool-wide anomalies. When multi-tenant traffic folds into a few upstream keys, which customer or tenant drove the loop is not that dimension’s job.
Attributed customer usage lines. Your commercial unit is customer, tenant, or workspace. You need “how many tokens this customer’s agent session burned tonight, and what that costs under your rules”—queryable, aggregable, exportable fact lines, not a screenshot of the pool curve.
Cross-check them if you want (model totals should roughly rhyme). Do not conflate them. One is procurement-pool health; the other is attributed fact. A clean upstream total does not mean the customer side can speak clearly—the same split as upstream invoice ≠ customer-level usage: the summary layer cannot answer the customer-layer question.
One adjacent issue gets only a pointer: when the gateway times out or a usage receipt never arrives, you may not know whether an event happened. That receipt problem lives in the Architecture post on gateway timeouts. This piece covers the quieter failure: even when events arrive, without a customer dimension you still cannot see who ran away.
The missing layer: usage event → attributed / priced customer usage line
Seeing customer-level cost before the invoice needs an explicit metering fact layer—not another refresh of the upstream board:
usage event → attributed / priced customer usage lineEvent: an observable usage occurrence (tokens, model, timestamp, plus customer/tenant—and session or agent dimensions when you care).
Attribute: attach it to the right customer (and product or env as needed).
Price (your rules): apply your rate card or cost map; do not paste provider dashboard rows as customer truth.
Line: a queryable, aggregable, exportable customer usage line—the input to visibility, allocation statements, or a billing system, not the invoice itself.
With that layer, runaway is no longer only “the pool curve went steep.” You can slice by customer and see who burned, when, and at what scale. The upstream dashboard keeps serving procurement and pool alerts. The customer side speaks from your usage lines.
Visibility first; budget controls are follow-ons, not a zero-overspend promise
On the budgets topic, lock the order: customer-level visibility first, then control primitives.
Capabilities such as check / reserve can sit on top of attributed usage as admission and reservation controls—they improve what you can do after you can see. They reduce overspend risk; they do not guarantee zero overspend (concurrency, estimate error, cached fallbacks, and similar paths can still exceed a limit). The same bound applies if you mention a hard gate or block: this post is not a full budget product manual—that belongs in a later piece. Here the nail is simple: visibility is the prerequisite; control is optional; neither is “flip a gate and never overspend.”
What this layer solves—and what it does not
It fixes customer-level seeing and attribution grain. It does not issue invoices, and it does not promise stop-loss at zero.
| It helps you | It does not replace |
|---|---|
| See tokens and cost per customer before month-end | Full subscriptions, invoicing, collections, tax |
| Turn agent / gateway / multi-tenant traffic into attributed usage lines | Stripe, Lago, Orb, Metronome, OpenMeter, or any billing suite |
| Feed runaway reviews, usage statements, and export | A promise of zero overspend or “one gate forever” |
| Keep upstream pool curves and customer detail comparable but separate | Treating HTTP 202 / custody as settlement; ClickHouse as billing truth; Flink as a billing engine |
In one sentence: metering stops at the attributed usage line (optionally exported). Invoicing and payment stay in your billing stack. If you read Compare, align the question first—metering visibility or billing suite? They can connect via export. They are not the same product story; this post does not rank them or promise a migration.
Where FluxMeter fits
FluxMeter’s positioning is deliberate: Open-source usage metering for AI gateways and multi-tenant products — customer-level tokens and cost, without a full billing suite.
From flux to ledger: ingest usage from a gateway or SDK, move it through custody and stream processing into a queryable ledger, and read attributed, optionally priced customer usage lines from the Usage API. Against agent runaway, the first value is customer-level visibility you can query outside the billing suite. Export is optional—into your own billing logic or Stripe, Lago, Orb, Metronome, and similar systems. FluxMeter does not claim to replace them, and it is not a complete billing or invoicing platform.
On the wire: a 202 on ingest means custody (usage was durably accepted), not settlement. ClickHouse is an audit cold store, not billing truth; Flink aggregates usage, it is not a billing engine. Meter every token. Attribute every cost. Stop at the usage line. If budget controls are enabled later, read them with the same bound: no zero-overspend guarantee.
Next steps
If “the agent ran away, the upstream curve is red, and we still cannot name the customer” is the stuck point, check for customer-dimension usage lines before asking for a bigger pooled dashboard.
Boundaries and public comparisons: Compare
Touch the stack locally: make demo (see Docs)
Product and path facts: Architecture
Series companion: Upstream invoice ≠ customer-level usage
Later control (this post is visibility only): pre-request budgets / prepaid drawdown