从 Claude Code 切到 Codex 后，很多人想通过 model_context_window 把上下文从 258k 调到 1M，却发现完全不生效。本文解释窗口上限由模型服务端决定、客户端参数只影响压缩触发点，并对比「大窗口是否必要」的两种看法，给出自动压缩、任务拆分、用文件保存上下文等可操作做法。
从 Claude Code 换到 Codex 的人，第一周常常卡在同一件事上：模型侧给出的上下文窗口只有 258k 左右，而之前习惯了 1M。于是很自然地在全局配置里写上 model_context_window = 1000000、model_auto_compact_token_limit = 950000，结果发现毫无变化。
这背后是一个常见误解：客户端配置能不能决定上下文大小？答案基本是否定的。下面把这个问题的成因、社区里的分歧和可行做法拆开讲。
先明确：上下文窗口上限由模型服务端决定
model_context_window 这类参数，在多数 CLI 里起的是「声明」或「下限」作用：客户端据此估算何时该触发压缩、还剩多少空间。它不会向服务端申请更多窗口。一旦请求真的超过模型支持的长度，服务端会截断或报错，不会因为本地写了一个大数字就放宽。
于是会出现这种因果链：配置改大 → 客户端以为空间很充裕 → 迟迟不压缩 → 更容易在真实上限附近突然出现问题。
真正决定 258k 的，是模型在该入口下的规格。讨论中有说法认为 API 侧与订阅入口的规格并不一致，这类信息变动频繁，务必以官方文档和控制台显示为准，不要拿社区传言当配置依据。
为什么改了配置「完全没反应」
| 现象 | 原因 |
|---|---|
| 改了全局配置仍是 258k | 上限由服务端决定，本地只是声明 |
| CLI 里看着生效，桌面 App 不生效 | 两者读取的配置与元数据来源不同 |
| 手动改了客户端的模型元数据文件 | 只改变显示和压缩触发点，服务端上限不变，还可能导致请求报错 |
有一种流传的做法是去改本地模型目录里的元数据文件，让客户端「认成」更大的窗口。它顶多改变前端展示和压缩时机，不会真的扩容；反而因为压缩被推迟，长会话更容易出现截断或质量骤降。不建议把它当成解决方案。
大窗口是否必要：两种看法
一种看法是 258k 够用，压缩做得好。 自动压缩在压缩前后差别不大，因此不必盯着使用率，也不需要频繁清理会话或重开窗口，把注意力放在任务本身即可。
另一种看法是小窗口就是不方便。 读长文档、财报分析、跨多个模块重构这类任务，258k 很容易被打断；上下文接近上限后模型会「变笨」，之前执行过的操作也记不住。
还有几点折中的观察值得记下：
- 窗口越大，单次请求消耗的 token 越多，成本和延迟都会上去；
- 有效注意力不随窗口线性增长，超过一定长度后幻觉和「漂移」的概率会升高——有反馈称某些模型到 350k 以上漂移就很明显，需要手动设置压缩上限；
- 新开一个干净的会话，往往比硬塞进一个超长会话更准确。
结论不是谁对谁错，而是：短平快的连续任务，长窗口收益有限；需要一次性喂入大量材料的分析类任务，长窗口或外部检索才真正有意义。
可落地的做法
1. 先把自动压缩用明白（推荐默认）
- 不要在配置里虚报窗口，保持默认，让压缩按真实上限触发；
- 一个任务结束就结束会话，不要一个窗口一路跑到低；
- 每个任务开头用一两句话复述目标与约束，压缩后模型更容易接回来；
- 一旦发现回答开始答非所问、忘记前面的约定，就主动压缩或新开会话，不要硬撑；
- 关键结论（接口约定、目录结构、复现步骤）随时写进仓库文档，不依赖对话记忆。
2. 用文件承载上下文，而不是堆在对话里
- 项目根目录放
AGENTS.md一类的说明文件，写清技术栈、常用命令、代码风格与禁止事项； - 长任务用
plan.md或TODO.md记录进度与决策，压缩后让模型先读它； - 大文档、日志先做摘要或切片，只把相关片段喂进去。这就是检索增强的思路，比硬塞满窗口更省也更准。
3. 确实需要更大窗口时
- 换用在当前入口下窗口更大的模型，同系列不同型号规格并不相同，具体数值以官方说明为准；
- 走 API 并自行承担成本，规格看控制台。注意第三方中转渠道存在账号合规与数据安全风险，能走官方就不要走中转；
- 把任务拆成多个阶段，每个阶段一个会话，用文件传递中间结果——多数情况下这比追求单窗口 1M 更稳。
4. 对齐客户端
- CLI 与桌面 App 读取配置的位置不同，改了一处不代表另一处生效，先用最小改动验证一次；
- 需要在执行中向用户确认的场景，可以查一下客户端是否提供「请求用户输入」类的开关，不同工具里名字不一样，按官方文档配置。
注意事项
- 具体窗口数值以及不同入口之间的差异属于会变化的规格，本文引用的只是讨论中的说法，请以官方文档与实际控制台为准；
- 不要为了「看起来更大」去改客户端元数据，收益低、副作用明确；
- 长会话本身怕中断：本地休眠、断网、进程被终止都会让正在跑的会话丢状态，压缩再智能也救不回来。如果确实需要长期挂着一个会话跑批处理，把它放到一台能长期在线的机器上（例如按月租用、放在机房里的远程 Mac）会比本地笔记本省心；纯短任务则完全没必要。
小结
258k 并不是配置写错了，而是当前入口下的模型规格。客户端参数只决定「什么时候压缩」，不决定「能装多少」。把自动压缩、任务拆分、文件沉淀这三件事做好，多数人不会觉得窗口是瓶颈；如果确实需要一次性吃下大量材料，再考虑换模型或走 API，同时接受成本与精度上的取舍。