OpenClaw Bug：Gemini Token 统计全是 0（如何验证、影响点、临时绕过方案）

社区有反馈指出：OpenClaw 的 Google provider 适配层 可能没有把 Gemini 返回的 usageMetadata 映射到 OpenClaw 统一的 usage 字段里。

表现非常直观：

你明明发了 prompt、也拿到了回答
但 session .jsonl 里 usage.input = 0、usage.output = 0

这不是“显示层的小瑕疵”。很多人会把 token 统计接到 成本报表 / 预算阈值 / 告警，一旦记录为 0，等于把一条关键的安全护栏拔掉。

上游来源： openclaw/openclaw#51743

TL;DR

如果你在 OpenClaw 里使用 google/gemini-2.5-flash 或 google/gemini-2.5-pro，并且看到 token 统计恒为 0：

先在 session .jsonl 里确认这不是 UI 问题。
确认 Gemini 原始响应里确实存在 usageMetadata。
在官方修复前，把与“成本/预算/告警”相关的判断当作 不可信。
采用绕过方案：要么临时切换到能记录 usage 的 provider/model，要么在源码环境里做一个小补丁。

典型症状长什么样

反馈中，assistant 消息被记录为：

{
  "type": "message",
  "message": {
    "role": "assistant",
    "provider": "google",
    "model": "gemini-2.5-flash",
    "usage": {
      "input": 0,
      "output": 0,
      "cacheRead": 0,
      "cacheWrite": 0,
      "totalTokens": 0,
      "cost": { "input": 0, "output": 0, "total": 0 }
    }
  }
}

与此同时，OpenAI / Anthropic / 等其他 provider 的 usage 是正常有数值的。

影响点（务实版）

即便 Gemini 侧的计费本身是对的，你在 OpenClaw 本地看到的“用量/成本”会变成 假数据。

常见会被误导的地方包括：

成本看板、按 token 的成本归因
预算阈值（比如“超过 X 就停”）
告警（异常飙升/异常下降）
跨模型对比（Gemini 会看起来像“几乎不要钱”）

如果你把 OpenClaw 放在团队/生产环境里跑，这类用量缺失建议优先处理。

快速验证（按这个顺序）

1) 先确认 JSONL 里确实是 0

问题反馈提到的路径类似：

