# Codex 额度重置已达 35 次，为何用量明细仍是谜？ **Summary:** 截至 7 月 19 日，Codex Resets 已记录 35 次公开的额度重置。免费续杯固然令人开心，但它无法告诉我究竟是哪个任务耗尽了额度，或者账目是否准确。 - Canonical: https://markhuang.ai/zh/news/codex-35-resets-button-is-the-product - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-07-19 - Section: News - Tags: AI, Codex, 开发者工具 - Source: [Codex Resets](https://codex-resets.com/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![卡通开发者和机器人看着一个巨大的重置拉杆为发光的用量表重新注满](https://cdn.markhuang.ai/news/codex-35-resets-button-is-the-product/hero.webp) *意外的续杯在当下感觉很慷慨。但经历足够多次后，这个按钮本身就成了产品运营方式的一部分。* 2026 年 7 月 19 日，我查看了[Codex Resets](https://codex-resets.com/)网站，这个非官方追踪器显示已有 35 次公开宣布的重置，平均间隔 8.9 天，最长一次间隔长达 67.7 天。该网站专门追踪 OpenAI 的 Tibo Sottiaux 在 X 平台上发布的重置公告，并将其整理成一份为期 26 周的日历和公告日志。 我的第一反应是觉得有趣——居然有人为 Codex 的重置按钮做了个“天气预报”。但转念一想，情况就没那么轻松了：如果开发者需要依赖一个独立网站来跟进这些意外的续杯，说明这些续杯本身已经成了用户理解产品的方式。重置可以是一次诚恳的致歉、一场促销活动，或是对突发问题的快速补救。但它终究无法替代一套清晰、可预测、可审计的用量核算体系。 ## 答案快照 | 问题 | 我的看法 | | --------- | -------------------------------------------------- | | 这个网站追踪什么？ | 追踪 Tibo Sottiaux 发布的公开重置公告，以日历和时间线日志的形式展示。 | | 它展示了什么数据？ | 截至 7 月 19 日，共记录 35 次重置，平均间隔 8.9 天，最长间隔 67.7 天。 | | 为什么会发生重置？ | 已记录的公告提到了多种原因，包括服务中断、延迟过高、用量调查、促销活动、系统变更以及庆祝用户里程碑。 | | 我的结论是什么？ | 这个追踪器很有用，但产品更需要的是清晰的用量解释，而不是靠惊喜式的慷慨来弥补。 | ## 追踪器将零散事件变成了可见模式 这个网站的价值，并不在于揭示了某个秘密政策——它并没有。网站明确声明[与 OpenAI 无任何关联](https://codex-resets.com/)，仅以 Tibo 的公告作为数据源，并对其进行自动分类。因此，我不会把 35 这个数字当作所有后台操作或账户专属福利的完整记录。 但它确实让节奏变得可见。日志中包含了因事故、高延迟、计费系统重构而触发的重置，也记录了一次促销额度增加——据估计约有 9% 的 Plus 和 Pro 用户未能收到，以及庆祝用户里程碑的奖励。近期的条目还区分了自动应用的全额重置和用户可留到以后用的“可存储”重置。 ![卡通开发者和机器人研究一堵日历墙砖上不规则闪烁的发光脉冲](https://cdn.markhuang.ai/news/codex-35-resets-button-is-the-product/reset-pattern.webp) *这个追踪器之所以有用，是因为它让一种不规律的产品行为在时间维度上变得清晰可见，尽管它并非官方账本。* ## 一个“重置”按钮，承担了多重角色 如今，“重置”这个词实际上涵盖了多种不同的产品功能。它可以是在服务降级后对用户的补偿，在用量核查期间争取的时间，也可以是对新模型或功能的推广。尽管用户看到的都是每周额度表瞬间回满，但背后的原因却大相径庭。 这种模糊性很重要，因为 OpenAI 的[Codex 计划文档](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan)指出，任务消耗量会根据工作规模与复杂度、所用模型以及运行位置而变化。更大的代码库、长时间运行的任务和会话都会消耗更多额度。当用户触及上限时，可选方案可能包括购买积分、升级套餐，或等待额度自动重置。 > **Info:** > > OpenAI 的[推荐计划条款](https://help.openai.com/en/articles/20001271)确认，促销福利可能是 Codex 速率限制重置、临时额外用量或积分。具体的上限、有效期、可用性和资格会因优惠活动、套餐、工作区、地区或促销而异。 ## 免费额度也会带来规划成本 当周额度即将耗尽时，一次重置听起来无疑是好消息。但如果重置发生在用户还没打算用完剩余额度之前，或者"可存储"重置带有有效期，事情就变得微妙了。在最近一篇[r/codex 的讨论帖](https://www.reddit.com/r/codex/comments/1uu2c1g/reset_discussion_megathread/)中，用户们纷纷吐槽错过重置、重置似乎未生效、有效期不明，以及较短的使用窗口和周额度之间的冲突让人很沮丧。这些都是用户报告，并非单一系统缺陷的证据，但它们清楚地表明，背后的机制亟需直白的解释。 新的费率卡让这一需求更加迫切。OpenAI 表示，自 2026 年 4 月 2 日起，Codex 定价从按消息估算改为针对 Plus、Pro、Business 和新 Enterprise 套餐的[基于 Token 的积分计费](https://help.openai.com/en/articles/20001106-codex-rate-card)，其余现有 Enterprise 套餐则在 4 月 23 日跟进。输入、缓存输入和输出 Token 的积分费率各不相同。这比模糊的消息计数更清晰，但前提是用量视图能帮助用户将具体任务与额度变动联系起来。 ![卡通开发者和机器人在发光的续杯胶囊与未完成的工作之间权衡](https://cdn.markhuang.ai/news/codex-35-resets-button-is-the-product/budget-tradeoff.webp) *一个"可存储"重置会带来真实的决策：现在就用掉续杯，为更大的任务存着，还是冒着误解其过期时间的风险？* ## 质疑的核心在于证据缺失 我认为最有说服力的批评，并非指责重置是一种骗局，而是指出续杯无法解释额度为何被耗尽。2026 年 5 月，一个公开的[Codex GitHub Issue](https://github.com/openai/codex/issues/23188)报告称，在接近五小时边界时，周剩余额度从约 70% 骤降至约 7%。报告者附上了本地日志细节和可能的解释，但该问题仍在调查中，目前只是用户报告，尚未确认根本原因。 公开报告可能指向计费漏洞、缓存上下文行为、后台任务、显示同步问题，或者仅仅是工作负载的实际成本超出了用户预期。一次全面重置可以在所有这些情况下缓解用户的燃眉之急，但它无法告诉用户究竟发生了哪种情况。 ![卡通开发者和机器人检查发光的用量 Token 在透明管道中流动](https://cdn.markhuang.ai/news/codex-35-resets-button-is-the-product/usage-audit.webp) *持久的解决方案是一条从任务到 Token 流再到配额影响的可追溯路径。重置阀门只能改变最终的水位。* ## 我真正想要的是什么 我会保留重置按钮。当服务中断或计费问题伤害到用户时，它是一个合理的恢复工具，而"可存储"重置也确实能派上用场。但我希望每次重置都能在产品内给出清楚的说明：为何发放、补充哪个额度池、是否改变了滚动窗口、何时过期，以及是否已自动应用。 用量侧也需要同样对待。开发者应该能看清是哪个任务、哪个模型、在哪个执行界面上推动了额度表，并且缓存用量和输出用量要清晰分开，以便调查意外情况。OpenAI 已经告诉用户去监控用量面板，其定价现在也直接将积分映射到 Token 类别。剩下的工作，就是在关键时刻让这套计费逻辑变得易于理解。 ## 我的总结 Codex Resets 是个巧妙的小网站，但它的存在恰恰暴露了一个更大的产品缺口。35 次追踪到的公告并不能证明 Codex 不可靠，追踪器本身也明确说明了其非官方性质。但它们确实表明，重置已经成了一种反复使用的手段——用来应对事故、做促销、调容量、安抚用户。 我欣赏免费的额度。但如果我不需要一个追踪器来搞清楚按钮何时被按下，也不需要一个论坛帖子去猜测续杯到底改变了什么，我会更加信任它。重置应该始终是安全阀，而不该变成用户手册。