Codex Direct 与缓存 Token

一句话教训

长线程不要无限 fork / resume 继续跑；监控也不能把 fork 复制的历史再算一遍。 Codex child rollout 可能把 parent 的全部或尾部 token history 写进自己的 JSONL。那是 provenance replay，不是新的 provider 使用量。

新版 collector 先用 direct parent 与 fork cutoff 做 exact suffix-prefix 匹配，再累计 child 真正新增的正向 delta。只有后续真实模型调用再次处理大上下文时产生的 cached input，才会继续计入 gross。

rollout 在这里是什么意思

这里的 rollout 不是业务发布，而是 Codex Desktop 本地的一次会话日志文件，例如：

~/.codex/sessions/YYYY/MM/DD/rollout-...uuid.jsonl

collector 只读其中的 token metadata：event_msg / token_count / total_token_usage。它不读取 prompt、response 或工具输出正文。

total_token_usage 是累计电表读数。统计单位是相邻可靠状态之间的增量，而不是把多个 rollout 的最终电表读数相加。

现在半小时图如何计数

1. Token monitor 每 :00 / :30 采样一次。
2. root rollout 从零累计；跨日 rollout 从当天零点 baseline 开始。
3. child rollout 若复制 parent history，exact replay 部分作为 inherited baseline 跳过。
4. parent fork 后继续产生的 delta、每个 child 分支自己的 delta，分别只计一次。

因此图上的新增量代表监控可证明的日内 token delta。实际调用若在半小时内集中产生大量 cached input，仍会形成真实台阶；JSONL hydration/replay 本身不会再制造假台阶。

缓存 token 的含义

cached_input_tokens 是 input_tokens 的子集：请求携带的输入上下文中，有多少 token 的前缀命中了 provider prompt cache。它不是本地新增缓存文件，也不是在 total 之外额外再加一遍。

一个大上下文如果被连续请求复用，每次都会贡献 cached input metadata。因此 cached input 可以在短时间内累计到几亿，但 non-cached / effective token 会小很多。

最新 Codex direct 归因

• Codex direct gross: 66,831,380 tokens (83.6% of latest gross total)
• Codex direct cached input: 63,424,768 tokens
• Codex direct non-cached/effective approx: 3,406,612 tokens

这里的 non-cached 是 max(total - cache_read, 0) 的本地近似，不是 ChatGPT Profile 公式或供应商账单折算。

操作建议

• 需要长时间推进时，保留长线程作为 provenance，但不要无限 fork 后继续让它成为主工作线程。
• 到关键节点时，开一个短上下文收口线程，只带目标、当前结论、必要文件和 next action。
• 看 dashboard 时同时看 gross total、cached input、non-cached/effective，不要只用一个数字解释成本或工作量。
• 当 gross 曲线出现几亿级台阶时，先查 by_root 中的 CodexCLI / codex-cli 和该时段新 rollout，再判断是否真实异常。