AIGC标识 Codex 1M Token 上下文：谁真正需要、1M 到底有多大，以及如何开启

本文由 AI 辅助整理，并经人工审核。产品能力、模型范围和计费规则截至 2026 年 8 月 26 日，后续可能随 Codex 更新而变化。

摘要

Codex 的 1M 上下文窗口并不是一个应该默认开启的“性能增强开关”。

它主要适合以下工作负载：

  • 单个任务的有效工作集超过约 200K～300K tokens；
  • 模型必须跨大量代码、文档、日志或历史对话进行多跳推理；
  • 任务持续数小时，且上下文压缩后会丢失重要约束；
  • 单次任务价值足以覆盖更高的额度消耗和潜在延迟。

对于局部代码修改、普通写作、单文档摘要、简单问答以及可以通过搜索或数据库精确筛选的信息，默认上下文通常已经足够。

一句话总结：

1M 上下文是复杂任务的工作空间，不是长期记忆、知识库或普遍提升模型智力的开关。

一、Codex 从什么时候开始支持 1M 上下文

2026 年 3 月 5 日：GPT-5.4 首次提供实验性支持

OpenAI 发布 GPT-5.4 时，首次宣布 Codex 实验性支持 1M 上下文，并允许通过以下配置项启用：

  • model_context_window
  • model_auto_compact_token_limit

超过标准 272K 上下文窗口的 Codex 请求，会更快消耗使用额度。

参考：Introducing GPT-5.4

2026 年 7 月 9 日：GPT-5.6 进入 Codex

GPT-5.6 系列在 Codex、ChatGPT 和 API 中正式发布。

GPT-5.6 Sol 的模型规格包括：

  • 1,050,000 tokens 上下文窗口；
  • 128,000 tokens 最大输出；
  • 超过 272K 输入的 API 请求，整次请求按更高费率计算。

参考：

2026 年 7 月 18 日：默认窗口设为 272K

Codex CLI 0.144.6 更新了 GPT-5.6 Sol、Terra 和 Luna 的内置模型元数据，将默认上下文窗口校正为 272,000 tokens。

这意味着模型本身拥有更大的上下文能力，但 Codex 默认采用较小窗口，以平衡性能、稳定性和额度消耗。

参考：Codex CLI 0.144.6 更新记录

2026 年 8 月 17 日：ChatGPT 账号支持 GPT-5.6 Sol 1M 配置

OpenAI 员工公开说明，GPT-5.6 Sol 的 1M 上下文配置已从主要面向 API Key 的使用方式，扩展至通过 ChatGPT 账号登录的 Codex。

截至 2026 年 8 月 26 日，这项能力尚未作为独立开关出现在 Codex 设置界面中，主要通过 config.toml 启用。

参考：1 Million Context to enable professional workloads

二、如何开启

打开用户级 Codex 配置文件：

~/.codex/config.toml

Windows 对应路径通常为：

%USERPROFILE%\.codex\config.toml

在所有 [section] 标题之前加入：

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

配置含义：

  • model：选择 GPT-5.6 Sol；
  • model_context_window：将上下文预算设为 1,000,000 tokens；
  • model_auto_compact_token_limit：在约 900,000 tokens 时开始压缩历史，给输出和系统内容留出空间。

保存后应：

  1. 完全重启 Codex CLI、桌面应用或 IDE 扩展；
  2. 创建一个新会话；
  3. 在 Codex CLI 中运行 /status；
  4. 发送第一条消息后再次运行 /status，确认实际窗口没有回落到默认值。

也可以只为一次 CLI 会话启用：

codex -m gpt-5.6-sol -c model_context_window=1000000 -c model_auto_compact_token_limit=900000

Codex 官方配置参考已经收录这两个配置项：

Codex Configuration Reference

三、支持哪些模型、客户端和账号

模型支持范围

