一份普通的 JSON 文件改动,64 行新增,54 行删除。2026 年 7 月 18 日,GitHub PR #33972 合并进 release/0.144 分支,标题是"Backport refreshed bundled model metadata to 0.144"。其中一项改动是:Codex 标注的上下文窗口,从 37.2 万 token 调整到了 27.2 万 token。
单看这两个数字,很容易读成"模型能力被砍了三成"。但 PR 页面没有变更说明,也没解释这个字段具体指什么。更谨慎的判断是:这更像一次模型元数据的校准,不是底层模型容量被削减。
| 项目 | 内容 |
|---|---|
| PR 编号 | #33972 |
| PR 标题 | Backport refreshed bundled model metadata to 0.144 |
| 目标分支 | release/0.144 |
| 合并时间 | 2026 年 7 月 18 日 |
| 改动规模 | 单文件,64 行新增,54 行删除 |
| 上下文标注 | 372,000 → 272,000 token |
标注数字变了,不等于模型变笨了
"上下文窗口"这个字段,在客户端代码里通常不是模型真实容量的唯一真相,而是客户端认为安全可用的输入上限。模型厂商公布的总上下文,往往包含系统提示词、工具调用记录、输出预留空间。客户端为了不让请求因超限报错,会把可用额度主动往下压一截。
372k 到 272k 的变化,更可能是 Codex 团队重新核算了输出预留和安全边际之后,把一个偏乐观的标注值,改成了更保守的实际可用值。这类回补式修复,在编码代理产品里并不少见,通常伴随小版本更新,很少单独发公告。同类工具如 Cursor、Claude Code,也普遍把"模型总上下文"和"客户端实际开放的输入额度"分开处理,两者不能划等号。
需要说清一点:PR 页面没有展示完整 JSON diff,这个字段是否包含输出预留,目前只能靠推测。是否属实,还要等官方说明确认。
三层 token,只有一层决定体验
一个上下文窗口数字,其实可以拆成三层:模型总上下文、客户端实际开放的输入额度、预留给输出和压缩触发的那部分。Codex 这次改的,是中间那一层的标注值。真正决定长任务能不能跑完的,是第三层——压缩和截断什么时候触发。
如果客户端在标注值下调后,同时收紧了压缩触发点,长任务会更早被打断或摘要化,即便模型本身没变。如果只是标注更准确、触发逻辑没动,升级前后体验应该没有明显差别。这一层机制目前没有对应的说明文档,只能靠实测验证。
两类人分别该做什么
对用 Codex 处理大型仓库、跑长会话重构的开发者,重点不是记住这两个数字,而是验证升级前后行为是否变了。对评估编码代理部署的企业研发负责人,重点是别把这次调整当成技术故障或成本削减去解读,先确认字段口径再排升级计划。
| 读者 | 该做什么 |
|---|---|
| 大代码库 / 长会话开发者 | 升级 0.144 前后各跑一次同样的长任务,对比是否提前触发截断或摘要压缩;单次会话减少载入文件数,跨文件重构分阶段提交 |
| 企业研发负责人 | 先向 Codex 团队确认标注值是否含输出预留,再决定是否把 0.144 纳入正式发布计划;不要拿 372k、272k 这两个数字直接测算预算或并发容量 |
接下来该看什么
三件事值得盯。一是 OpenAI 会不会补发说明,解释这个字段的准确定义。二是 0.144 版本的长任务在实测里,是否比之前更容易被截断或摘要压缩。三是后续版本会不会延续这次"标注下调"的模式,变成常态化的口径校准。这三点目前都没有确认信息,只能靠实测和后续版本记录去验证。
【锐评】数字易见,机制难查;决定代码读不读得完的,从来不是标注牌上那个数。