同一个 GPT-5.6 Sol，有人打开 Codex 看到 1.05M，有人只有 353K，还有人只剩 258K。到底谁的数据是真的？需要修改配置才能开启百万上下文吗？本文把模型窗口、Codex 工作窗口、自动压缩和第三方 API 配置一次讲清楚。

最近使用 Codex 时，我发现一个很容易让人误解的问题。

OpenAI 的 GPT-5.6 Sol 模型页面明确标注了 1,050,000 Token 上下文窗口，但不少用户在 Codex 的 /status 里看到的却是 353K，甚至只有 258K。

更奇怪的是，有用户在同一台电脑、同一个账号上测试：

• 交互式启动 Codex，显示约 1.05M；

• 使用 codex exec 执行任务，却只显示约 258K；

• 换成 API Key 或自定义服务后，数字又可能发生变化。

于是网上出现了两种完全相反的说法：

GPT-5.6 Sol 根本没有百万上下文。

以及：

只要在配置文件里加两行，就能强制解锁 1M。

实际上，这两种说法都不够准确。

一、先说结论：1.05M是真的，但不等于Codex一定给你1.05M

根据 OpenAI 官方模型文档，GPT-5.6 Sol 的规格是：

项目	官方规格
模型 ID	gpt-5.6-sol
上下文窗口	1,050,000 Tokens
最大输出	128,000 Tokens
输入价格	5 美元/百万 Tokens
缓存输入价格	0.5 美元/百万 Tokens
输出价格	30 美元/百万 Tokens

这里的 1.05M 是模型 API 层面的最大上下文容量。

Codex 则是运行在模型上方的产品。它还要考虑系统提示词、工具定义、终端输出、补丁记录、推理结果和预留输出空间，因此实际交给一次会话的工作窗口可能更小。

换句话说：

模型最多能装多少，和Codex当前愿意给一次任务装多少，不是同一个概念。

二、1.05M、372K、353K、272K和258K分别是什么

这些数字看起来很乱，其实分别来自不同层级。

1. 1.05M：模型原生上下文

这是 GPT-5.6 Sol 在 API 文档中公布的总上下文窗口。

它代表模型理论上能在一次请求中共同处理的输入、历史内容、工具信息、推理内容和输出预算，并不代表你可以无成本地一次塞入 105 万个 Token 的代码。

2. 372K：Codex曾下发的模型目录窗口

部分版本和账号曾拿到 372000 的 Codex 模型目录配置。

Codex 还会预留一部分空间，所以用户最终看到的有效窗口大约为：

372000 × 95% = 353400

这就是很多人截图中的 353K。

3. 272K：部分Codex会话当前使用的目录窗口

后续又有用户发现，服务端下发的窗口变成了 272000。

按照同样的 95% 有效比例计算：

272000 × 95% = 258400

所以你在 /status 里看到的 258K，并不一定是显示错误，而可能是当前账号、入口或会话获得的有效工作窗口。

4. 128K：最大输出，不是输入窗口

128K 指单次响应允许生成的最大输出，不要把它和模型总上下文混在一起。

三、为什么同一个模型，每个人显示得不一样

目前比较常见的影响因素有四个。

1. 登录方式不同

使用 ChatGPT 账号登录 Codex，通常会读取 OpenAI 为该产品和账号下发的模型目录。

使用 API Key 或自定义 Provider，则更多依赖本地配置和上游接口真实支持的限制。

2. Codex版本不同

Codex CLI、桌面端以及 IDE 扩展的更新节奏不同。旧版本缓存的模型目录，也可能与新建会话拿到的数据不一致。

先执行下面的命令确认版本：

codex --version

3. 启动入口不同

目前已经有用户复现：交互式 Codex 会话显示约 1.05M，而 codex exec 创建的会话约为 258K。

因此，讨论上下文时不能只说“Codex支持多少”，还要说明使用的是 CLI 交互模式、桌面端、IDE，还是 codex exec。

4. 自动压缩阈值不同

Codex 不会等到窗口完全塞满才处理历史记录。达到一定阈值后，它会把前面的对话和执行过程压缩成摘要，为后续任务腾出空间。

压缩能让任务继续运行，但摘要不可能保留所有细节。长时间重构时，早期约束、失败方案和跨文件关系可能因此丢失。

四、先别急着改配置，用 /status 看真实结果

建议先启动一个全新会话：

codex -m gpt-5.6-sol

进入后执行：

/status

重点记录：

• 当前模型是不是 gpt-5.6-sol；

• 上下文窗口显示多少；

• 使用的是 ChatGPT 登录还是 API Key；

• 新会话与旧会话是否一致；

• 交互模式和 codex exec 是否一致。

不要仅凭模型选择器里写着“GPT-5.6 Sol”，就默认当前会话一定获得了完整 1.05M。

五、走兼容API时，两个配置项分别控制什么

Codex 官方配置中有两个相关参数：

model_context_window = 1050000
model_auto_compact_token_limit = 900000

它们分别表示：

• model_context_window：Codex认为当前模型可使用的上下文窗口；

• model_auto_compact_token_limit：达到多少Token后自动压缩历史记录。

需要特别注意：

这两个参数是客户端的窗口管理配置，不是给上游模型“扩容”的开关。

如果上游线路实际只支持 258K、400K，强行填写 1.05M 只会让 Codex 更晚压缩，最终可能收到 context length exceeded、400 或请求被截断等错误。