模型 上下文规格 Codex 1M 配置状态
GPT-5.6 Sol 1.05M 已明确确认
GPT-5.6 Terra 1.05M API 规格 Codex 公开开启说明未明确确认
GPT-5.6 Luna 1.05M API 规格 Codex 公开开启说明未明确确认
GPT-5.4 1M 曾提供实验性支持
GPT-5.4 mini 400K 不支持 1M
GPT-5.3 Codex、GPT-5.2 Codex 低于 1M 不适用

虽然 Terra 和 Luna 的 API 模型规格也达到 1.05M，但目前公开的 Codex 开启说明明确点名的是 GPT-5.6 Sol。因此，在 Codex 中不宜直接把 Terra 和 Luna 视为已经得到同等确认。

客户端范围

本地用户级 config.toml 主要适用于：

  • Codex CLI；
  • ChatGPT/Codex 桌面应用；
  • VS Code 等 Codex IDE 扩展。

目前没有公开资料给出一个严格的最低客户端版本号。2026 年 8 月 17 日的关键变化主要发生在服务端账号权限，因此建议升级至可用的最新客户端版本。

Codex Web 或 Cloud 是否接受本机 config.toml 没有得到公开确认。

ChatGPT 套餐范围

GPT-5.6 Sol 在 Codex 中面向：

  • Plus；
  • Pro；
  • Business；
  • Enterprise。

Free 和 Go 用户主要使用 GPT-5.6 Terra，因此无法直接套用已经明确确认的 Sol 1M 配置。

Enterprise 工作区还可能受到管理员模型策略、额度和数据治理规则限制。

四、1M tokens 究竟有多大

下面是便于理解的粗略量级。实际结果会受到语言、文件格式、代码密度、图片和工具输出影响。

内容类型 1M tokens 粗略对应
英文文本 约 50万～75万词
普通文档 约 1,000～1,500 页
中文材料 数十万至约百万汉字，受分词方式影响较大
源代码 约数万至二十万行，取决于语言和注释密度
会议逐字稿 数百小时以内，取决于语速和转写格式
React 代码库 OpenAI 的类比是超过 8 份完整 React 代码库

配置为 1M 并不意味着可以放入完整的 1M 用户数据。

上下文空间还需要容纳：

  • 系统指令；
  • AGENTS.md 等项目规则；
  • 工具和技能定义；
  • 历史对话；
  • 文件内容；
  • 命令输出和日志；
  • 模型输出所需余量。

因此，在 900K 自动压缩的配置下，真正能够放入的业务数据通常明显低于 900K。

五、判断是否需要 1M：看任务工作集，不看数据总量

假设一家企业拥有 10TB 文档，但一次任务只需要查找其中 20 页，那么更合适的方案是：

  • 搜索；
  • 数据库查询；
  • 文件索引；
  • RAG；
  • 先过滤再分析。

这种任务没有必要把大量资料全部放进上下文。

相反，一个代码仓库可能只有几百 MB，但一次系统迁移需要同时理解：

  • 数十个模块；
  • 多个服务；
  • 接口和数据结构；
  • 测试；
  • 部署配置；
  • 运行日志；
  • 历史架构决策；
  • 当前任务的验收条件。

此时，有效工作集可能快速超过默认的 272K，1M 就可能产生明显价值。

最核心的判断问题是：

为了完成一个具体任务，模型是否必须同时保留超过 272K tokens 的相关信息，并持续跨这些信息进行推理？

只有答案为“是”时，1M 才具有明确价值。

六、哪些人群和行业最有价值

1M 上下文的价值主要取决于任务结构，而不是行业名称。需要跨大量材料持续推理、任务周期较长、上下文压缩会丢失关键信息的人群，收益通常最高。

