2026 年 7 月 18 日，OpenAI 的一位工程师合并了一个不起眼的 Pull Request。标题平淡无奇——「Backport refreshed bundled model metadata to 0.144」。改动只有 64 行新增、54 行删除，文件路径是 codex-rs/models-manager/models.json。
但其中一行变更，足以让每个依赖 Codex 做重型开发的工程师停下手里的工作。
- "context_window": 372000,
- "max_context_window": 372000,
+ "context_window": 272000,
+ "max_context_window": 272000,OpenAI 把 GPT-5.6 Sol 在 Codex 中的上下文窗口从 372K 砍到了 272K——缩减约 27%。没有公告，没有 Release Note，没有提前通知。只有一个静默合并的 hotfix。
对不熟悉 AI 开发工具的人来说，100K token 的差异可能只是一个抽象的数字。对正在用 Codex 处理大型代码库的开发者来说，这个改动意味着昨天还能正常工作的 Agent 工作流，今天突然报错退出。我们的一个同行在 GitHub Issue #32806 里写道：「这不是 UI 显示问题。实际运行时从 model_context_window: 353400 变成了 model_context_window: 258400，工作流直接中断。」
372K → 272K 的实际影响
先解释一下数字。GPT-5.6 Sol 公开 API 文档标注的上下文窗口是 1,050,000 token。但 Codex 作为客户端产品，从未给用户开放过完整窗口。此前 Codex 内部配置将上下文窗口设为 372K，经过 95% 的有效利用率折算后，实际可用约 353,400 token。
这次 hotfix 把内部上限从 372K 拉到 272K，折算后只剩 258,400 token。也就是说，Codex 用户实际可用的上下文窗口，只有公开 API 标注值的 24.6%。
对于不了解 token 计量方式的读者：一个 token 大致等于 3/4 个英文单词或大约 0.5 个中文字。353K token 大约能容纳一个中等规模项目的核心代码加上几轮对话历史。258K token 则意味着同样的项目，Codex 会更早地「忘记」前面的对话——或者更直白地说，更早地罢工。
这种降级对两类用户影响最大。第一类是使用了 Codex 的重度 Agent 模式用户——他们会同时启动多个 Agent 并行处理不同模块，每个 Agent 都需要足够的上下文来理解代码结构。第二类是依赖 Codex 处理遗留系统迁移的团队，他们的代码库本身就大，每一轮对话都可能触及上下文上限。对这些人来说，这意味着之前建立的开发流程需要重新设计——开发流程本身建立在上下文窗口足够大的前提上，前提一旦被抽走，整套流程就得推倒重来。
「Codex Resets」不是一次性的意外
如果你以为这只是 OpenAI 的一次临时调整，那说明你还没听说过「Codex Resets」这个词。
在 2026 年的开发者社区中，「Codex Resets」已经成为一个专有名词。它描述的是一种反复出现的模式：OpenAI 在没有任何预告的情况下改变 Codex 的行为参数——可能是上下文窗口、可能是速率限制、可能是模型路由——导致依赖该工具的开发者工作流突然断裂，然后社区愤怒，最后 OpenAI 通过某位员工的社交媒体账号做一个简短的非正式说明。
社区甚至为此建立了一个专门的追踪网站：codex-resets.com。网站首页用黑色幽默的语气写着：「Sometimes, without warning, @thsottiaux tweets that OpenAI has reset everyone’s Codex usage limits. There is no schedule. There is no changelog. There is only the feed.」
截至 2026 年 7 月 18 日，该网站记录了 35 次重置事件，平均间隔 8.9 天，最长的一次「干旱期」长达 67.7 天。每次重置的原因各不相同——有的是为了应对用户量暴增带来的算力压力（Codex 在 2026 年 7 月的两周内从 600 万用户增长到 800 万），有的是为了弥补服务中断，有的则完全没有给出解释。
这次的上下文窗口削减，虽然没有被正式列入该网站的「重置」记录中（它追踪的主要是使用额度重置），但完全符合「Codex Resets」的行为模式：静默变更、用户自行发现、社区告警、事后解释缺位。
开发者工具需要可预测性
笔者想在这里停下来讨论一个基础问题：为什么开发者对 API 产品的稳定性要求远高于普通消费产品？
答案在于「可预测性」三个字。当你把一个 API 或开发工具集成到自己的工作流中时，你实际上是在它的基础上搭建了一套「假设」。你假设明天的 API 行为和今天一样，你假设某个参数的上限不会突然减半，你假设你不会在半夜被报警电话吵醒因为依赖的服务改了接口。
这些假设不是可有可无的偏好——它们是工程决策的基石。一个团队如果无法信任自己依赖的工具会保持行为稳定，他们就不得不为每个依赖项预留「防御性工程」的预算：抽象层、降级策略、多供应商备份。这些额外成本在前期的技术选型中往往被忽略，但当工具开始出现不可预测的变更时，它们会迅速侵蚀最初选择该工具带来的效率收益。
OpenAI 这次的操作恰好撞在了这个最敏感的环节上。372K → 272K 本身是一个可以讨论的工程决策——算力紧张、用户激增、需要做容量管理，这些理由工程师群体完全能理解。真正激怒社区的是操作方式：没有提前通知，没有过渡期，直接合并到 release 分支，用户在自己的 Agent 突然报错之后才发现问题。
HN 社区的反应：愤怒、幽默与实用主义
这个 PR 被合并后，社区反应迅速从 GitHub Issues 蔓延到了 Hacker News。一条获得广泛共鸣的评论来自用户 Lwrless：「那些重置和 5 小时使用限制的取消，正在静悄悄地把我锚定到一个更高的使用基线。我不再节约使用，直接派出一堆 Agent 以任意速度工作，因为总感觉还会有更多重置在路上。现在我真正担心的是——如果有一天他们不再重置了，我的『正常』工作流会突然超出限制，而升级套餐会感觉像在退步。」
这段话精准地描述了一种被经济学家称为「道德风险」的动态：供应商的临时性补贴改变了用户的行为模式，但当补贴停止时，用户已经无法回到原来的行为模式。在 Codex 的语境下，频繁的使用额度重置让开发者养成了更「豪放」的使用习惯，而上下文窗口的缩减则从另一个方向收紧了约束——两条线一拉一收，中间的开发者被夹在了一个不稳定的预期空间里。
另一位用户 sebjones 的评论更直接：「所有这些重置都是因为有竞争对手。当他们赢了市场，我们就会被榨干。」这条评论有些阴谋论的色彩，但它指向了一个真实的结构性问题：当你的核心开发工具由一家同时在与竞争对手激烈厮杀的商业公司提供时，你今天享受到的「慷慨」到底有多少是来源于 CEO 的善意、有多少来源于竞争压力下的战术选择？
还有一批评论转向了更宏观的讨论：在开放权重模型逐渐逼近前沿能力的时代，AI 工具市场的竞争到底会走向「竞相降价」还是「差异化锁定」？有人指出，Moonshot 的 Kimi 系列虽然承诺开放权重，但在 K3 版本中价格反而上涨了近 6 倍——「竞相降价」只会发生在能力增长遇到天花板之后，在那之前大家竞相提价。
更大的问题：供应商锁定
如果把视野拉得更高一些，这次上下文窗口削减折射出的问题远不止一个参数变更。
Codex 的核心商业模式建立在「免费使用 + 付费升级」的框架上。但这个框架有一个隐含的前提：用户在免费使用过程中积累的上下文——对话历史、项目配置、工作流习惯——构成了巨大的切换成本。你已经用 Codex 写了三个月的代码，你的所有项目对话历史都在里面，你对它的命令、快捷键、输出格式已经形成肌肉记忆。这时候 Anthropic 发布了一个新模型，在某些 benchmark 上比 GPT-5.6 高 2 个百分点——你会因此切换吗？
大多数人不会。切换成本太高了——新模型确实好，但它没有你过去三个月积累的对话历史和项目上下文。这就是供应商锁定的经典机制：累积的使用痕迹让用户「懒得离开」，这种摩擦力比任何技术壁垒都有效。
从这个角度看，Codex 的频繁重置和突然的上下文窗口削减之间存在一种微妙的互补关系。重置降低了用户对「消耗」的敏感度——既然随时可能重置，那就放开了用；削减则降低了单用户对算力的消耗——每个人用的少一点，服务器压力就小一点。两者组合起来的效果是：用户在 Codex 生态中越陷越深，但 OpenAI 为每个用户付出的边际算力成本却在下降。
笔者不认为这是一种精心设计的策略。更可能的解释是，OpenAI 的不同团队在独立运作——增长团队推重置、基础设施团队砍窗口、产品团队做功能——彼此之间缺乏协调，最终呈现给用户的是一个行为矛盾的产品。但这种「非故意的」不一致，对用户的影响和一个精心设计的锁定策略没有本质区别。
社区自组织的信号意义
codex-resets.com 的出现本身就是一件值得关注的事情。它不是一个商业产品——没有广告，没有付费墙，只有一个时间线和一段黑色幽默的文案。它是一群开发者用最少的代码、最快的速度搭建起来的一个「公共监督工具」。它的存在本身就是对 OpenAI 透明度缺失的一种回应：既然你不告诉我们什么时候会变，我们就自己建一个追踪系统。
这种自组织行为在开发者社区中并不罕见——GitHub Issues 本身就是一种公开的监督机制，Hacker News 的讨论区是另一个。但 codex-resets.com 的特殊之处在于它的单一功能性和仪式感。它把「追踪大公司的不透明行为」这个行为本身变成了一种文化符号，让每个访问者都能在一秒钟内理解：这家公司的产品策略是不可预测的，而社区正在用自己的方式应对这种不可预测性。
回到这次上下文窗口削减。如果 OpenAI 在合并 PR 之前发了一条简短的公告——「由于近期用户量激增，我们将暂时调整 Codex 的上下文窗口上限，预计在算力扩容后恢复」——社区的反应会完全不同。不是所有的参数变更都会引发愤怒。引发愤怒的是沉默。
在依赖关系高度不对称的情况下，被依赖方的沉默本身就是一种权力的表达。「我不需要告诉你为什么，因为你别无选择。」——当这种信号被反复传递，它侵蚀的是整个供应商-开发者关系的根基——远超出任何一个参数或功能的范畴。
笔者并不想夸大这一次上下文窗口削减的后果。272K 的窗口对很多轻度使用场景来说仍然够用。Codex 作为一个产品，在代码补全、Bug 修复、文档生成等方面的能力依然是业界领先的。8 小时之后，大多数开发者还是会打开终端，输入 codex，继续写他们的代码。
但信任的损耗是累积性的。每一次静默变更、每一次事后才发现的行为变化、每一次需要靠社区追踪网站才能了解到的产品动态，都在往同一个天平上加砝码。当砝码多到一定程度，天平倾斜的结果是「大家开始把 Codex 当作一个不可靠但暂时好用的工具来使用」——这意味着更浅的集成、更少的长期投入、更多的并行备份方案。这些隐性成本不会出现在任何一家的财报里，但它们会缓慢地改变整个开发者工具生态的竞争格局。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接
- GitHub PR #33972：OpenAI Codex context window 372K → 272K
- GitHub Issue #32806：社区对 context 缩减的反馈
- codex-resets.com：Codex 行为变更追踪站
- HN 讨论：Codex Resets (197 分, 139 条评论)