~/.openclaw/agents/<agent>/sessions/*.jsonl

找到对应的 assistant message，确认：

provider: "google"
model: "gemini-2.5-*"
usage.input == 0 && usage.output == 0

如果 JSONL 本身就是 0，那么这不是“前端展示”的锅，是归一化后的 usage 没被写进去。

2) Gemini 的原始响应通常会给 usageMetadata

Gemini 的 generateContent 响应一般包含：

usageMetadata.promptTokenCount
usageMetadata.candidatesTokenCount
usageMetadata.totalTokenCount

如果这些字段存在，那 OpenClaw 的适配层就应该把它们映射到：

usage.input
usage.output
（可选）usage.total

快速分流：这是 Gemini usage 映射缺失，还是别的计费/可观测性问题

很多团队第一次看到 token 全是 0 时，会把不同层级的问题混在一起。更实用的分流方式是：

只有 Google / Gemini 相关会话是 0，其他 provider usage 正常
- 这更像 provider adapter 的字段映射缺失，而不是全站统计系统都坏了。
session .jsonl 里已经是 0，但 UI 面板也是 0
- 这更像归一化写入阶段缺字段，不是前端展示层问题。
Gemini 原始响应里也根本没有 usageMetadata
- 这时要把排查重点转向上游 API 返回、模型配置或采集方式，而不是只盯 OpenClaw 的统一 usage 字段。
所有 provider 的 usage 都异常
- 那就不该再把问题范围锁死在 Google adapter，应该改查更上游的统计链路或日志落盘过程。

这一步很重要，因为它决定你下一步该去修 Google 适配层，还是去查更广泛的 observability / logging 问题。

值班时的快速决策树

如果你在值班时发现 Gemini token 统计全是 0，不要先把它当成“只是面板显示问题”。更稳的分流顺序是：

只有 Gemini 会话 usage 为 0，其他 provider 正常
- 优先怀疑 Google adapter 的 usage 字段映射缺失，而不是整站统计系统都坏了。
- 先确认 session .jsonl 和原始响应里到底有没有 usageMetadata。
session .jsonl 已经是 0，但 provider 账单或 quota 仍在增长
- 先把 OpenClaw 本地 usage 当成不可信信号，立即切换到外部账单或预算护栏。
所有 provider 的 usage 都异常
- 这时问题面更大，不该再只盯 Gemini adapter，应该改查更上游的统计或落盘链路。

宣布问题收口前，还要补验什么

即便你已经做了切流、补丁或外部护栏，也别只看一次测试就结束。至少还要补验这四件事：

新会话里的 usage.input、usage.output 已恢复为合理非 0，或外部护栏已稳定接管；
Gemini 原始响应与 OpenClaw 归一化字段之间已经能对上，避免再次“实际有消耗、平台记成 0”；
成本、预算或告警链路已经重新建立可信性，不会再被全 0 数据误导；
事故记录里已经保存受影响 session、原始响应样本、版本点和缓解方式。

如果你是从 troubleshooting 进来，先分清 Gemini 成功和 usage 计费失败

GA4 现在把这篇和 setup、provider 排障入口放在同一组里。读者可能已经成功调用 Gemini，但 billing、credits 或 dashboard 仍然看起来不对。

不要先换 API key 或 model name，先拆成三类检查：

Gemini 响应成功但 usage 为零：保留原始 usageMetadata、provider adapter 版本，以及上游是否改名 input/output token 字段。
请求在产生 usage 前就失败：按认证、quota 或 model routing 处理，不要误判成 usage mapping bug。
只有计费视图不对：对比日志、credit ledger 和 dashboard 聚合，让修复落在 mapping 或 reporting，而不是 provider 调用。

这样能避免高意图 provider 读者反复轮换 Gemini 凭证，而真正卡住的是 token usage normalization。

官方修复前的绕过方案

按风险从低到高列：

方案 A：对“必须记账”的工作流临时切 provider/model

如果你的工作流强依赖 token 统计（成本控制/预算/告警），最稳妥的方式是：

临时把这些会话路由到当前能正确记录 usage 的 provider/model

优点：不动网关代码，最不容易引入新故障。

方案 B：源码部署场景做一个最小补丁

该 issue 给出了一个直观的映射建议：

usageMetadata.promptTokenCount → usage.input
usageMetadata.candidatesTokenCount → usage.output
usageMetadata.totalTokenCount → usage.total（可选）

如果你是源码安装/可控升级的环境，可以在 provider adapter 层做一个非常小的提取函数，把字段接回去。

注意：尽量保持“最小、可回滚、与上游一致”，方便后续升级后直接删掉补丁。

方案 C：在 OpenClaw 之外加临时护栏

如果你既不能换模型，也不能打补丁，那建议至少在外部补一条护栏：

比如在 Google 侧的项目/账单里设置日预算或配额
或在你自己的 API 网关/账单面板上做监控

目的是在 OpenClaw 的 usage 不可信时，仍然能防止成本失控。

后续怎么确认“已修复”

关注上游 issue 的修复 PR/版本号：

openclaw/openclaw#51743

升级后用一个新会话复测，检查：

usage.input > 0
usage.output > 0
totalTokens（或等价字段）随调用合理增长

常见落地判断问题

什么时候该停止相信 OpenClaw 的成本看板，直接把它当成 provider adapter 可观测性缺陷

如果 session 里明明已经有 Gemini 请求和回复，但归一化后的 usage.input、usage.output 仍持续为 0，而其他 provider 的 usage 记录又正常，就不该再把它当成前端显示问题。更安全的判断是 Google adapter 在归一化过程中漏掉了 usageMetadata，这意味着所有依赖这些字段的预算、告警、会话成本统计都已经不可信。

哪些团队最应该在 usage 映射修好或本地补丁落地前暂停 Gemini 上线

如果团队依赖共享预算、内部成本分摊、超额告警或自动成本上限，这类场景最应该优先暂停或补丁修复。因为 token 记账一旦归零，受影响的不是展示层，而是治理和响应链路本身。个人试验阶段通常还能靠外部账单兜底，但团队或生产环境不该在成本遥测失真的前提下继续放量。

面向搜索入口的对比判断：Gemini usage 映射缺失，还是“模型本来就便宜/免费”的误读

这类故障很容易被值班同事误判成“Gemini 可能本来就便宜，所以 token 看板归零也没关系”，或者“只是 UI 少展示了几个数字”。这两种判断都会拖慢止损。

更有效的对比方式是：

请求和回复明明发生了，但 usage 仍持续为 0
- 这更像遥测映射失败，而不是“模型没有消耗 token”
OpenClaw 外部的 Google 账单或 quota 还在增长
- 这进一步说明丢失的是 OpenClaw 归一化层里的 usage 信号，不是实际调用没有发生
只有某个下游看板错了，但 provider 原始日志仍能看到计数
- 那就更该怀疑展示层或聚合层，而不是 adapter 本身
问题紧跟某次 OpenClaw 升级或 provider 变更后出现
- 这比“定价异常”更像 adapter 回归或响应字段处理变化

这也是搜索意图上的关键区别。搜 OpenClaw Gemini totalTokens 为 0 的人，通常不是在问 Gemini 是不是免费，而是在判断这套成本遥测还值不值得继续拿来放量。

缓解之后，交接里至少要写什么

如果你已经做了临时缓解，建议给下一位值班同事留一条简短交接，至少包含这四项：

这次是改成切流、打本地补丁，还是补了外部账单护栏
哪个受影响模型或路由曾经出现 usage.input = 0
故障期间 provider 侧账单或 usage 计数是否仍在增长
下一位同事应该继续盯哪个上游 issue 或版本点，再决定何时撤掉临时方案

这类交接的价值在于，它能让下一位同事直接判断“成本信号什么时候重新可信”，而不是从头再做一轮账单可信度排查。

常见判断问题 FAQ

如果 OpenClaw 里 token 全是 0，但 Google 账单还在涨，应该先信谁？

先信 provider 侧账单 / quota / 原始响应，不要继续把 OpenClaw 本地 usage 当真。

因为这类故障的关键就在于：

调用真实发生了
成本真实发生了
但 OpenClaw 统一 usage 字段没有把它写出来

这时候继续拿本地 usage 做预算、阈值和告警，只会放大误判。

什么时候更该把它当成 adapter 映射缺失，而不是 UI 看板显示问题？

如果 session .jsonl 里记录的 usage.input、usage.output 已经是 0，那就应该优先怀疑 adapter 归一化阶段，而不是前端看板。

因为 UI 再怎么错，也不会反过来把已经落盘的 JSONL 改成 0。

搜 `Gemini totalTokens 0` 的人，页面最该先帮他排哪三个点？

最该先排这三个：

session .jsonl 里 usage 是不是已经为 0
Gemini 原始响应里有没有 usageMetadata
其他 provider 的 usage 是否仍然正常

这三步能最快把问题分流到“Google adapter 映射缺失”还是“更广泛的统计链路故障”。

如果财务或运维已经依赖 token 告警，最稳妥的快速止损动作是什么？

最稳妥的快速动作，通常不是继续争论这些 0 到底是不是展示层小问题，而是先把成本敏感流量临时切离 Gemini，或者立刻补一条 provider 侧的外部预算护栏。

先保住运营边界，再给团队时间判断后续该走 adapter 补丁、本地回滚，还是 provider 切换。

团队准备给 Google adapter 打本地补丁前，最该先保留哪些证据？

在本地补丁落地前，至少留一组小型前后对照证据：

一份 usage 仍为 0 的受影响 session .jsonl
一份仍带有 usageMetadata 的 Gemini 原始响应
当时测试所用的 OpenClaw 版本或 commit
一份补丁后 usage 恢复非 0 的新会话样本

这组证据会直接影响你后面做回滚、升级清理和对比上游修复时的效率。

重新放量 Gemini 前，先做这 4 个恢复检查

当上游修复或本地补丁已经让 usage 恢复非 0，不要马上把所有成本敏感流量切回 Gemini。先做一轮小流量恢复检查：

新会话复测：用一个全新 session 触发 Gemini 请求，确认 usage.input、usage.output 和总 token 都随真实调用增长。
账单对齐：把 OpenClaw 侧 usage 与 Google 侧 quota / billing 变化做一次小样本对照，确认不是只恢复了本地展示。
告警重启：重新打开预算、阈值、内部分摊或自动停机策略，避免恢复放量后继续裸跑。
撤销临时绕过：记录什么时候撤掉 provider 切流、本地补丁或外部账单兜底，避免长期保留已经过期的应急配置。

这一步服务的是高意图运维读者：他们不是只想知道 bug 是否存在，而是想知道什么时候可以安全恢复 Gemini 流量。

Sources

问题描述与字段映射建议： openclaw/openclaw#51743

OpenClaw Bug：Gemini Token 统计全是 0（如何验证、影响点、临时绕过方案）

TL;DR

典型症状长什么样

影响点（务实版）

快速验证（按这个顺序）

1) 先确认 JSONL 里确实是 0

2) Gemini 的原始响应通常会给 usageMetadata

快速分流：这是 Gemini usage 映射缺失，还是别的计费/可观测性问题

值班时的快速决策树

宣布问题收口前，还要补验什么

如果你是从 troubleshooting 进来，先分清 Gemini 成功和 usage 计费失败

相关阅读

官方修复前的绕过方案

方案 A：对“必须记账”的工作流临时切 provider/model

方案 B：源码部署场景做一个最小补丁

方案 C：在 OpenClaw 之外加临时护栏

后续怎么确认“已修复”

常见落地判断问题

什么时候该停止相信 OpenClaw 的成本看板，直接把它当成 provider adapter 可观测性缺陷

哪些团队最应该在 usage 映射修好或本地补丁落地前暂停 Gemini 上线

面向搜索入口的对比判断：Gemini usage 映射缺失，还是“模型本来就便宜/免费”的误读

缓解之后，交接里至少要写什么

相关阅读

常见判断问题 FAQ

如果 OpenClaw 里 token 全是 0，但 Google 账单还在涨，应该先信谁？

什么时候更该把它当成 adapter 映射缺失，而不是 UI 看板显示问题？

搜 `Gemini totalTokens 0` 的人，页面最该先帮他排哪三个点？

如果财务或运维已经依赖 token 告警，最稳妥的快速止损动作是什么？

团队准备给 Google adapter 打本地补丁前，最该先保留哪些证据？

重新放量 Gemini 前，先做这 4 个恢复检查

Sources

TL;DR

典型症状长什么样

影响点（务实版）

快速验证（按这个顺序）

1) 先确认 JSONL 里确实是 0

2) Gemini 的原始响应通常会给 usageMetadata

快速分流：这是 Gemini usage 映射缺失，还是别的计费/可观测性问题

值班时的快速决策树

宣布问题收口前，还要补验什么

如果你是从 troubleshooting 进来，先分清 Gemini 成功和 usage 计费失败

相关阅读

官方修复前的绕过方案

方案 A：对“必须记账”的工作流临时切 provider/model

方案 B：源码部署场景做一个最小补丁

方案 C：在 OpenClaw 之外加临时护栏

后续怎么确认“已修复”

常见落地判断问题

什么时候该停止相信 OpenClaw 的成本看板，直接把它当成 provider adapter 可观测性缺陷

哪些团队最应该在 usage 映射修好或本地补丁落地前暂停 Gemini 上线

面向搜索入口的对比判断：Gemini usage 映射缺失，还是“模型本来就便宜/免费”的误读

缓解之后，交接里至少要写什么

相关阅读

常见判断问题 FAQ

如果 OpenClaw 里 token 全是 0，但 Google 账单还在涨，应该先信谁？

什么时候更该把它当成 adapter 映射缺失，而不是 UI 看板显示问题？

搜 Gemini totalTokens 0 的人，页面最该先帮他排哪三个点？

如果财务或运维已经依赖 token 告警，最稳妥的快速止损动作是什么？

团队准备给 Google adapter 打本地补丁前，最该先保留哪些证据？

重新放量 Gemini 前，先做这 4 个恢复检查

Sources

搜 `Gemini totalTokens 0` 的人，页面最该先帮他排哪三个点？