技术热点透视20261007：Codex 重置了，但 28 天承诺才刚开始
原创 · 约 16 分钟阅读 · 阅读 --

技术热点透视20261007：Codex 重置了，但 28 天承诺才刚开始

作者: Alex Xiang

人工智能工程实践

本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。

扫码注册 WorkBuddy 即可获取 2000 积分

我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。

今天上午 11:28，我的 Codex 额度重置了。距离 Tibo 在 X 上立下那个「28 天」承诺，只过去三天。这三天里发生的事，值得单独写一篇——不是因为重置本身有多新鲜，而是因为这三天把一个产品承诺机制里所有能出问题的地方，挨个撞了一遍。

事情的起因：一句承诺

先把来龙去脉说清楚。

OpenAI 的产品与平台负责人 Thibault Sottiaux（社区里叫 Tibo，重置哥、赛博义父）在 10 月 5 日发了一条帖子，大意是：未来 28 天，每一天，要么推出一项对大多数 Codex / Work 用户明显有用的改进，要么就做一次完整的额度重置。

注意这条承诺的结构，它不是「我们会在 28 天内持续改进」，而是一个每天都要交付的二选一。有改进，就更新；没改进，就赔额度。用户至少不会空手。

这条承诺的上下文是用户投诉的集中爆发。往前数一周：9 月 25、26 日 Codex 与 Work 连续故障，随后给付费账号做了额度重置；9 月底 GPT-6 Astra 质量问题复盘，又是一次重置；9 月 29 日 DevDay 一天端出 20 多项更新；10 月 1 到 3 日 GPT-6.1 Sol 负载暴涨，Tibo 10 月 2 日道歉并给全体付费账号做全局重置，10 月 3 日还在追查 Pro 500 档没吃到重置的用户。

所以这条承诺本质上是用一种公开的、可逐日核对的机制，去偿还累积的信任欠账。Tibo 在访谈里说过一句自嘲的话：还能重置多少次，取决于「我们把东西弄坏多少次」。这句话比那条 28 天承诺更诚实。

Day 1：速度确实快了 50%

第一天交的是速度。GPT-6 Astra 和 GPT-6.1 Sol 在订阅体系下的默认输出速度，从大约每秒 30 个 token 提到 50 个，官方说法是「快了约 50%」。用户侧什么都不用改，两小时内生效。

这个选择很聪明。Agent 的工作形态是读文件、改代码、跑测试、失败重试的循环，单次交互的等待时间会被上百次往返放大。token 速率提升 67%（30→50），对长任务的实际吞吐影响比模型能力提升更直接。而且它覆盖了所有通过 ChatGPT 登录的用户，以及 OpenCode、Pi、Amp、Devin 这些第三方接入方——等于用一次基础设施优化，同时讨好了一大片用户。

Day 2：「一个」变成了 2.1 到 2.4

第二天，节奏突然变了。Tibo 没有交一项更新，而是一次放出四项：

  • 2.1 Auto-review（就是权限菜单里的「Approve for me」）对所有 ChatGPT 登录用户免费，且不再消耗套餐用量。这个功能本身 4 月就发布了，Auto-review 原本会吃掉套餐用量的 2% 到 10%，现在归零。
  • 2.2 API 付费用量档位从五档精简为三档（Build / Launch / Grow），最高档 Grow 的门槛从累计 1000 美元降到 500 美元。
  • 2.3 Meetings 插件，把会议记录、纪要和待办自动写进 ChatGPT Space。仅限 macOS 桌面端的 Pro 与 Business（Beta）。
  • 2.4 Decisions API 开放公测，让模型、工具和动作的选择快到几乎瞬时，官方称比通过 Responses API 调 GPT-6 Luna 快最多 10 倍。

到这里，「每天一项改进」这个承诺在第二天已经被重新定义了。不是「一项」，是「2.1 到 2.4」——用小数点切分出来的四项。发布 2.2 之前 Tibo 还先说了一句「这是个小更新」，诚实是诚实的，但计数方式相当灵活。

Day 3：76% 的人说，还是重置吧

10 月 7 日早上，Tibo 发了一条总结帖，然后紧跟一个投票。投票只有两个选项：「今天是好日子」和「需要重置」。

结果很直接：74,565 票，76% 选了「需要重置」。

投票之后，有人留言说「今天是好日子，但需要重置」，Tibo 的回复是「数学对不上，但规则就是规则」——他没说明是哪条规则。

