codex 的输入 token 消耗巨大，跟 claude 拉开了几条街，怪不得额度消耗这么快
- 内容介绍
- 文章标签
- 相关推荐
这是 claude 用 opus 4.7 xhigh：
image1888×770 100 KB
这是 codex 用 gpt 5.5 high：
image1888×768 97.2 KB
同一个代码库，正常的需求分析和实现。。。
网友解答：--【壹】--：
opus 创建了 1416.5k 的 缓存，但是只输入了 8k？
gpt 那边 没创建缓存，但是命中了15590k？
是数据统计的问题吧
--【贰】--：
统计口径都不一样。。。claude那边是输入跟缓存分开计算了，codex明显输入已经包含了缓存的数据
--【叁】--：
cc 自带的统计没这么详细，而且 ccs 可以对比看各家的消耗
--【肆】--：
确实，这个数据可能有问题，截图是取的 cc-switch 的数据，但是 codex 的额度消耗巨快体感上很明显，所以看到这个数据第一感觉就是 codex 有问题。
有关缓存命中的知识不甚了解，有没有可能这里计算的是非缓存命中的场景呢？
--【伍】--：
看明白了。
Opus的总输入是：8.6k（普通输入）+1416.5k（缓存创建输入）+28284.5k（缓存命中）
5.5有两种解释，要么总输入是 17161.6k（普通输入+缓存命中），要么是 17161k+15590k
无论哪一种都不至于差很多
--【陆】--：
opus这数据有问题吧
一般来说 Input >> Output 才是对的，打了200多k的输出怎么才 8k 输入？
PS：啊，可能算到缓存创建了
--【柒】--：
就正常使用，没有引入额外的 skill 或者工作流，而且使用的方式和 claude 是差不多的。只是代码仓本身比较大，所以我才怀疑是 codex 的 harness 工程实现拉垮
--【捌】--：
opencode+magic-context 真香定律
--【玖】--：
总的消耗应该确实是差不多的，这么看的话最大的可能性是 codex 缓存命中的问题，并非 harness 工程的问题。看到数据量级的差距下意识就觉得 codex 拉垮了。
--【拾】--：
楼上正解，你的claude统计是有问题的，input一定大于output，要么你2次的提示词不对，要么claude的统计规则跟codex不一样
--【拾壹】--：
一个 bug fix 下去，5h limit 干没了 35%，这是把我整个代码库都作为 input 了吧
--【拾贰】--：
一般这种情况优先排查上下文组装层是不是有问题吧。
harness 在构建任务 input 时，没有做相关文件筛选，直接把仓库结构/全部文件作为背景塞进去了？
或者说evaluator/validator 多跑了一轮？这种一般也会导致爆炸，毕竟每多一轮评估，就得带完整上下文重跑
--【拾叁】--：
image937×259 21.1 KB
image482×948 23.8 KB
codex请优先检查网关问题。缓存高的
image256×106 4.94 KB
--【拾肆】--：
为什么不查本地的cc数据去查这种中转统计
cx能比cc高消耗吗？我不太相信
这是 claude 用 opus 4.7 xhigh：
image1888×770 100 KB
这是 codex 用 gpt 5.5 high：
image1888×768 97.2 KB
同一个代码库，正常的需求分析和实现。。。
网友解答：--【壹】--：
opus 创建了 1416.5k 的 缓存，但是只输入了 8k？
gpt 那边 没创建缓存，但是命中了15590k？
是数据统计的问题吧
--【贰】--：
统计口径都不一样。。。claude那边是输入跟缓存分开计算了，codex明显输入已经包含了缓存的数据
--【叁】--：
cc 自带的统计没这么详细，而且 ccs 可以对比看各家的消耗
--【肆】--：
确实，这个数据可能有问题，截图是取的 cc-switch 的数据，但是 codex 的额度消耗巨快体感上很明显，所以看到这个数据第一感觉就是 codex 有问题。
有关缓存命中的知识不甚了解，有没有可能这里计算的是非缓存命中的场景呢？
--【伍】--：
看明白了。
Opus的总输入是：8.6k（普通输入）+1416.5k（缓存创建输入）+28284.5k（缓存命中）
5.5有两种解释，要么总输入是 17161.6k（普通输入+缓存命中），要么是 17161k+15590k
无论哪一种都不至于差很多
--【陆】--：
opus这数据有问题吧
一般来说 Input >> Output 才是对的，打了200多k的输出怎么才 8k 输入？
PS：啊，可能算到缓存创建了
--【柒】--：
就正常使用，没有引入额外的 skill 或者工作流，而且使用的方式和 claude 是差不多的。只是代码仓本身比较大，所以我才怀疑是 codex 的 harness 工程实现拉垮
--【捌】--：
opencode+magic-context 真香定律
--【玖】--：
总的消耗应该确实是差不多的，这么看的话最大的可能性是 codex 缓存命中的问题，并非 harness 工程的问题。看到数据量级的差距下意识就觉得 codex 拉垮了。
--【拾】--：
楼上正解，你的claude统计是有问题的，input一定大于output，要么你2次的提示词不对，要么claude的统计规则跟codex不一样
--【拾壹】--：
一个 bug fix 下去，5h limit 干没了 35%，这是把我整个代码库都作为 input 了吧
--【拾贰】--：
一般这种情况优先排查上下文组装层是不是有问题吧。
harness 在构建任务 input 时，没有做相关文件筛选，直接把仓库结构/全部文件作为背景塞进去了？
或者说evaluator/validator 多跑了一轮？这种一般也会导致爆炸，毕竟每多一轮评估，就得带完整上下文重跑
--【拾叁】--：
image937×259 21.1 KB
image482×948 23.8 KB
codex请优先检查网关问题。缓存高的
image256×106 4.94 KB
--【拾肆】--：
为什么不查本地的cc数据去查这种中转统计
cx能比cc高消耗吗？我不太相信