暂无菜单项

GPT-6.1 Sol默认上下文升至500K:免附加费不等于免费,Codex长任务终于少压缩

发布于 更新于
105

导读:GPT-6.1 Sol在Codex与ChatGPT Work里的默认上下文,从272K直接提高到500K。对大型代码任务来说,真正的收益不是数字更大,而是少触发几次压缩、少丢一点早期约束、少等几轮恢复。但“完全免费”并不准确:订阅不收长上下文附加费,任务照样扣额度;API超过272K输入,还会进入更高费率。

先把三个数字分清:500K是Codex与Work的新默认值;1,050,000是GPT-6.1 Sol官方模型上下文上限;272K仍是API标准费率与长上下文费率的分界线。

OpenAI产品负责人公布Codex与Work默认500K上下文
OpenAI产品负责人公布Codex与Work默认500K上下文。

01 / 从272K到500K,默认窗口一次增加约80%

OpenAI产品负责人公布,GPT-6.1 Sol在Codex与ChatGPT Work中的默认上下文已提高到500K Token。用户仍可覆盖默认设置,向上调整到模型支持的105万Token,也可以为了速度与额度主动调低。

OpenAI给出的理由很直接:更大的窗口能减少上下文压缩,并让需要长时间工作的任务保留更多背景和细微差异。对于“查文件、改代码、跑测试、继续修复”的Agent循环,这比普通聊天更有意义。

订阅额度使用GPT-6.1 Sol不收长上下文附加费
订阅额度使用GPT-6.1 Sol不收长上下文附加费。

准确表述:从订阅额度扣除GPT-6.1 Sol用量时,不额外收取长上下文费用;但任务本身仍会消耗订阅额度。这不是“所有使用完全免费”,更不代表API免费。

开发者对默认上下文调整的讨论
开发者对默认上下文调整的讨论。

02 / 为什么程序员在意的不是500K,而是“少压缩几次”

Codex执行一个真实开发任务时,上下文里会不断累积代码片段、终端输出、错误日志、测试结果、用户追加要求和已经做过的判断。窗口快满时,系统需要压缩早期信息,腾出空间继续工作。

开发者反馈Codex上下文压缩等待时间较长
开发者反馈Codex上下文压缩等待时间较长。
Codex状态页显示约522K上下文窗口
Codex状态页显示约522K上下文窗口。

压缩不是简单删除,而是把庞杂轨迹整理成更紧凑的任务状态。问题在于它需要时间,也可能损失细节。例如最初要求“新接口必须兼容旧版”,在几十轮工具调用后,如果压缩摘要没有保住这条约束,新功能可能通过测试,旧接口却被意外破坏。

大型代码任务中的上下文积累与压缩流程
大型代码任务中的上下文积累与压缩流程。

500K不会消灭压缩,但会推迟触发时间。对于一次读取几百个文件、执行大量测试的仓库级任务,少一次压缩往往意味着少一次等待,也减少重新解释需求和恢复工作状态的概率。

03 / 免附加费,为什么额度仍可能掉得更快?

因为长上下文的成本不只来自“第一次塞进去”。你只发送一句“继续”,Agent为了接着工作,仍可能需要重新读取前面的文件、要求和测试结果。缓存让重复内容的处理价格更低,却不等于读取次数不计入用量。

此前上下文扩容后出现额度消耗高于预期,团队曾回退默认值
此前上下文扩容后出现额度消耗高于预期,团队曾回退默认值。

因此,更大的默认窗口可能同时带来两种结果:

  • 体验更顺:压缩次数减少,长任务连续性更好。
  • 用量更高:每轮可能携带和读取更多历史内容,缓存读取累计增加。

免掉附加费,不等于同一个任务一定更省额度。真正需要观察的是完成任务的总轮数、缓存命中、压缩次数、重试量和最终返工成本。

04 / API用户要特别注意:超过272K仍会涨价

项目 标准费率 超过272K输入
输入 2美元/百万Token 整次请求按2倍输入费率
缓存输入 0.10美元/百万Token 整次请求按2倍缓存费率
缓存写入 2.50美元/百万Token 按官方长上下文规则计费
输出 10美元/百万Token 整次请求按1.5倍输出费率

模型官方规格是105万上下文、12.8万最大输出。500K是产品默认配置,并没有改变API的105万上限,也没有取消API长上下文价格。Fast、Ultrafast、Batch、Flex和区域处理还会使用不同倍率,生产环境应以当日官方价格页为准。

05 / 500K还是1M?别把窗口开满当成优化

GPT-6.1 Sol默认500K更新示意图
GPT-6.1 Sol默认500K更新示意图。

默认500K的意义,是给大多数Codex与Work用户一个连续性、速度和额度之间的平衡点。只有任务确实需要跨越大量文件、长日志或多阶段决策时,才值得手动向1M靠近。

场景 建议
小型修复、单文件修改 不必追求1M,保持默认或更低即可
中型仓库、多轮测试 500K更适合作为起点,观察压缩和额度
跨模块迁移、超长日志、复杂研究 可测试1M,但必须设置阶段总结和成本上限
API批量任务 优先检索与裁剪,避免无差别越过272K价格线

06 / 与Claude Opus 5.5相比,别只盯着窗口数字

原文整理的长上下文对比示意,实际规格与价格应以双方官方页面为准
原文整理的长上下文对比示意,实际规格与价格应以双方官方页面为准。

Claude Opus 5.5官方规格同样提供1M上下文,输入与输出标准价格为每百万Token 4美元和20美元;GPT-6.1 Sol API为2美元和10美元,但超过272K输入后会采用更高费率。两者的订阅限制、压缩策略、工具链和API价格不是同一口径,不能仅凭“500K对1M”判断谁更划算。

更实用的比较方式,是让两款模型在同一仓库完成同一任务,记录成功率、压缩次数、总Token、墙钟时间、测试通过率和人工Review返工量。

07 / Codex长任务省额度的7个办法

  1. 先写验收标准:把兼容性、测试、不能改动的目录和最终交付写在任务开头。
  2. 使用仓库规则文件:让持续要求不依赖长对话记忆。
  3. 把检索交给子Agent:子任务独立搜索,主Agent只接收结论和关键文件。
  4. 主动做阶段总结:完成一个模块后记录决策、修改文件、未解决问题和下一步。
  5. 限制日志噪声:保留失败测试和关键堆栈,不把几万行重复输出长期留在主上下文。
  6. 按模块分任务:需要时拆成多个线程,使用明确的交接摘要,而不是让单个上下文无限膨胀。
  7. 观察用量而非窗口:窗口是容量,最终成本取决于被读取多少次、缓存是否命中以及任务是否返工。

08 / 做视频网观点:500K不是模型升级,却是很实在的产品升级

开发者质疑“改一个配置算不算升级”并非没有道理:GPT-6.1 Sol的模型能力没有因为默认值变化突然增强。但对Codex这类Agent产品,默认配置决定了绝大多数用户真正能用到多少能力。

更大的默认窗口能减少等待和信息损失,属于典型的体验升级。它的代价是用量管理变得更重要。最成熟的做法不是一味追求1M,而是让上下文只保留目标、关键事实、决策、必要代码和可验证结果。

站内入口与延伸阅读

官方资料

0 点赞
0 收藏
分享
0 讨论
反馈
热门资讯
相关素材

暂无数据