然后就是今天上午 11:28，额度重置落地了。

28 天承诺的兑现结构

三个词都没有判据：承诺机制的真正漏洞

把这三天摊开看，会发现「28 天承诺」真正的风险不在数字，而在定义权。

承诺里有三个关键词：「明显有用」、「大多数用户」、「一项」。三个词都没有可验证的判据。

Day 2 的四项更新，正好卡在这个模糊地带。2.1 面向所有 ChatGPT 登录用户，但需要自己在设置里开启，默认不生效；2.3 只覆盖 macOS 的 Pro 和 Business；2.2 和 2.4 面向 API 开发者。严格按字面，只有 2.1 够得上「对大多数 Codex/Work 用户明显有用」，另外三项的目标人群压根不同。把它们加总成「一项」，是修辞，不是会计。

而 Tibo 同时握有出题权和判卷权。他决定什么算「一项」，也决定投票结果怎么用。有用户留言警告不要用「小赢」来规避重置，Tibo 的回应是「这不算回避，我们今天有三次更新」——那时其实已经有三项了，第四项随后才到。

「二选一」为什么总会退化成「或」

更深一层的问题在于：这个二选一的两条腿，成本差了一个数量级。

两种重置的对比

额度重置的边际成本极低——后台改一个计数器，不需要改模型、不需要改架构、不必承认问题出在哪，而且用户立刻拿到好处。问题解决的代价则完全不同：要定位（是模型降智、任务断连，还是容量不足？），要改推理栈、调度、沙箱策略，还要公开承认之前的判断错了。而且用户当场看不出差别。

所以从执行角度看，「改进 或 重置」这个承诺，只要选便宜的那条腿就自动合规了。用户也清楚这一点，所以才会有 76% 投「需要重置」——他们要的不是四个各自只覆盖一部分人群的更新，而是一个立刻可用的额度。

这不是说重置不该做。作为补偿，它完全合理，甚至 Tibo 在访谈里说得对：出了问题就该赔。问题在于，补偿一旦成为可预期的常规操作，它就从「修复失败后的补救」变成了「产品交付的一部分」。承诺把补偿写进了 SLA，于是补偿不再是意外的善意，而是被计入计划的成本项。

这件事对使用者的实际含义

抛开机制分析，说几条务实的。

Auto-review 值得去开。 这是 Day 2 唯一一项对所有用户都有实际好处的更新——如果你在用 Codex 的沙箱权限模式，它原本会吃掉你 2% 到 10% 的套餐用量，现在这部分完全免除，而且开启后主 agent 连续工作时不那么容易被权限确认打断。默认是关的，需要在设置里手动启用。

别为重置去囤额度。 重置通常是把你现有的桶换成一个满的，不是额外叠加。为了等重置而留着额度不用没有意义。

自己的 Usage 页面是唯一权威。 第三方监控站（resetbeacon、codexreset 之类）预测的是「全局重置」的时机，不覆盖你自己的 5 小时窗口和滚动 7 天窗口。这两者是完全不同的东西——很多人在这里产生误解，看到监控站说「几天没重置了」，其实只是自己的周窗口正常关闭了。要看自己的额度，跑 /status。

10 月 30 日的 Pro 200 变更没有被取消。 承诺里没有提这件事，20x 降到 10x 的调整仍在日程上。这提醒一句：承诺覆盖的是「每天交作业」，不覆盖产品线的整体调整方向。

最后

三天里最值得记住的，不是速度快了 50%，也不是拿到了重置，而是一个更朴素的事实：

一个把补偿写进承诺的机制，短期能买到很多掌声，长期会失去它要买的东西——用户的相信。

APPSO 那篇评论里有句话说得比谁都准：「Tibo 的作用——心情开心：reset；服务异常：reset；模型降智：reset；模型太慢：reset。但是好像从来没有解决问题，而是解决了我们。」

Tibo 按下重置键只要不到一秒，用户要自己付的返工时间却是真实的：任务中断后重新交代背景、检查它做到了哪一步。这些时间不会因为额度满了而回来。

28 天还剩 25 天。承诺会一天一天兑现下去，投票也许每天都会有人发起。我会继续看下去——尤其是看它到底是每天都在交作业，还是每天都在交额度。这两件事在纸面上长得一模一样。

参考资料

打开原图 ↗