上下文 258K 够不够用？Codex 开 1M 之前该想清楚的事
编程 agent 默认只给 258K 上下文，而对比的模型标称 1M，差距从何而来？本文拆解「模型上限」与「工具默认值」的区别，说明分段计费的阈值风险，给出调整配置的具体做法，并整理了压缩、会话交接、拆分任务等更省 token 的实践，以及各场景下的取舍建议。
最近有开发者提出疑问：新一代 GPT 系模型在编程工具里的默认上下文只有 258K，而对比的 Claude 系模型标称 1M，差了将近四倍，是不是被"阉割"了？讨论很快分成两派——一派认为 258K 根本不够用，必须手动开到 1M；另一派认为默认值就是最优解，开大了既贵又蠢。
这场争论其实把两个不同的问题混在了一起：模型本身支持多长的上下文，以及工具默认给你开多少。把这两件事分开看，大部分疑惑就解开了。
258K 是默认值，不是模型上限
多数编程 agent 的默认上下文长度是刻意设小的，模型本身往往支持得更长。原因不复杂：
- 计费与额度通常分段。讨论中反复出现一个数字——272K 左右。超过这个阈值，API 侧的单价或订阅侧的额度消耗可能翻倍。默认卡在阈值之前，是为了避免一次长会话把整月额度烧光。
- 订阅与 API 的权限不同。同一模型，订阅套餐和按量计费能拿到的上限、计费口径都可能不一样。
- 规则变化很快。哪些套餐解锁 1M、超额是否双倍计费、企业版与个人版是否一致，各家各版本差异很大，务必以官方最新文档和账单页面为准，不要只信截图、第三方中转面板或二手转述。
所以"只有 258K"更准确的说法是：默认配置只给你 258K，超出部分要不要花钱、花多少，得你自己判断。
为什么会觉得不够用
在考虑调大之前，先看看上下文是被什么吃掉的。常见的有四类：
- 一次性投喂：把整个仓库、几十个文件、整份日志直接塞进首轮对话。
- 单会话死磕：一个会话从需求讨论做到上线，中间经历几十轮修改，历史全量累积。
- 重复上下文：每一轮都重新贴一遍同样的报错、同样的代码片段。
- 让模型"记住"本可以检索的东西：把文档当记忆塞进 prompt，而不是让它按需查找。
这四种情况里，真正需要"更大窗口"的只有第一种的一部分，其余都能靠习惯改善。
大上下文不等于更聪明
这是讨论里最有价值的一点，也是两派分歧的核心。
多位长期使用者反馈：上下文超过 200K 之后，模型开始"跑偏"，注意力被稀释，简单任务也会答得离谱。这不是精确结论，但方向上有共识——窗口越大，单位信息的权重越低。
另一边的代价是钱。上下文翻倍，输入 token 也跟着涨，一个长会话下来账单可能远超预期。
所以调大窗口的边际收益往往没有想象中高：额外塞进去的内容大多是不相关的噪声，而真正需要的信息本来可以通过检索精确拿到。
确实需要长上下文时怎么改
如果手头就是一次性分析大日志、跨几十个文件做重构这类任务，临时调大是合理的。以 Codex 为例，配置文件里通常有控制上下文长度和自动压缩阈值的字段：
# ~/.codex/config.toml
model_context_window = 1000000
model_auto_compact_token_limit = 200000
字段名会随版本演进变化，改之前先做三件事：
- 备份原配置，改动出问题时能立刻还原。
- 确认字段是否真的生效，很多工具支持在会话里查看当前状态；不生效就去翻对应版本的官方文档。
- 只改一项，观察一次用量。先跑一个小任务，看看额度消耗是否出现跳变，再决定要不要长期保留。
检查清单：
- 我的套餐是否允许这个上限？
- 超过阈值后的计费口径是什么？
- 改完之后实际生效的上下文是多少？
- 这次任务真的需要这么大吗，还是拆成几次更划算？
需要提醒的是：不要为了省钱去买共享账号，也不要用来路不明的第三方中转。账号安全和数据泄露的风险，远大于省下的那点额度，而且面板显示的数字未必可信。
比调大窗口更划算的四个习惯
讨论里另一派给出的方案，实操价值更高：
1. 会话交接，而不是无限续命
一轮搞不定时，不要硬撑。让模型先输出一份交接摘要——目标、已完成的改动、当前卡点、相关文件路径——写进项目里的一个 Markdown 文件。开新会话时先读这份文件，上下文干净，信息也不丢。
2. 把稳定背景写进项目文件
项目约定、目录结构、常用命令、代码规范这类每轮都要用的内容，放进 AGENTS.md、CLAUDE.md 之类的说明文件，让 agent 自己去读，而不是每次手动粘贴。
3. 主动压缩，并接受有损
压缩会丢细节，但保留推理能力；上下文过载则是能力整体下降。两害相权，前者可控——丢掉的信息还可以回头从对话记录或代码里找回。很多工具的自动压缩做得已经相当无感，长会话跑下来偏移并不明显。
4. 减少轮数，一次想清楚
与其来回试探十轮，不如第一轮就把约束、验收标准、边界条件写全。轮数少了，累积的上下文自然就少，也不容易越跑越偏。
不同场景怎么选
| 场景 | 建议 |
|---|---|
| 单文件修改、问答、小脚本 | 用默认值，完全够用 |
| 跨文件重构 | 默认值 + 先出一份计划文件，按文件分批改 |
| 一次性分析大量日志或文档 | 临时调大，用完改回 |
| 长时间挂机跑 agent | 重点在网络和机器稳定性，而不是窗口大小 |
最后一行值得多说一句。有些人觉得上下文不够用，实际是会话被本地机器休眠、网络抖动、断线重连打断，不得不重开，于是一遍遍重建上下文。这种情况下，把 agent 跑在一台长期在线的远程机器上是个可选思路——比如整台托管在新加坡机房的独享 Mac mini，按月租用、远程连接使用，网络环境稳定，适合 Claude Code 这类需要长时间在线的工具。本地设备条件够用就没必要折腾。
小结
- 258K 是工具的默认值，不是模型的能力上限，改不改取决于任务。
- 默认值卡在分段计费阈值之前，是成本与体验之间的折中，盲目开到 1M 很可能"又贵又蠢"。
- 大多数"上下文不够"的问题，靠会话交接、项目说明文件、主动压缩和减少轮数就能解决。
- 真要改配置，先备份、再验证字段是否生效、最后看一次真实账单。
- 各套餐的上下文上限与超额计费规则变化频繁，请以官方最新说明为准；社区经验可以参考，但不要当成计费依据。
