文章 / 大厂观察

Writing

大厂观察|默认上下文涨八成,OpenAI 免长文本附加费

2026-10-12大厂观察OpenAICodex

目录 展开 / 收起
  1. 事实:默认值动了多少,费用免了哪一块
  2. 背景:一次退回,和一条没说出口的成本曲线
  3. 影响:容量翻倍,不等于长任务变便宜或变可靠
  4. 观察点
  5. 来源与说明

OpenAI 把自家编码智能体的默认工作区放大了接近一倍。北京时间 10 月 12 日上午,OpenAI 的 Thibault Sottiaux(Tibo)在 X 上宣布,GPT-6.1 Sol 在 Codex 与 Work 里的默认上下文窗口从 272k token 提到 500k token,涨幅约 80%,多出来的 228k 不需要用户改任何设置。几分钟后他补了一句同样要紧的话:这个模型从订阅额度里扣用量时,不再收长上下文附加费。两次表态都不是发布会环节,官方帮助中心与更新日志当天没有对应条目,本稿事实节以当事人原帖与多家媒体转述互证为准。

事实:默认值动了多少,费用免了哪一块

这次改的是默认值,不是上限。按 Tibo 的说法,GPT-6.1 Sol 的上下文上限仍是 1M,用户可以手动调高调低,平台只是把出厂设置从 272k 挪到了 500k;OpenAI 开发者文档的模型页给得更细——上下文窗口 1,050,000 token,其中输出上限 128,000,知识截止 2026 年 4 月 30 日。调整理由是经过测试后认为这个数值对多数用户处在体验与性能的折中位置,往后还会继续提高,但后续上调没有给出日期。

给这个动作定的目标也很具体:减少上下文压缩的触发次数。Codex 这类智能体在长时间工作时,读到的代码、报错、工具结果都会占用上下文,快装满时系统会把前面的对话与工作进度压成较短的记录,腾出空间再继续。Tibo 的说法是,扩容之后需要长期保留大量上下文与复杂细节的任务能跑得更从容。这个说法有开发者的实测作对照:有人在这次调整前几天自己把窗口手动调到 500k 并贴出状态截图,理由是压缩一次最长要干等两分钟。

费用这块要分两条线读。订阅侧,GPT-6.1 Sol 从订阅额度里扣用量时不收长上下文附加费,任务照常消耗额度。API 侧没有变化:文档写明标准档每百万输入 token 2 美元、输出 10 美元,输入 token 超过 272K 的请求按 2 倍输入与缓存费率、1.5 倍输出对整条请求计费;缓存输入按非缓存输入价的 5% 计,缓存写入按 1.25 倍计。

数字这次调整里的几组数字
500k
GPT-6.1 Sol 在 Codex 与 Work 的新默认上下文,原值 272k
228k
用户不改任何设置就能多拿到的空间,官方概括为约 80% 的涨幅
1,050,000
开发者文档给出的上下文窗口上限,其中输出上限 128,000
272K
API 侧长上下文费率的分界线,超过后整条请求按 2 倍输入、1.5 倍输出计费
2 / 10 美元
标准档每百万输入与输出 token 的 API 价格

社区的反应分成两派。有人反问“改个默认值也算一次升级”,也有人认这笔账——默认值才是大多数人实际跑的数字,上限只是参数表上的一行。

背景:一次退回,和一条没说出口的成本曲线

这不是 OpenAI 第一次动这个数。今年 7 月,OpenAI 曾把产品里的上下文从 272k 提到 372k 供 GPT-5.6 Sol 使用,结果订阅用量扣得比预期多,团队又退回了 272k。开发者 Theo 当时的猜测是上下文超过 272k 之后按两倍收费;Tibo 后来纠正说,订阅侧当时也没有加收长上下文费,多扣的用量来自反复读取缓存内容——你只敲一句“继续”,智能体要接着改代码,仍得把前面读过的文件、测试结果和约束条件再带一遍,缓存读取比重新处理便宜,但每次读取照样计入用量,读得多、读得勤就累积起来了。

这段旧事是理解这次“免附加费”的钥匙。免掉的是附加费这一项,额度怎么扣并没有变,所以容量涨了不等于同一个任务更省额度。

