编程代理订阅额度：缓存上下文影响多大

同一块任务看板上跑 Claude Code 和 Codex，订阅额度能撑多久？作者根据两家的每周用量表估算：Claude Pro 约能跑 36 小时，ChatGPT Plus + Codex 约 3 到 3.5 小时，相差约 10 倍。

这个结果更有意思的地方，是它暴露了长任务的消耗结构：Agent 反复读取已有上下文，可能比生成代码更影响订阅额度。但这是一组生产使用记录，任务数量和测量精度都不对等，适合拿来调整选购思路，不能直接当成两款产品的通用排名。

为什么生成代码很少，额度却一直在掉

作者记录的 Claude 工作负载覆盖 17.6 小时、15 个任务，期间新输入只有 3,956 tokens。Codex 那个任务的构成也类似：98.2% 是缓存读取，输出只占 0.26%。

编码 Agent 每轮都需要读取任务说明、代码和历史操作。即使这些内容已经缓存，下一轮仍然要读取它们。任务持续时间越长，反复读取同一批上下文的消耗就越值得关注。

因此，作者把比较重点放在订阅允许消费多少重复上下文，而不是模型能输出多少内容。

对缓存读取占比很高的 Agent 工作流，输出额度未必是最先碰到的限制。

两家 API 的缓存读取定价都约为新输入的十分之一。作者据此指出，观察到的差距不能简单归因于 API 缓存价格，而在于订阅方案允许消耗多少缓存用量。原文没有给出两家订阅内部的完整计费规则，这仍然是根据用量表现作出的解释。

约 10 倍的差距，是怎样推出来的

Claude Pro 在 17.6 小时内消耗了每周额度的 49%。假设后续消耗速度不变，外推得到约 36 小时。

作者沿途记录了 44 次周用量表变化，并称这让消耗斜率的误差约为 ±1%，而只读两次用量表时约为 ±33%。这是作者对测量精度的描述，原文没有展开误差计算方法。

Codex 则在 18 分钟内消耗了 ChatGPT Plus 每周额度的 9%，按相同速度外推，得到约 3 到 3.5 小时。它的用量表只显示整数百分比，因此估算噪声更大。

作者选择比较小时数，是因为 OpenAI 的额度以 credits 和 requests 表示，没有一个可以直接外推的 token 总池。若换算成美元，又必须先决定缓存读取是否按 API 标价计入。「消耗一周额度的多少比例」避开了这些换算选择。

不过，这里的小时数是按当前负载外推的 Agent 运行时间，不能直接等同于开发者有效工作时间。

两组记录还有几个边界：

• Claude 覆盖 15 个任务，Codex 只有 1 个任务；作者说工作负载可比，但并不相同。
• Codex 测于 9 月 7 日，Claude 测于 9 月 15 日，原文没有注明年份。
• Claude 测量时，临时增加 50% 每周额度的活动已经结束，记录反映的是 9 月下调后的额度。

作者也提到，他们在 5dive model value board 跟踪实测与建模的方案价值，但原文没有提供更多对照数据。

我的判断

我认同它提出的比较维度：如果日常工作是让 Agent 持续读代码、改代码、验证结果，只看输出限制和 token 标价，很容易看偏。实际任务能跑多久、完成多少件事，更贴近订阅是否够用。

但「约 10 倍」只能限定在这组记录里。15 个任务对 1 个任务、不同测量日期、不同精度的用量表，都削弱了直接比较的力度。原文也没有报告具体模型、任务难度、完成质量和返工情况，无法判断谁以更少额度完成了同等质量的工作。

作者关于保持上下文稳定的建议也有价值：修改提示词靠前的内容，可能让下一轮整个上下文都需要重新写入缓存。Claude 记录中，缓存写入只占额度消耗的 1.8%，却占按 API 价格折算价值的 22.7%。

这两个比例的分母不同，不能据此推算「减少缓存写入就能省多少订阅额度」。它更能说明，API 等价金额和订阅用量并不是同一把尺子。至于稳定上下文到底能提高多少续航，作者没有提供对照实验。

能拿来做什么

• 选订阅前，用自己的真实编码任务记录运行时间、周额度变化和任务完成情况；前端页面修改与 Node 问题排查可以分别记录，避免用单个任务代表全部工作。
• 如果工具能显示用量构成，先确认缓存读取是否接近作者所说的 97% 到 98%。占比差异很大时，就不适合套用这组续航估算。
• 在可控的提示词里，让固定项目说明保持稳定，把本轮新增要求放在后面，减少前部内容变化；再观察缓存写入是否下降。
• 比较 Claude Code 和 Codex 时，同时记录验收结果与返工次数。额度消耗慢只是一个指标，完成可用修改才是订阅价值的落点。