多模型能回复，为什么日志里的 Token 总是空

同一应用先接 Responses，再加 Chat Completions、Anthropic Messages 或 Gemini，如果沿用一条 response.usage.total_tokens 读取规则，某些记录会出现空值。先检查响应所属协议和原始字段，再调查是否真的没有返回用量。

这篇面向维护应用日志的开发者：建立一张协议映射表，把能核实的用量放进自定义记录，同时保留缺失状态。它不计算价格，也不替代控制台账单；若目的是解释一项任务为何消耗较多，可先读本站任务用量核对指南。

第一步：用实际调用入口选择映射规则

AIGoCode 当前四份协议文档给出的用量位置如下。表中的“常见”意味着应以实际响应为准，不能要求每次响应必有全部字段。

不要只按模型品牌选择解析器。Responses 和 Chat Completions 即使调用同一个 OpenAI 协议模型，输入、输出字段的命名也不同。建议在发送请求时记录本次选用的接口类型，响应回来后直接使用对应规则，避免仅凭对象里恰好有没有某个字段猜协议。

第二步：给缺失值留一个明确位置

可以在自己的日志中设计 protocol、inputTokens、outputTokens、reportedTotalTokens、usagePresent 五项。这些是应用自定义字段，不是 AIGoCode 额外提供的 API。

读取时建议使用三种状态：

• 原响应中存在数值字段：记录该值，包括明确返回的零。
• 容器存在，但某个预期字段缺失或类型不符：记录为空并注明原因。
• 连用量容器都没有：记录“本次未取得用量”，保留响应类型供排查。

不要用默认值零覆盖后两种状态，否则后续统计无法分清“接口明确返回零”和“采集器根本没有读到”。合计字段也建议保留服务端实际返回值；缺失时，不要用应用自行相加的数字冒充接口报告的合计。若业务确实需要估算，应单列为本地计算值，并标明来源。

第三步：Anthropic 缓存信息先保留，别猜字段补齐

Anthropic 页面只说明 usage 包含输入、输出及可能返回的缓存读写信息，没有在本页逐项列出这些键名。此时应保留已脱敏的用量子对象，等核实实际字段或更详细的正式资料后，再扩展映射。

“其他协议有三个常见字段”不能作为给 Anthropic 补造同名字段的依据。也不要把缓存读写直接折算成普通输入用量，或仅凭出现缓存记录就宣称节省了多少费用。Gemini 文档同样说明控制台可查看输入输出、缓存记录与实际额度消耗，接口字段表只是用量采集的起点。

保留原始信息的范围也要收窄：可记录用量子对象与必要的协议标识，不为观察 Token 将认证头、API Key 或完整业务 Prompt 一并写入排错日志。

第四步：用本地样本检查映射，而不是重新发收费请求凑数据

先整理已经拥有、允许使用且经过脱敏的响应样本。为每种已接入的接口分别检查三个情形：正常数值、明确的零、字段缺失。确认缺失样本不会生成一条“消耗为零”的记录，再接入汇总统计。

例如，一份 Gemini 样本含 usageMetadata.totalTokenCount 时，应该进入 Gemini 的映射分支；如果误按 usage.total_tokens 读取，只能得到缺失状态，不能据此认定 Gemini 没有消耗。这是本地解析检查示例，不是本文实际调用所得的响应。

对于流式请求，应另行核对该流中实际取得的用量位置与时机；本文的表格基于各协议页面的一般响应说明，不保证每一段增量都附带完整用量。没有取得完整记录时，保留“不完整”状态，不从正文长度反推 Token。

最后分别保存用量和实际额度

Responses、Chat Completions 与 Anthropic 文档都将实际额度或消费明细指向控制台的“使用统计”。因此建议日志保留 Token 原单位，实际消耗保留控制台对应记录及单位；不要为统一图表，把 total_tokens 直接命名成“扣费金额”。

完成后，你应能回答三件事：这条记录来自哪个接口，数值是原响应提供还是本地计算，缺失信息是否被误记成零。字段采集稳定以后，再按模型、时间与控制台消费记录做核对，才有可复查的依据。