行业组合 值得开启的场景 通常无需开启
软件、SRE、安全与工程 大型重构、跨服务迁移、事故调查、安全审计，以及联合分析代码、配置、日志和测试 局部 Bug、单文件修改、普通 CRUD、原始日志或传感器数据处理
法律、金融、医疗与公共政策 合同尽调、审计核验、长期病历、监管申报，以及跨法规、证据和历史记录分析 单份材料摘要、简单查询、批量计算或无需多材料关联的任务
科研与教育 跨论文、实验记录、研究代码、课程资料和长期学生作品进行综合分析 单篇论文总结、单次备课、简单知识问答
咨询、产品、运营与客服 整合数据室、访谈、需求、指标、工单和历史决策，形成跨部门结论 单个需求、普通工单、短期活动复盘或单份报告
销售、市场与招聘 战略客户全过程分析、大型 RFP、多渠道品牌活动、复杂岗位或组织材料整合 普通邮件、单次客户研究、单篇文案、简历初筛
媒体、出版与内容创作 长篇小说、系列剧本、调查报道，以及人物、时间线和多版本一致性维护 新闻短稿、社交媒体内容、单篇校对

跨行业最值得开启的四类任务

无论属于哪个行业，以下任务通常最可能从 1M 上下文中获益：

  1. 跨系统整合：任务涉及大量相互依赖的模块、部门、合同或数据源。
  2. 长时间执行：单个任务持续数小时，积累大量工具调用、修改记录和反馈。
  3. 多跳推理：结论必须同时关联多个文件或证据位置，无法通过一次检索完成。
  4. 压缩敏感：早期约束、例外条件、失败路径或关键证据不能被概括丢失。

医疗、法律、金融、招聘等高风险场景即使适合使用长上下文，也仍需落实最小权限、数据脱敏和专业人员复核。

七、最值得开启的四类使用者

大型系统的整合者

工作跨越大量模块、服务、合同、数据源或业务部门，局部理解不足以完成任务。

长时间代理任务的使用者

单个 Codex 任务持续数小时，过程中包含大量：

  • 搜索；
  • 命令；
  • 测试；
  • 文件修改；
  • 错误日志；
  • 用户反馈；
  • 决策调整。

OpenAI 曾披露内部存在持续六小时以上的单次 Codex 任务，同时也强调应给代理提供“地图”，而不是巨型说明书。

参考：Harness engineering

对上下文压缩损失敏感的人

任务早期出现的以下内容不能被简单概括：

  • 例外条件；
  • 验收标准；
  • 合规要求；
  • 关键证据；
  • 已经失败的方法；
  • 用户明确否决的方案。

需要跨材料多跳推理的人

任务不能通过找到一段文字完成，而是需要关联多个位置，例如：

  • 追踪跨服务调用链；
  • 识别合同之间的冲突；
  • 重建设备故障时间线；
  • 比较多轮实验结果；
  • 关联政策、执行记录与实际影响。

OpenAI 的长上下文研究也指出，多项真实任务需要在不同文件或文档之间进行多次逻辑跳转。

参考：Introducing GPT-4.1

八、哪些情况下没有必要开启

以下情况通常应继续使用默认窗口：

  • 对话通常低于 100K～150K tokens；
  • 一次只修改少数文件；
  • 工作主要是写作、翻译、摘要或普通问答；
  • 信息可以通过搜索、SQL、脚本或 RAG 精确筛选；
  • 任务可以自然拆成多个独立阶段；
  • 可以通过结构化交接文档连接不同阶段；
  • 问题来自提示不清，而不是上下文不足；
  • 环境、依赖或验收条件尚未提供完整；
  • 工作负载追求低延迟、高吞吐或固定成本；
  • 输入包含大量重复日志、生成文件和无关历史；
  • 只是担心未来可能用到，实际从未接近默认窗口上限。

OpenAI 在内部 Codex 实践中提到，巨大的指令文件会挤占真正有价值的任务和代码上下文。当所有内容都被描述为重要时，模型反而更难判断重点。

参考：How OpenAI uses Codex

九、1M 上下文不能替代什么

不能替代搜索和 RAG

长上下文适合处理已经筛选出的相关工作集。

如果面对数百万份文件，应先检索，再把最相关的材料交给模型。

不能替代数据库

结构化查询、聚合、排序、去重和计算应由数据库完成。

模型适合解释结果和发现关系。

不能替代外部状态

长期项目的事实、决策和进度应记录到文件、数据库或任务系统中。

对话上下文属于临时工作记忆。

不能替代任务拆分

如果任务能够自然分成研究、设计、实现、测试和审查等阶段，分阶段执行通常比持续扩大上下文更稳定。

