当额度变成产品功能：Codex 的 5 小时限制、Tibo 的重置按钮与 Claude 的回应

2026年8月11日 · 阅读需 6 分钟

这段时间，Codex 用户最熟悉的不是某个新模型，而是一个反复出现的动作：重置额度。

有时是因为事故，有时是因为缓存或计量异常，有时是产品发布或活跃用户里程碑。最近，5 小时额度又在部分用户界面里消失，只留下周额度；与此同时，OpenAI 方面多次把付费用户的周额度恢复到满额。另一边，Claude 也在 GPT-5.6 发布当天重置了全体用户的 5 小时和周额度。

随后，Codex 负责人 Tibo Sottiaux 对 Claude 的公告只回了一句：“I smell fear.”

这当然是一条适合截图传播的 X 回复。但如果把热闹往下挖一层，会发现这并不是单纯的“OpenAI 嘲笑 Anthropic”。它暴露的是一个更重要的变化：在 agent 时代，额度、重置和限流已经从后台基础设施变成了产品体验本身。

5 小时限制消失了，但这不等于限制消失了

7 月，OpenAI 支持人员曾在开发者社区回应：Codex 的 5 小时限制展示被临时移除，是事件响应的一部分；周额度信息会继续保留，待问题处理后 5 小时信息应当恢复。OpenAI Developer Community 的原始讨论

这句话非常关键。用户看到的“没有 5 小时限制”，不能直接被解读为 OpenAI 永久取消了滚动窗口。更准确的说法是：产品暂时把一个限制维度隐藏或暂停了，具体政策仍然由后台额度系统决定。

但从用户体验看，区别没有那么大。一个原本清晰的双层机制——5 小时窗口加周额度——突然变成只显示周额度，用户自然会问：我究竟还剩多少可用量？现在的恢复是滚动恢复，还是要等到固定周期？“100%”是一次补偿，还是新的长期上限？CLI、桌面端和 Web 页面，谁才是准的？

这些问题说明额度系统已经影响到了工作流的可预测性。

过去，限流通常是一个安静的后台机制：达到上限，等待窗口恢复，或者升级套餐。现在的 Codex 则出现了另一种节奏：遇到异常，重置；发布新模型，重置；活跃用户突破里程碑，重置；用户报告消耗异常，还是重置。

其中有些动作是合理的补偿。OpenAI 状态页曾说明，部分 Codex 用户的额度消耗过快与滥用和欺诈防护系统误判有关。OpenAI 状态页

问题在于，当同一个补偿动作被频繁使用，它就不再只是补偿，而会变成用户理解产品的一部分。社区甚至开始记录 Tibo 的每一次公开重置：从事故、缓存问题，到 GPT-5.6 Sol 发布、活跃用户增长和周末福利。公开记录

用户并不讨厌免费额度；用户讨厌的是不知道下一次额度什么时候会被重新定义。

7 月 9 日，ClaudeDevs 宣布重置所有用户的 5 小时与周速率限制，时间点恰好与 GPT-5.6 系列发布重合。Tibo 的 “I smell fear” 因此被理解为：Anthropic 看到竞争压力，所以给用户发了一次免费补给。ITmedia 对这次交锋的报道

当然，这条回复并不能证明 Anthropic 的动机。重置也可能是容量变化、服务策略、事故补偿，或者几个因素叠加。它有传播力，正是因为它把一个无法证实的因果关系，压缩成了三个很有戏剧性的单词。

这已经不是模型之间的静态对比，而是用户留存的动态竞赛：模型发布负责吸引用户，额度重置负责让用户留下来继续跑任务。

对每天在真实仓库里工作的开发者来说，体验往往由四个变量决定：一次任务能否在额度耗尽前完成；中断后能否准确恢复上下文；用户能否预测下一次可用时间；额度消耗是否和实际产出相称。

因此，模型的“便宜”不能只看 token 单价，模型的“慷慨”也不能只看某一天有没有重置。更有用的指标是：每个被接受的代码变更，需要花多少钱、多少轮交互和多少人工返工。

记录任务开始时的剩余量、模型、effort、工具调用次数和结束原因。给 agent 工作流设置预算边界；用测试、lint 或类型检查证明结果，而不是让模型重复自我验证；长任务要设计可恢复的检查点。

Codex 去掉或隐藏 5 小时限制、OpenAI 反复重置周额度、Tibo 在 X 上调侃 Claude，这些事件属于同一场竞争：谁能把昂贵的 agent 计算，包装成用户愿意持续购买的日常生产力。

重置按钮可以修复一次事故，也可以把一次模型发布变成试用机会。但它也会制造产品债务：当用户习惯了“总会有人按按钮”，稳定规则就变得不再可信。

我们不需要替 Tibo 判断谁真的害怕。更值得关注的是：AI coding 的下一轮竞争，不只在模型能力上，也在额度透明度、恢复机制和用户能否安心把工作交给 agent 上。

免费额度会让人开心一会儿。可预测的额度，才会让人留下来。