脉络这条线上的几个时间点
2026-07
372k 试验
产品内上下文提到 372k,因订阅用量扣得超预期又退回 272k
2026-09-29
GPT-6.1 Sol 发布
在 DevDay 登场,面向复杂编码、重度计算机使用与专业工作
2026-10-12
默认 500k
Codex 与 Work 出厂值从 272k 提到 500k,订阅扣用量免长上下文附加费
待公布
继续上调
官方称默认窗口还会往上走,未给出新日期

对手那一侧的口径也要摆进来。Claude Code 里 1M 上下文已是若干模型的默认配置,会话自动压缩点约在 967k token;Anthropic 的 API 文档写明 1M 以内按标准单价计费,超过 200K 不加价。也就是说,OpenAI 这次的新默认值仍只有对手默认配置的一半,而两边的收费口径并不在同一条线上——一个在 272K 之后对整条请求加价,一个在 1M 之内不额外加价。

影响:容量翻倍,不等于长任务变便宜或变可靠

三笔账要分开算。订阅用户的账是压缩次数变少、附加费取消,但额度消耗未必下降,7 月那次退回已经演示过一次。API 用户的账几乎没动:272K 的溢价线原地不动,而且是对整条请求计费,一次 300K 输入的请求,前后 300K 全部按双倍算,做批量处理的团队感受最直接。第三笔账最难算——窗口变大本身,到底换来了什么。

学术与工程侧给出的答案都偏保守。Nelson F. Liu 等人在 2023 年的实测里发现,相关信息放在长上下文的开头或结尾时模型表现更好,放在中部时性能显著下降,长上下文的可用性并不随长度线性增长。社区把窗口塞满之后模型开始遗忘、重复、混淆的现象称为 context rot。LangWatch 针对编码智能体的测算更贴近这次的场景:随窗口增大,累积成本大致按 C 的 2.5 次方增长,而真正被用到的活跃上下文稳定在 6k—8.5k token;它给出的低成本区间是 220k—240k,建议运行区间 250k—450k,并测到压缩之后 5 步内的操作员修正率从基线 17.7% 升到 41.9%。这组数字能解释为什么 OpenAI 选的是 500k 而不是直接给 1M:默认值落在“够用且还能承受”的位置,往上加的边际收益要打问号。

对照
这次改了的
这次没动的
默认上下文 272k 提到 500k
手动上限仍是 1M(文档口径 1,050,000,输出上限 128,000)
订阅扣用量免长上下文附加费
API 侧 272K 以上对整条请求加价的规则没变
官方称可减少压缩触发
压缩本身的等待耗时与摘要丢信息,没有新的解法
多数用户拿到更大空间
窗口塞满后的信息衰减(中部衰减、context rot)没有变化

工程侧还有一件小事值得当天就做。如果你之前手动改过 model_context_window 或 model_auto_compact_token_limit(Codex 用户配置通常落在用户目录的 .codex/config.toml),这次默认值改了,你的旧值不会自动跟着变;文档写明自动压缩阈值未设置时才采用模型默认。命令行参数、可信项目配置与启用的 profile 都可能覆盖用户配置,用 /status 看状态、/debug-config 看实际加载的配置层,能确认当前生效的到底是哪一个。

把格局摊开看,默认上下文正在变成产品对比项,而不只是参数表上的规格。Anthropic 一侧 1M 已是默认,OpenAI 这次给到 500k、手动可到 1M,两边都不缺上限,差的是出厂设置和怎么收钱。

观察点

看默认值会不会在高峰时段悄悄回落。今年 7 月有过 372k 上去又退回 272k 的先例,退回理由是订阅用量扣得超预期;这次免了附加费却没改额度扣法,如果同样的用量压力重现,回退的可能仍然存在。

看 API 的 272K 溢价线是否跟着下移。目前订阅侧免附加费、API 侧按旧规则走,两条线口径不一致。若后续把溢价线抬到 500K 对齐,说明这次是产品口径与计费口径统一的第一步;若长期不动,那么“免附加费”就只覆盖订阅用户,API 侧的长任务成本逻辑没有变。

看压缩相关的可验证指标。LangWatch 测到压缩之后 5 步内的操作员修正率从 17.7% 升到 41.9%,这是一个能被复现的口径。如果 500k 之后压缩触发次数明显下降、修正率同步回落,说明扩容确实解决了问题;如果压缩照旧频繁触发,那么瓶颈在上下文里装什么,而不在装多少。

