OpenAI 把 Codex 和 ChatGPT Work 的默认上下文从 272k 挪到了 500k，涨幅接近八成，消息一出，开发者的反应很快分成两拨，一拨盯着能不能靠它少被压缩打断，另一拨第一反应是去看账单，担心视野一宽，额度反而掉得更凶。
开发者 Lasse 早前就公开抱怨过，一次上下文清理能生生拖掉他两分钟。窗口塞满之后，工具得先回头把前面聊过的内容、已经推进的工作重新梳理压缩，空出位置才好继续，麻烦在于梳理完它未必记得住最初的约束，比如项目开头明确要求过「新接口要能带旧版本」，等到改动往外蔓出十几处地方、新功能也验收完了，才发现老接口被改坏，收尾的活还是落回自己手里。
也有人并不买账，开发者 Mhmd Hammoud 在底下留言反问，动一个默认值算不算真正的升级。这个吐槽有它的道理，窗口数字变大是一回事，工具会不会更懂你的项目是另一回事。
官方给的说明分了两层，产品侧的理由是让长任务少被打断、模型能记住更多上下文细节，计费侧则由 Tibo 出面，说订阅用户拿这套额度跑 GPT-6.1 Sol 不会因为窗口拉长而单独加价，消耗照旧从订阅额度里走，真正按量付费的接口调用，价格算法没变。
嘴上说免费，OpenAI 自己却在同一件事上摔过。七月时它把窗口从 272k 试到 372k，给当时的 GPT-5.6 Sol 用，上线后发现订阅额度掉得比预估快，于是又把容量缩回 272k。开发者 Theo 当时的第一反应是，超过 272k 的部分大概被按双倍计价，Tibo 把原因归到了缓存被读得更频繁上。
容易被忽略的一笔账藏在缓存里。机制本身是省钱的，已经算好一遍的内容可以复用，读取单价更低，但复用的每一步依旧会被记账，用户觉得只是发了个「接着做」，后台的智能体却要重新把需求、先前读过的文件、跑过的测试结果一起带上，后面要用工具、要接着推理时，这些材料还可能被一次次重读，攒的内容越多、翻出来越勤，消耗就越可观。
窗口给多大，同行也在较劲。Claude Code 里挂的 Opus 5.5 和 Sonnet 5.5，默认就是 1M 的视野，比这个新默认值还多出一倍，GPT-6.1 Sol 其实也能撑到 1M，用户手动可以调上去，OpenAI 把默认值定在 500k，是内部测完觉得这个档位对大多数人更合适。两边的免费指的不是同一笔钱，Claude 那两款在 1M 以内按标准单价算，OpenAI 省的是订阅里那笔加价，接口调用依旧单独定价。
视野再大也总会被塞满。Claude Code 接着两款模型跑，自动清理的触发点大约在 967k，快到顶时它先动手删掉更早那批工具输出，翻文件、敲命令攒下的记录先出列，空间还是不够，就把整段对话浓缩成摘要，保住当前目标和关键代码。查资料这种活儿还能外包给子智能体，它带着自己的一份上下文去翻，翻完把结论交回来，主对话不需要把整个查找过程原样收进来。
这周 Meta 也没闲着，Muse Wonder 的上下文直接给到一百万 token，窗口拉长不加价。它在数学证明的评测里多答对 36 题，输出 token 却从 450 万降到 270 万，缩掉四成，平均步数由 120 步缩到 62 步。
官方还预告，这个默认值往后仍会一轮轮抬高。就拿缓存来说，同一份资料摆在对话靠前的位置，命中率往往比塞在最末尾更高，项目规范、接口文档这类稳定不变的部分尽量别挪窝，复用才落得到实处，给查资料、跑测试这类子任务单开一份上下文，主对话只留结论，也能少消耗一截，这些是省 token 的手感，跟窗口给到多大关系不大。
长窗口真正帮上忙的，是那种需要一口气看完全貌的活。整理一份跨十几个模块的改动、把几百行报错和上下文一起交出去、让模型在多个文件之间来回对照，这些场景窗口窄一点就频繁断片，可多数日常任务根本用不满这么宽，硬把窗口撑大，只是把成本往上涨。窗口一宽还带出一道选择题，以前资料不够用，做法是切成块、靠检索按需取回，现在窗口大到能一口吞下整个代码库或几百页文件，不少团队开始把东西直接塞进去，省事是真的，成本模型却变了，检索只取回一小块，长窗口是把材料反复加载，用量一上去未必便宜。
对开发者来说，窗口数字好不好看其实无所谓，真正决定体验的是等待次数、需求复述次数，还有余额会不会在没察觉时清零，这背后要盯的是 token 怎么定价、缓存命中怎么计、几个模型之间怎么切。天天跟智能体打交道的人，把多家模型的调用收进一个统一入口、按真实用量结账，省下的是来回比价和翻账单的功夫，窗口会一轮轮往上加，计价方式却不会跟着变简单。
