OpenAI的用量接口新增了按API密钥分组的能力，这解决了一个很实际的报表缺口：我能看到哪把API密钥产生了补全令牌活动，哪把密钥累积了成本。麻烦的地方不在于发两次请求，而在于把两边的每日桶拼在一起时，不能丢掉那些没有归属或对不上的数据。

我要的是一份对账报告，把缺口暴露出来，而不是把它们抹平。一条缺失的成本行、一条只有成本的行、或者一个空的密钥ID，各自都可能是有用的证据。下面这套确定性.NET示例不需要任何凭证，也不用付费调用，就能把这些情况保留在视野里。

打开网易新闻 查看精彩图片

为什么需要全外连接

OpenAI在2026年8月4日的API更新日志里，给用量和成本接口都加上了按API密钥过滤和分组的能力。这让两个响应有了一个共同的操作维度，但不代表它们变成了完全相同的数据集。

补全用量端点报告的是输入令牌、输出令牌、模型请求数这些指标，它的api_key_id可以为空。成本端点返回的是金额和币种，同样带一个可空的API密钥维度。

内连接只会保留两个响应里都出现的行。做一张干净的图表时这很诱人，但对账时却不安全。它可能藏掉一把有令牌用量但没有对应成本行的密钥、一把有成本却没有补全行的密钥，或者一个没有归属的桶。

所以我改用按(start_time, end_time, api_key_id)做键的全外连接。空值或空白ID会变成一个显式的显示值，比如，它们不会消失。

两个接口都按天查询

成本接口支持每日桶，所以两个端点我都请求bucket_width=1d，并且按同一个维度分组：

  • GET /v1/organization/usage/completions?start_time=...&end_time=...&bucket_width=1d&group_by=api_key_id
  • GET /v1/organization/costs?start_time=...&end_time=...&bucket_width=1d&group_by=api_key_id

两个资源都用has_more和next_page做分页。我会一直请求下一页，直到has_more变成false。如果响应说还有更多数据但漏掉了游标，我就让报告失败，而不是接受一个不完整的周期。重复的游标我也会拒绝，防止分页循环卡死。

这种对齐很重要。把小时级用量和每日成本拼在一起，会人为制造出不匹配。只给用量分组加上model，会让它的行粒度跟成本侧对不上。对这份报告来说，两个来源都必须解析成每个UTC日、每个API密钥ID一行。

对账但不虚构价格

加载完所有页之后，实现会为用量和成本分别建索引，然后把两边的键合并，给每一行分配一个状态：

  • 两边都有，标记为Matched
  • 只有用量，标记为UsageOnly
  • 只有成本，标记为CostOnly

索引会拒绝重复的日期/密钥对。这样每一行都能被追踪到它的来源，而不是被静默合并或丢弃。

整个对账过程不引入任何价格推算。令牌数和成本金额各自来自原始响应，报告只负责把它们并排呈现，让缺口自己说话。