Grok 与 OpenAI 的思考 Token 口径差异

xAI Grok 的 Chat Completions 响应沿用了 OpenAI 风格的 usage 字段名，但相同字段名不代表相同的计算口径。最关键的差异是：xAI Grok 的 completion_tokens 只统计最终返回的答案文本；模型在得出答案过程中用于分析和规划的思考 Token 单独记录为 reasoning_tokens。OpenAI 的 completion_tokens 则已经包含思考 Token。¹²

本文说明厂商官方协议的原始口径。经过兼容网关或第三方聚合服务后，usage 可能被归一化；业务代码应同时检查模型、协议和实际返回数字，不能只根据字段名判断。

结论速查

这里的“包含”是集合关系，不是说模型的思考过程会直接返回给调用方。思考 Token 可以不可见，但仍会占用上下文并参与计费。

xAI Grok Chat Completions

xAI 对相关字段的定义是：

• completion_tokens：仅表示模型最终返回的文本；
• completion_tokens_details.reasoning_tokens：模型在得出答案过程中用于分析和规划的思考 Token，不包含最终返回的答案文本；
• prompt_tokens_details.cached_tokens：prompt_tokens 中命中缓存的子集，不应再次加到输入总量；
• total_tokens：在 Grok 官方示例中包含输入、最终文本和思考 Token。

xAI Chat Completions 官方示例返回：³

{
  "usage": {
    "prompt_tokens": 32,
    "completion_tokens": 9,
    "completion_tokens_details": {
      "reasoning_tokens": 94
    },
    "total_tokens": 135
  }
}

这组数字的关系是：

32 + 9 + 94 = 135

另一个 xAI Deferred Chat Completions 官方示例为：⁴

prompt_tokens = 26
completion_tokens = 168
reasoning_tokens = 304
total_tokens = 498

26 + 168 + 304 = 498

两个示例中的 reasoning_tokens 都大于 completion_tokens，因此 reasoning_tokens <= completion_tokens 也不能作为跨厂商不变量，更不能为了满足 OpenAI 的子集关系而截断 Grok 的原始数字。

因此，在保留 xAI 原始口径的响应中：

Grok 计费输出用量 = completion_tokens + reasoning_tokens
Grok 总用量       = prompt_tokens + completion_tokens + reasoning_tokens

xAI 将 Completion Tokens 和 Reasoning Tokens 都按完整的 completion/output Token 单价计费。total_tokens 只用于汇总和校验，不是第三个独立计费项。⁵

OpenAI Chat Completions

OpenAI 把 completion_tokens_details 定义为 completion_tokens 的明细。reasoning_tokens 虽然通常不可见，但已经计入 completion_tokens，因此：²

OpenAI 计费输出用量 = completion_tokens
OpenAI 总用量       = prompt_tokens + completion_tokens

OpenAI 的 Reasoning 指南还给出了 Responses API 示例：⁶

input_tokens = 75
output_tokens = 1,186
reasoning_tokens = 1,024
total_tokens = 1,261

正确关系是 75 + 1,186 = 1,261。其中 1,024 个思考 Token 已包含在 1,186 个 output_tokens 中，不能再计算成 75 + 1,186 + 1,024。Chat Completions 使用不同的字段名，但同样把 reasoning 作为 completion 的明细。

如何识别实际口径

对于普通纯文本响应，当 reasoning_tokens > 0 时，可以用顶层总量检查响应采用了哪种关系：

base = prompt_tokens + completion_tokens

total_tokens == base
  → reasoning 已包含在 completion 中，符合 OpenAI 聚合口径

total_tokens == base + reasoning_tokens
  → reasoning 独立于 completion，符合 xAI Grok 原始口径

其他结果
  → usage 不自洽，或经过了尚未识别的协议转换

如果 reasoning_tokens 为 0，两种等式会同时成立，无法只靠数字识别。此时需要结合模型 ID、上游厂商、接口协议和渠道是否做过 usage 归一化判断。

这个等式适合用于一致性诊断，不应替代厂商协议定义。音频、Prediction、工具调用或其他扩展 Token 类别可能引入额外关系，应按对应 endpoint 的官方字段说明处理。

输出上限也存在差异

字段名相似不只影响 usage：

因此，不能根据 Grok Chat Completions 的 max_completion_tokens 估算这次请求最多会产生多少思考 Token，也不能假设同名参数在两个厂商中具有完全相同的限制范围。³

xAI Responses API 的一致性提醒

截至 2026 年 8 月 16 日，xAI Responses API 的官方资料存在不一致：

• POST /v1/responses 示例中，input_tokens = 131、output_tokens = 624、reasoning_tokens = 246、total_tokens = 755，满足 131 + 624 = 755，表现为 reasoning 已包含在 output 中；³
• GET /v1/responses/{response_id} 示例仍使用 prompt_tokens、completion_tokens 字段，其中 prompt_tokens = 32、completion_tokens = 9、reasoning_tokens = 110、total_tokens = 151，满足 32 + 9 + 110 = 151，表现为 reasoning 独立计数；³
• Context Compaction 示例中，input_tokens = 12,000、output_tokens = 800、reasoning_tokens = 240、total_tokens = 12,800，满足 12,000 + 800 = 12,800，同样表现为 reasoning 已包含在 output 中；⁷
• usage.context_details.output_tokens 的字段说明也把 output 描述为 completion 与 reasoning 的合计。³

因此，当前资料不能支持“所有 xAI Responses endpoint 采用同一种 reasoning 包含关系”的结论。不应把 Chat Completions 的结论机械推广到 Responses，也不应因为接口兼容 OpenAI 就直接采用 OpenAI 的 usage 加法。接入 xAI Responses 时，应按 provider 与 endpoint 保存并解析原始响应，通过 total_tokens 验证关系，并以请求日志和账单明细确认最终计费口径。

对账检查清单

1. 确认请求实际使用的是 Chat Completions 还是 Responses。
2. 记录模型 ID、上游厂商和是否经过兼容协议转换。
3. 从 details 中读取 reasoning_tokens，不要把字段缺失直接解释为零。
4. 用 total_tokens 检查 reasoning 是独立计数还是输出子集。
5. 根据识别出的口径计算输出用量，避免漏计或重复计算。
6. 最后使用 Modelink 请求日志中的 bo_usage、bo_usage_cost 和请求发生时的模型价格复核金额。

参考资料