10 月 12 日（北京时间），OpenAI 把 GPT-6.1 Sol 在 Codex 与 Work 中的默认上下文长度从 272k 提到 500k，增幅约 80%。这条消息由 Codex 负责人 Tibo 发布：尽管 OpenAI 未来还会继续提高上限，但这一调整已能显著降低上下文压缩的触发频率，让需要长期保留大量上下文和复杂细节的任务跑得更从容。 在他的说法里，500k 是仔细测试后对大多数用户的最佳平衡点，用户仍可手动覆盖到 1M。 这里要争的不是参数表上的窗口竞赛：此前开发者观察到 Codex 默认值大约在 200k 到 300k 之间，真正的代价是“压缩”——上下文写满后系统把早期内容摘要丢弃、腾出空间，任务还能继续，丢掉的却是刚刚执行过的细节。微博微博微博
变的是默认值，不是模型
GPT-6.1 Sol 还是 9 月底开发者活动日上发布的那个模型：据官方介绍，它在智能体编程、电脑操作和专业工作流等任务上的性能接近旗舰 GPT-6 Astra，而标准输入/输出 token 价格仅为 Astra 的五分之一。 发布两周以来，几乎每周都有一件影响体验的大事：10 月 7 日，OpenAI 把 GPT-6 推向全球所有 ChatGPT 用户，付费的用 Sol、免费的用 Luna。 10 月 8 日，OpenAI 又给 6.1 Sol 加了 Ultrafast 极速模式，API 单价翻到标准档的 6 倍，官方说法是速度最高提升 8 倍。微博知乎知乎
而这次默认上下文提至 500k，正是那条 28 天更新系列公开的第七件事，补丁包的顺序大致说明了 OpenAI 认为这个模型还缺什么。微博
免费与否，取决于你用订阅还是 API
API 侧，6.1 Sol 定价为每百万 token 输入 2 美元、输出 10 美元，缓存输入只有 0.10 美元——上下文变大后，反复复用的长前缀按这个价格计费，实际账单涨幅取决于缓存命中率而非窗口大小。 订阅侧则是另一回事：Tibo 明确，通过订阅使用 GPT-6.1 Sol 时，不会额外收取长上下文费用。 所以同一个 500k，对 Codex 与 Work 里的开发者是零成本扩大的工作空间，对直接调用 API 的团队则意味着要重新核算提示复用率，把便宜的缓存输入用满。知乎微博
窗口变大，会不会更慢
上线初期，Codex 里 6.1 的速度曾是社区集中吐槽的点，有实测称生成速度只有 13–20 tok/s，比 Claude Opus 慢 3–5 倍。 “更大的上下文等于更慢”的担心并非没有来由，但目前的证据指向别处。知乎
那篇把 Codex 拆开实测的内容给出的结论是：prefill 不是瓶颈——13.7k token 的输入，相对 201 token 只多了 0.5 秒；慢的大头是客户端本地开销，模型和网络都不慢。 如果这个归因成立，默认上下文翻倍主要增加的是排队与缓存失效层面的风险，而不是首字延迟本身；此前社区“长上下文 TTFT 劣化”的个别报告，也更可能来自排队和缓存，而非计算本身。知乎
还有一层边界要画清楚：这次只是产品默认值调整，500k 满载下的细节检索与长程推理表现，官方没有给出评测数据，“最佳平衡点”目前是配置意义上的权衡；1M 属于手动覆盖，能否稳定跑满、代价如何，暂无可核验的结果；上限还会继续提高，但没有时间表。眼下最实际的观察信号，是 Codex 或 Work 会话里压缩提示出现的频率——它明显变少，说明这轮调整正好落在你的长任务上；若走 API，则要确认智能体的上下文复用能吃到缓存价，扩大的窗口才划算。
