一句话看懂：有开发者用同一个 Codex 客户端、同一套输入、同样的模型和思考等级做对照测试，发现通过 API Key 访问时 OpenAI 返回的“推理 token”数量，比通过 ChatGPT Pro 订阅登录时高出最多约 32 倍。同一模型却给出两套用量数字，这件事比单纯的计费争议更值得关注。
事件核心：发生了什么
这项实验（托管在 GitHub 的 codex-reasoning-token-experiment 仓库）收集了 960 条完整回答，覆盖两个任务：预算内选项目、诊断书店重复邮件。测试对象是 Luna 6 与 Sol 6.1，思考等级分 Low、Medium、High，每个“任务 × 模型 × 等级 × 登录方式”组合取 40 条回答。
差异最明显的是书店任务：Luna 6 在 Medium 等级下，API Key 登录平均每次回答报告 96.30 个推理 token，ChatGPT Pro 登录仅 3.025 个，相差约 32 倍；High 等级为 148.525 对 85.2；Sol 6.1 High 为 216.675 对 138.7。Luna 6 Low 在订阅侧甚至报告为 0。所有书店决策答案全部正确，token 多并不等于答案更好。
实验用本地代理保证每一对请求的模型输入字节级一致，且只使用同一个 Codex 客户端，唯一变量是认证方式与服务端点。作者强调，这些数字是服务端“报告的用量”，并不等于模型内部的真实推理预算，目前公开信息显示，分歧原因仍未被确认。
为什么重要
推理 token 现在是大模型计费与成本核算的核心单位。同一模型、同一输入在不同访问路径上给出不同的用量记录，直接动摇开发者对账单和配额的可预测性。对于按 token 付费的 API 用户，这可能是真金白银的差异；对于订阅制用户，则意味着“包月”与“按量”两种商业形态背后可能连统计口径都不一致。
这也是闭源模型透明度问题的又一个缩影。开发者无法看到推理预算如何被分配，只能依赖服务端返回的数字，一旦这些数字在不同入口间不一致，所谓“同款模型”的说法就需要更谨慎地对待。
对用户/开发者/创作者的影响
对开发者而言，如果推理 token 直接计入费用，那么 API 与订阅之间的成本对比可能被系统性扭曲，做成本估算时不能默认两边口径相同。建议在账单侧分别记录 API 与订阅的实际用量，有条件的话复现作者的对照实验。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对企业采购来说，这意味着需要追问供应商：同一模型在不同产品线、不同端点下的用量统计是否统一，这直接影响预算模型和合同条款。对内容创作者和普通订阅用户，短期内实际体验未必有变化，但“花同样的钱、拿到的算力是否一致”会成为一个更值得留意的议题。
值得关注的后续
一是 OpenAI 是否回应这一差异，说明是路由、缓存、系统提示或统计方式所致；二是是否有更多独立复现，尤其出现“没有差异”的结果同样有价值；三是推理 token 的计量口径是否会随 API 定价或订阅条款调整。
