Codex 做一个大型项目做到一半，突然开始忘记前面改过的文件；你刚刚解释过的架构，它又重新问一遍；终端里还多了一句：上下文已经被压缩。
这时候很多人会想到一个问题：
如果把 Codex 的上下文窗口从 272K 改成 372K，是不是就能让它记住更多代码？
答案没有那么简单。
本文针对 Codex CLI 0.146.0 做一次实验，尝试把 GPT-5.6-Sol 的本地模型元数据调整到 372000，并解释这项配置到底改变了什么、没有改变什么，以及如何验证它是否真的有用。
先给结论：
这不是模型升级，也不是让服务端凭空获得更大的上下文能力。它修改的是 Codex 客户端读取到的模型元数据和上下文预算。是否真正可用，最终要看服务端能不能接受这么大的请求。
一、当前 Codex CLI 的默认值
先确认本机版本：
codex --version
本文实测版本：
codex-cli 0.146.0
再查看当前模型目录：
codex debug models
GPT-5.6-Sol 的默认元数据类似这样：
{
"slug": "gpt-5.6-sol",
"context_window": 272000,
"max_context_window": 272000,
"effective_context_window_percent": 95,
"multi_agent_version": "v2"
}
因此默认有效窗口大约是：
272000 × 95% = 258400
这里的 95% 并不是模型的原始限制，而是 Codex 为系统提示词、工具调用和模型输出预留空间后，认为可以用于输入的比例。
二、372000 和 353400 分别是什么？
实验配置将本地模型目录中的窗口改成：
{
"context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95
}
于是得到：
372000 × 95% = 353400
这几个字段需要分开理解：
| 字段 | 示例值 | 含义 |
|---|---|---|
context_window | 372000 | 模型元数据中的原始窗口 |
max_context_window | 372000 | 客户端允许配置到的最大窗口 |
effective_context_window_percent | 95 | 预留系统、工具和输出空间后的比例 |
| 有效窗口 | 353400 | 372000 × 95% |
需要注意：
353400 是 Codex 客户端计算出来的有效窗口，不等于服务端模型一定支持 353400 tokens。
三、它到底能解决什么问题？
如果任务经常接近上下文上限，这项配置可能带来一些帮助：
- 长时间运行的 Codex 任务可以保留更多历史信息；
- 大型代码仓库分析时，可以一次读取更多文件；
- 长日志排查时，较晚触发上下文压缩；
- 多轮重构任务中，模型不必过早重新建立项目背景。
但它不会改变：
- GPT 模型本身的推理能力；
- 模型的代码能力；
- 服务端真实上下文上限；
- 不同任务之间的永久记忆；
- 模型理解超长内容时的注意力分配。
更准确的表述是：
它可能扩大 Codex 的“上下文预算”，但不会扩大模型的“理解能力”。
如果你的普通任务只使用几万 tokens，那么修改后基本感觉不到差别。
四、为什么要同时修改 max_context_window？
Codex 客户端通常会把运行时配置和模型元数据的最大值进行比较：
最终窗口 = min(配置值, max_context_window)
如果只在 config.toml 中写：
model_context_window = 372000
但模型目录仍然是：
"max_context_window": 272000
那么 372000 可能会被客户端限制回 272000。
因此实验需要同时调整模型目录中的两个窗口字段。
五、开始前的注意事项
这是一项实验性配置，建议先确认：
- 使用的是 Codex CLI 0.146.0 或相近版本；
- 已经备份
config.toml； - 已经备份模型目录文件；
- 知道自己使用的是官方服务还是兼容模型网关；
- 不要在生产任务中直接测试；
- 不要把 API Key、Cookie、Token 或私有代码发到截图和评论区。
如果服务端真实上限低于 372000，本地配置不会改变服务端限制，可能出现：
context length exceeded；- 请求被服务端拒绝；
- 部分上下文被截断；
- 任务运行时间变长；
- 配额消耗增加；
- Codex 在长任务中途失败。
六、备份 Codex 配置
Windows PowerShell 示例：
$codexHome = if ($env:CODEX_HOME) {
$env:CODEX_HOME
} else {
Join-Path $HOME ".codex"
}
if (-not (Test-Path -LiteralPath $codexHome)) {
throw "找不到 Codex 配置目录：$codexHome"
}
$backupDir = Join-Path `
$codexHome `
("backups\context-window-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
New-Item -ItemType Directory -Path $backupDir -Force | Out-Null
foreach ($name in @("config.toml", "custom_models.json")) {
$source = Join-Path $codexHome $name
if (Test-Path -LiteralPath $source) {
Copy-Item `
-LiteralPath $source `
-Destination (Join-Path $backupDir $name) `
-ErrorAction Stop
}
}
Write-Host "备份完成：$backupDir"
如果当前还没有 custom_models.json，不要直接创建一个只有几行字段的不完整 JSON 文件。后面应该从当前模型目录生成完整文件。
七、生成自定义模型目录
当前模型目录是一个完整 JSON 对象，结构类似：
{
"models": [
{
"slug": "gpt-5.6-sol"
}
]
}
可以先读取当前目录，再只修改 Sol 对象：
$codexHome = if ($env:CODEX_HOME) {
$env:CODEX_HOME
} else {
Join-Path $HOME ".codex"
}
$catalogPath = Join-Path $codexHome "custom_models.json"
$catalog = codex debug models | ConvertFrom-Json
$solModels = @(
$catalog.models |
Where-Object { $_.slug -eq "gpt-5.6-sol" }
)
if ($solModels.Count -ne 1) {
throw "没有找到唯一的 gpt-5.6-sol 模型对象"
}
$sol = $solModels[0]
$sol.context_window = 372000
$sol.max_context_window = 372000
$sol.effective_context_window_percent = 95
$json = $catalog | ConvertTo-Json -Depth 50
$utf8NoBom = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList $false
[System.IO.File]::WriteAllText($catalogPath, $json, $utf8NoBom)
Write-Host "已生成：$catalogPath"
保存后检查文件是否存在：
Test-Path "$HOME\.codex\custom_models.json"
结果应为：
True
八、修改 config.toml
打开：
~/.codex/config.toml
在顶层加入或调整：
model = "gpt-5.6-sol"
model_context_window = 372000
model_catalog_json = "~/.codex/custom_models.json"
model_context_window 必须位于顶层，不要放进不确定的配置段中。
model_catalog_json 必须指向真实存在的完整模型目录文件。如果文件路径错误，Codex 可能无法正常启动。
这类字段属于比较底层、版本敏感的配置。当前 Codex CLI 0.146.0 可以读取自定义模型目录，但未来版本可能改变字段名称或加载方式。
九、验证本地模型目录
重新打开终端，执行：
codex debug models
也可以只查看 Sol：
$catalog = codex debug models | ConvertFrom-Json
$catalog.models |
Where-Object { $_.slug -eq "gpt-5.6-sol" } |
Select-Object `
slug,
context_window,
max_context_window,
effective_context_window_percent
如果自定义目录加载成功，应看到类似：
slug context_window max_context_window effective_context_window_percent
---- -------------- ------------------- --------------------------------
gpt-5.6-sol 372000 372000 95
这只能证明：
Codex 客户端读取了新的本地模型元数据。
它还不能证明服务端真的支持 353400 tokens。
十、验证真实长任务
新建一个 Codex 任务，不要继续使用旧任务。
旧任务可能已经在启动时加载了旧模型元数据。
在新任务中观察：
task_started.model_context_window
token_count.info.model_context_window
如果显示：
353400
说明 Codex 运行时采用了新的有效窗口。
但真正的服务端验证，还要观察：
- 长任务是否正常完成；
- 第一次上下文压缩发生在哪一轮；
- 是否出现
context length exceeded； - 是否发生内容截断；
- 任务耗时是否明显增加；
- 输出质量是否下降；
- 是否消耗更多配额。
建议使用同一个代码仓库、同一个任务和同一个模型，分别测试默认配置与实验配置。
| 指标 | 默认配置 | 实验配置 |
|---|---|---|
| 原始上下文窗口 | 272000 | 372000 |
| 有效窗口 | 258400 | 353400 |
| 第一次压缩轮次 | 待记录 | 待记录 |
| 最大 token 使用量 | 待记录 | 待记录 |
| 任务耗时 | 待记录 | 待记录 |
| 是否报错 | 待记录 | 待记录 |
十一、95% 不一定是自动压缩阈值
还需要区分“有效窗口”和“自动压缩阈值”。
有效窗口：372000 × 95% = 353400
但自动压缩可能在达到有效硬上限之前触发。在某些版本中，如果没有单独设置 auto_compact_token_limit，自动压缩阈值可能按原始窗口的比例推导，例如：
372000 × 90% = 334800
所以：
353400 是客户端计算出的有效窗口，不代表 Codex 一定会等到 353400 才开始压缩。
具体行为需要结合当前版本的任务日志验证。
十二、如何回滚
关闭 Codex 后，恢复备份文件：
Copy-Item `
-LiteralPath "$HOME\.codex\backups\你的备份目录\config.toml" `
-Destination "$HOME\.codex\config.toml" `
-Force
如果备份了 custom_models.json，也一并恢复。
或者删除实验配置：
model_context_window = 372000
model_catalog_json = "~/.codex/custom_models.json"
然后重启 Codex，再执行：
codex debug models
确认模型目录恢复到默认值：
context_window: 272000
max_context_window: 272000
十三、常见问题
修改后仍然显示 272000，怎么办？
依次检查：
custom_models.json是否存在；- JSON 是否能正常解析；
model_catalog_json路径是否正确；- 是否修改了
gpt-5.6-sol对象； - 是否完全退出并重启 Codex；
- 当前任务是否实际使用了 Sol；
- 是否被远程模型目录覆盖。
为什么配置成 372000 后仍然自动压缩？
可能原因包括：
- 自动压缩阈值早于有效硬上限；
- 当前任务还包含大量系统提示词和工具输出；
- 模型目录没有真正加载；
- 服务端使用了更低的上下文限制；
- 当前版本的压缩策略由其他字段控制。
为什么出现 context length exceeded？
这通常表示客户端认为可以发送这么多内容，但服务端真实上限更低。
此时应该回滚配置，而不是继续提高数值。
这会让 Codex 变得更聪明吗？
不会。
它不会改变模型参数、推理能力或代码质量，最多让 Codex 在一次长任务中保留更多上下文。
会不会增加消耗？
可能会。更大的上下文通常意味着更高的输入 token 消耗、更长的请求时间、更大的网络传输量和更高的失败风险。
十四、最终结论
这项配置有一定价值，但需要正确理解。
它不是：
- 模型升级；
- 无限上下文；
- 永久记忆；
- 智力增强；
- 服务端限制突破。
它更接近：
修改 Codex CLI 本地模型元数据，尝试让客户端使用更大的上下文预算。
对于大型代码仓库、长时间运行的 Agent 任务、频繁触发上下文压缩的用户，这种调整可能有帮助。
但对于普通短任务，基本没有明显收益。
在 Codex CLI 0.146.0 中：
默认：272000 × 95% = 258400
实验：372000 × 95% = 353400
最终是否真正有效，必须通过长任务和服务端错误日志验证，而不能只看本地配置文件里的数字。