不能保证准确性

1M 代表模型可以接收更多信息，不代表它一定会正确使用所有信息。

材料越多，相似条目、冲突版本和无关内容也越多。即使先进模型能够在超长上下文中检索信息，复杂的多目标辨别仍然具有挑战。

十、成本、速度与质量风险

使用额度增长

更长的上下文意味着后续每轮请求可能携带更多历史信息。

对于 GPT-5.6 Sol API：

  • 输入超过 272K tokens 后；
  • 整次请求的输入价格为标准费率的 2 倍；
  • 整次请求的输出价格为标准费率的 1.5 倍。

Codex 套餐并不一定采用完全相同的账单呈现方式，但大型代码库、长任务和长会话会明显加快使用额度消耗。

延迟增加

模型需要处理更多输入，首个响应和完整任务时间可能增长。

噪声增加

无关文件、重复日志和历史错误结论可能干扰模型判断。

错误传播

如果上下文中存在旧版本、错误假设或互相冲突的规则，模型可能在较长任务中持续引用它们。

隐私与治理

把更多数据放入同一会话会扩大单次任务的数据暴露范围。

企业应继续实施：

  • 最小权限；
  • 数据分类；
  • 敏感信息脱敏；
  • 工作区访问控制；
  • 审计；
  • 专业人员复核。

十一、一个实用的量级判断

以下是工程经验阈值，并非 OpenAI 官方硬标准：

活动上下文 建议
低于 100K 保持默认配置
100K～200K 优化提示、文件范围和工具输出
200K～300K 观察是否频繁压缩，以及压缩后是否出现信息丢失
300K～600K 复杂跨材料任务开始具有明确收益
600K～900K 适合少数大型、长时间、强关联任务
长期超过 900K 应考虑分阶段、索引、RAG 或外部状态管理

如果任务长期超过 900K，继续扩大窗口往往无法解决根本问题。

此时真正缺少的可能是：

  • 信息架构；
  • 检索策略；
  • 数据过滤；
  • 任务拆分；
  • 状态管理；
  • 决策记录；
  • 可验证的验收标准。

十二、是否应该开启：五项检查

以下五项满足三项以上，可以考虑试用 1M：

  • 经常接近或超过 250K tokens；
  • 压缩后出现可复现的信息丢失；
  • 任务必须跨几十个相关文件或文档；
  • 任务很难安全拆成独立阶段；
  • 单次任务价值足以覆盖额外额度和等待时间。

如果只满足一项，通常应先优化上下文管理。

十三、推荐的验证方法

不建议仅凭感觉永久开启。

可以选择 10 个具有代表性的复杂任务进行对照测试：

  1. 使用默认 272K 窗口执行；
  2. 使用 1M 配置执行；
  3. 记录首次完成率；
  4. 记录人工纠正次数；
  5. 记录遗漏约束数量；
  6. 记录自动压缩次数；
  7. 记录完成时间；
  8. 记录使用额度；
  9. 比较最终交付质量；
  10. 判断节省的人工时间是否高于额外成本。

只有在成功率和人工时间方面出现稳定提升时，才值得长期保留 1M 配置。

十四、最终结论

1M 上下文真正解决的是：

在一个大型、长时间、强关联任务中，让模型更久地保留相关代码、文档、日志、约束和决策。

它最适合：

  • 大型系统整合；
  • 跨材料多跳推理；
  • 长时间代理任务；
  • 对压缩损失敏感的高价值工作。

它不适合：

  • 简单问答；
  • 局部修改；
  • 高吞吐任务；
  • 无差别装载海量资料；
  • 用上下文代替数据库、搜索、RAG 或长期记忆。

对于多数日常任务，经过筛选且结构清晰的 100K 上下文，通常比混杂且缺少重点的 800K 上下文更有效。

因此，比较合理的策略是：

默认保持 272K，在已经证明受到上下文压缩限制的高价值任务中，再按需启用 1M。

posted @ 2026-08-26 23:18  LexLuc  阅读(3)  评论(0)    收藏  举报