余额少了，只能证明钱被扣了。
它没有告诉你，是哪个项目、哪个 Key、哪个模型，也没有告诉你这次任务为什么比昨天贵。
使用 AI Code With 这类第三方 API 路径运行 Codex 时，真正有用的不是反复刷新余额，而是把一次调用拆开看。平台当前 Usage Records 已确认显示时间、服务、模型、折扣、渠道、输入输出 Token、TTFB、总时长、Key、缓存与费用。
这已经足够把很多模糊问题缩小到一个可检查范围。
第一步只看时间
先复现一个很小的 Codex 请求，记下开始与结束时间。回到 Usage Records，只筛这几分钟。
如果没有任何记录，优先检查 Provider、Endpoint、网络与 Key 是否真的被当前 Codex 进程读取。没有到达平台的请求，换渠道和看模型价格都没有意义。
第二步看 Key 和模型
不同项目最好使用可识别的 Key。筛到 Key 后，再看模型是否符合配置。
模型不对，可能是默认 Provider 覆盖、Model ID 填错，或者 Codex 仍在读取旧配置。这里别用模型自报身份当唯一证据，后台调用记录更直接。
[真实截图待补：Usage Records 筛选器、字段明细与一条脱敏 Codex 请求]
第三步拆 Token、缓存和时长
输入 Token 很高，常见原因是上下文过大、重复附带文件或长会话不断累积。输出 Token 高，则要看任务是否要求了过多解释或生成了大段内容。
缓存字段能帮助判断重复上下文有没有被复用。TTFB 与总时长可以辅助区分等待首字节和整体生成时间，但这些数据不是根因诊断器。
第四步再看渠道和费用
同一模型可能存在不同渠道和折扣。AI Code With 后台能显示渠道与费用，但折扣会变化，不能把一次记录写成全站长期固定价格。
如果成本突然变化，先确认模型、渠道、Token 和缓存是否同时变化，再回到任务本身检查。不要看到一笔高费用，就直接得出平台涨价或模型变慢的结论。
记录能缩短人工排查路径，不会自动解决 401、404、429 或 502，也不会保证找到代码里的循环调用。
如果你使用的是官方 Codex 订阅，调用没有经过 AI Code With，就应该查看对应官方用量页面，不需要拿第三方后台替代。
看余额，是看结果。
看记录，才是在找原因。