夜里某个租户的 Agent 进了工具循环：反复检索、反复调用、反复写回。上游 Provider 侧流量照常上涨，仪表盘曲线好看也吓人——但那是整池合计。到你要回答「是哪个客户在烧」「烧到什么量级」时，同一块上游看板几乎帮不上忙；等到月末发票落地，损失与争议往往已经定型。
问题通常不是「再要一张更大的发票 PDF」，而是在月结之前，有没有客户级可见性。Agent runaway（agent 用量失控）把这件事放大了：用量短时冲高、跨会话/跨工具堆叠，若只盯上游池，你会很晚才知道是谁在跑飞。
上游仪表盘看见的，和客户侧需要看见的
对照很清楚，关键是粒度不同，不是「谁更全」。
上游 Provider 仪表盘。 按账号、项目或 key 汇总模型、token 与花费。对采购对账、发现整池异常很有用。多租户流量汇进少数上游 key 时，池内是哪一个 customer / tenant 触发的循环，默认不在这个维度里。
客户归因后的用量行。 商业单位是 customer、tenant、workspace。你要的是「这个客户今晚的 Agent 会话烧了多少 token、按你的规则对应多少成本」——可查询、可汇总、可导出的事实行，而不是上游合计曲线的截图。
二者可以对照（例如按模型汇总是否大致吻合），职责却分开：一边是采购池的健康度，一边是归因事实。上游合计对得上，并不等于客户侧已经说得清——这一点与 上游账单 ≠ 客户级用量 同源：汇总层回答不了客户层问题。
另有一层只点到为止：若网关超时或收据缺失，连「事件是否发生」都会变模糊——那是 Architecture 文 的收据问题。本稿聚焦另一点：即便事件到了，没有 customer 维度，你仍然看不见谁在跑飞。
缺的一层：usage event → 可归因的客户用量行
要在发票到来之前先看见客户级成本，中间需要明确的计量事实，而不是再刷新一次上游看板：
usage event → attributed / priced customer usage lineEvent： 可观测的一次用量（token、模型、时间戳，以及 customer / tenant，最好还有 session / agent 等你关心的维度）。
Attribute： 归到正确的客户（及产品、环境等）。
Price（按你的规则）： 用你的价目或成本映射标价，而不是把上游仪表盘行直接当成客户真相。
Line： 可查询、可汇总、可导出的客户级用量行——是可见性、分账说明与对接账单系统的输入，不是发票本身。
有了这一层，runaway 不再只是「整池曲线陡了」：你可以按客户切开，看到是谁、在哪段时间、以什么量级在烧。上游仪表盘继续服务采购与整池告警；客户侧则基于自己的用量行说话。
可见性优先；预算控制是后续，不是零超支保证
在 budgets 话题里，顺序值得写死：先有客户级可见性，再谈控制原语。
check / reserve 一类能力可以建立在归因用量之上，作为准入与预留的控制手段，改善「看见之后能否拦一把」的体验；它们降低超支风险，但不保证零超支（并发、估算偏差、缓存回退等仍可能越过限额）。硬闸 / 拦截若被提及，同样适用这条边界——本稿不展开成完整预算产品说明书，那是后续专题；这里只钉住：可见性是前提，控制是可选项，不是「上了闸就永不超支」。
这层解决什么，不解决什么
解决的是客户级看见与归因粒度，不是出账，也不承诺止损为零。
| 它帮你做的 | 它不替你做的 |
|---|---|
| 在月结前按 customer 看见 tokens 与成本 | 完整订阅、出票、催收、税务 |
| 把 Agent / 网关 / 多租户流量写成可归因用量行 | 替代 Stripe / Lago / Orb / Metronome / OpenMeter 等账单套件 |
| 为 runaway 复盘、用量说明、导出提供事实底稿 | 承诺「零超支」或「一闸永逸」 |
| 让上游整池曲线与客户明细可对照、不混为一谈 | 把 HTTP 202 / custody 当成已结算；把 ClickHouse 当账单真相；把 Flink 当计费引擎 |
一句话：计量层停在归因后的 usage line（可再导出）；出票与支付仍属于你的账单栈。若在看 Compare，先对齐问题——要的是计量可见性，还是账单套件。二者可以衔接（导出），不是同一叙事下的简单替代。
和 FluxMeter 的关系
FluxMeter 定位：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：接入网关或 SDK 的用量流，经 custody 与流处理进入可查询账本，再通过 Usage API 读出已归因、可按你的规则标价的客户用量行。面对 Agent runaway，价值首先是客户级可见性落在账单套件之外也能查到；导出可选——可送进自有账单逻辑，或 Stripe / Lago / Orb / Metronome。FluxMeter 不宣称取代它们，也不是完整计费 / 出票平台。
工程语义需克制：ingest 返回 202 表示 custody（用量已被可靠接收），不是 settlement。ClickHouse 是 audit cold store，不是 billing truth；Flink 做 usage aggregation，不是 billing engine。Meter every token. Attribute every cost. 停在用量行；预算控制若启用，也须带着「不保证零超支」阅读。
接下来
若正被「Agent 跑飞了、上游曲线红了、却说不清是哪个客户」卡住，先确认是否已有 customer 维度的 usage line，而不是先换一张更大的上游报表。
边界与对照：Compare
本地摸栈：make demo（见 Docs）
产品与路径：Architecture
系列对照：上游发票 ≠ 客户级用量
后续控制（本稿只谈可见性）：请求前预算 / 预付扣减