六、一套可直接使用的Codex兼容API配置

用户级配置文件位置：

macOS / Linux：~/.codex/config.toml
Windows：C:\Users\你的用户名\.codex\config.toml

注意不要把 Provider 配置写进项目里的 .codex/config.toml。Codex 官方文档说明，项目级配置不能覆盖 openai_base_url、model_provider 和 model_providers 等本机 Provider 设置。

下面采用自定义 Provider，切换和排查会更清晰：

model = "gpt-5.6-sol"
model_provider = "genvis"
model_reasoning_effort = "high"

# 只有确认上游支持长上下文后再开启
model_context_window = 1050000
model_auto_compact_token_limit = 900000

[model_providers.genvis]
name = "OpenAI Compatible"
base_url = "https://genvis.xyz/v1"
wire_api = "responses"
env_key = "GENVIS_API_KEY"

然后设置环境变量。

macOS / Linux：

export GENVIS_API_KEY="sk-你的API-Key"

Windows PowerShell：

$env:GENVIS_API_KEY="sk-你的API-Key"

重新启动 Codex，再用 /status 检查模型和窗口。

我这里把测试用的兼容接口直接保留在配置中，避免读者还要自己猜字段。示例接口目前提供新用户 2 元测试额度，比较适合先验证登录、模型调用、读取项目和一次短任务。2 元并不适合做百万 Token 压力测试，长上下文测试前仍要检查余额、实际计价和上游窗口。

七、如果你更在意费用，不要盲目追求1M

GPT-5.6 Sol 有一个很容易忽略的计费规则：

当输入超过 272K Tokens，整个请求按 2 倍输入价格和 1.5 倍输出价格计费。

注意，不是“超出的部分”涨价，而是整个请求进入长上下文价格区间。

如果你的日常任务只是修复 Bug、编写一个模块或者补充测试，其实没必要一直保留 1M 窗口。可以采用更保守的配置：

model_context_window = 272000
model_auto_compact_token_limit = 240000

240000 是为了给工具输出、系统信息和最终回答留出余量，并不是 OpenAI 官方指定值，也不能保证每次请求一定低于 272K。

真正需要长上下文的场景通常包括：

• 大型仓库的跨模块分析；

• 长时间运行的架构重构；

• 同时读取大量规范、日志和代码；

• 多轮工具调用且必须保留早期决策；

• 需要追踪大量文件之间的依赖关系。

普通代码补全和单文件修改，相关上下文的质量通常比单纯扩大窗口更重要。

八、配置后仍然只有258K，应该怎么排查

按照下面的顺序检查，效率最高。

1. 确认修改的是用户级配置

Provider 和 Base URL 应写在用户目录下的 ~/.codex/config.toml，而不是项目目录里的配置文件。

2. 新建会话

旧会话可能已经保存了创建时的模型信息。修改配置后应退出 Codex，并创建一个全新会话再测试。

3. 检查模型名

确认请求使用的是：

gpt-5.6-sol

不要把 gpt-5.6、平台自定义别名和 gpt-5.6-sol 默认视为完全相同的路由。

4. 检查上游真实窗口

有些平台展示的是模型官方规格，实际线路可能来自不同推理提供方，窗口限制并不相同。

应该以真实请求、错误信息、计费日志和平台说明为准，不能只看模型列表上的“1M”标签。

5. 不建议长期修改模型缓存

网上有教程要求修改 models_cache.json，甚至用定时脚本防止它被覆盖。

这种方式只能改变客户端读到的模型信息，不能改变上游能力，而且 Codex 更新后可能再次刷新缓存。除非你明确知道当前版本的目录加载逻辑，否则不建议作为长期方案。

九、最后总结

GPT-5.6 Sol 的 1.05M 上下文是真的，但它描述的是 API 模型的最大容量，不代表所有 Codex入口、账号和线路默认都提供完整窗口。

你看到的几个数字可以这样理解：

• 1.05M：模型 API 的原生上下文窗口；

• 372K：部分 Codex 版本曾使用的目录窗口；

• 353.4K：372K 扣除 5% 预留后的有效窗口；

• 272K：部分会话当前使用的目录窗口；

• 258.4K：272K 扣除 5% 预留后的有效窗口；

• 128K：最大输出，不是总输入窗口。

model_context_window 和 model_auto_compact_token_limit 确实是 Codex 官方支持的配置项，但它们只能控制客户端如何理解和管理上下文，不能突破服务端的真实限制。

最稳妥的做法不是看到“1M”就直接把参数拉满，而是：

1. 用 /status 确认当前会话；

2. 区分交互模式和 codex exec；

3. 用短任务验证模型、Base URL 和 Responses API；

4. 确认上游支持后，再逐步提高窗口；

5. 同时留意 272K 以上的长上下文计费变化。

对于绝大多数开发任务，稳定、透明并且可验证的上下文，往往比配置文件里一个漂亮的“1M”更重要。

---

参考资料

• OpenAI：GPT-5.6 Sol Model

• OpenAI：Codex Configuration Reference

• OpenAI Codex Issue #31860、#32806、#33306、#33478

说明：Codex模型目录和产品策略仍可能更新。本文记录的是截至2026年8月18日可查到的官方规格、公开问题与配置方式，具体结果以当前客户端和实际接口为准。