来源与说明

[1] Thibault Sottiaux 宣布 GPT-6.1 Sol 默认上下文提升至 500k(原帖,含 272k 基准、1M 上限与不收长上下文附加费的表述)|X(Thibault Sottiaux,OpenAI)|2026-10-11 [2] OpenAI 宣布 GPT-6.1 Sol 默认上下文长度从 272k 提升至 500k(含“约 80%“涨幅、1M 上限、折中点表述与免附加费说明)|IT之家|2026-10-12 [3] GPT-6.1 Sol 一夜扩容 500k(含 7 月 372k 回退经过、Tibo 对缓存读取的纠正、Claude Code 1M 与 967k 压缩点对照、开发者评论)|新智元|2026-10-12 [4] GPT-6.1 Sol Defaults to 500k Context in Codex and Work(英文汇总,含默认值与上限的区别、订阅免附加费范围、后续三项看点)|MOOGH|2026-10-12 [5] OpenAI raises GPT-6.1 Sol default context length to 500,000 tokens(含 1,050,000 窗口、922k 输入与 128k 输出拆分、标准档 2/10 美元定价)|Web Pulse|2026-10-12 [6] GPT-6.1 Sol 模型页(上下文窗口 1,050,000、输出上限 128,000、知识截止 2026-04-30、定价与 272K 长上下文费率、缓存计价)|OpenAI 开发者文档|2026-10-12 [7] Codex 配置参考(model_context_window 与 model_auto_compact_token_limit 的含义、配置层优先级与 /status、/debug-config 用法)|OpenAI 开发者文档|2026-10-12 [8] API 定价页(按 token 计费口径与档位说明)|OpenAI 开发者文档|2026-10-12 [9] Prompt caching 指南(前缀精确匹配、缓存断点与缓存输入的计费方式)|OpenAI 开发者文档|2026-10-12 [10] Claude Code 模型配置(1M 窗口的适用范围与约 967K 的自动压缩点)|Anthropic 文档|2026-10-12 [11] 上下文窗口(窗口构成、自动压缩与上下文管理建议)|Anthropic 文档|2026-10-12 [12] Lost in the Middle: How Language Models Use Long Contexts(相关信息位于上下文中部时性能显著下降的实测)|arXiv(Nelson F. Liu 等)|2023-07-06 [13] Finding the Optimal Context Window for Coding Agents(累积成本随窗口的增长、活跃上下文规模、低成本与建议运行区间、压缩后修正率)|LangWatch|2026-10-12(检索日,原文未标注发布日) [14] Claude Code 成本页(缓存与压缩时机的官方建议)|Anthropic 文档|2026-10-12

说明:检索截止 2026-10-12 20:00(Asia/Shanghai)。272k→500k 的默认值调整、约 80% 涨幅、1M 手动上限、订阅扣用量不收长上下文附加费,均出自 Thibault Sottiaux 本人的公开表态,经 IT之家、新智元、MOOGH 与 Web Pulse 转述互证;截至检索截止时,OpenAI 帮助中心与更新日志未见对应条目,本文按“当事人表态 + 媒体转述”口径引用。1,050,000 上下文窗口、128,000 输出上限、知识截止日、2/10 美元标准档定价与 272K 以上的整请求加价规则、缓存输入的 5% 与缓存写入的 1.25 倍,出自 OpenAI 开发者文档模型页与定价页。今年 7 月 372k 上调后回退、Theo 的猜测与 Tibo 关于缓存读取的纠正、开发者手动调到 500k 并吐槽压缩等待,出自新智元对 X 帖与社区讨论的汇总,属转述口径。Claude Code 的 1M 默认窗口与约 967K 自动压缩点、1M 以内不加价的收费口径,出自 Anthropic 官方文档。上下文中部信息衰减出自 arXiv 2307.03172;成本增长、活跃上下文规模、区间建议与压缩后修正率出自 LangWatch 的测算,属第三方研究,未见厂商复现。同一模型此前的定价动作另见本站 10 月 1 日《OpenAI 把旗舰级智能降到五分之一价》(openai-gpt61-sol-price-cut)。本期未采用涉及政府与公共部门主体、跨境监管、安全手法与国别对比框架的若干候选线索,取舍见同日 scan-report。

← 全部文章