Codex 上下文窗口缩减影响：372k 降到 272k 后怎么改用法
OpenAI 将 Codex 模型上下文从约 372k 降到约 272k，长会话和大仓库更容易提前触顶。本文说明影响面、怎么观察占用、以及拆会话与降上下文的实操。
OpenAI 侧一次 Codex 相关更新把可用模型上下文从大约 372k 收到大约 272k（社区讨论与 PR 变更见 openai/codex#33972）。绝对值仍远大于早期 32k 档讨论，但对“整个 monorepo + 长代理轨迹”这类用法，触顶会明显提前。本文只谈窗口变小之后你怎么改用法，不争论产品动机。
缩减后最先坏掉的三类场景
- 超长多轮 agent 会话：工具调用、补丁、测试输出叠在同一线程里，窗口被轨迹吃满。
- 大仓库一次塞太多文件：检索把几十个文件摘要塞进上下文，还没改完核心模块就告警。
- “接着昨天继续”：跨天不换会话，历史指令和失败尝试一直占额度。
若你主要做小改动、单文件修复，体感可能不明显。体感变差的往往是本来就在压上限的人。
怎么判断是窗口问题而不是模型变笨
优先看可观测信号，而不是凭感觉骂模型：
- Codex UI / CLI 旁的上下文占用圆点或百分比是否长期贴边。
- 是否反复“忘记”几轮前刚约定的约束。
- 是否开始忽略仓库里已写明的规则文件。
这些现象和 Claude Code 侧的上下文管理类似，可对照阅读 Claude Code 上下文窗口管理，原则通用：少塞、勤归档、会话拆分。
用法调整：比抱怨版本号更有效
拆会话，不要硬续。 一个目标一个会话：修完 bug 或合完一个 PR 就开新线程，把结论写进 issue / PR 描述，而不是指望模型记住昨天的聊天。
先缩小工作集再开 agent。 用路径、模块名、失败测试名限定范围；避免“先读完整仓库再想怎么改”。
中间产物外置。 长计划、接口约定、验收清单落到 markdown 或 ticket，会话里只引用摘要。窗口缩了之后，“写在仓库里”比“写在聊天里”更抗遗忘。
控制工具输出噪音。 大段测试日志、完整 diff 反复回灌会加速触顶；让 agent 摘要失败用例，而不是整份 log 贴回上下文。
和订阅档、模型档不要混谈
ChatGPT 网页、不同订阅、不同 Codex 入口的窗口数字历史上并不统一（早期讨论里甚至出现过 32k 档说法）。你要以当前客户端显示的占用和官方当次说明为准，不要拿旧截图对比新行为。
选型层面，Codex / Claude Code / Cursor 的分工仍可参考 三者怎么选；窗口缩减改变的是单会话容量，不自动改变“该用哪条产品线”的结论。
团队侧可以定的三条规矩
- 超过 N 轮或占用超过 70% 必须开新会话（N 按团队习惯定，常见 15–30）。
- PR 描述必须写清目标、边界、已验证命令，方便下一段 agent 冷启动。
- 禁止把密钥、整库 dump、巨型 fixture 贴进对话。
常见问题
272k 是不是对所有 Codex 入口都一样？
以你正在用的客户端/模型标签显示为准。网页、CLI、不同模型档可能不一致；本文讨论的是“相对上一档变小”带来的用法变化。
能不能靠换更大模型把窗口要回来？
不一定。窗口是产品配置与模型能力的组合，不是“越贵越大”的简单映射。先验证当前标签的上下文上限，再决定是否换入口。
缩减后长重构是不是做不了了？
做得了，但要改成多会话、模块化交付。把一次“改完整个服务”拆成可验收的小 PR，反而更稳。