1. 为什么长任务总在关键时刻掉上下文如果你用 Codex 处理过跨十几个文件的重构大概率遇到过这种情况前面刚让它读完整个模块的接口定义聊到第三轮它就开始失忆把最早贴进去的代码摘要成一句话。这不是模型不行而是默认上下文窗口在自动压缩历史。Codex 默认的上下文预算偏保守日常写个函数、改个 bug 完全够用。但一旦进入长文档分析、跨文件重构、超长工具输出这类场景token 消耗速度会远超预期。触发自动压缩后早期内容被摘要化模型对项目结构的理解就开始漂移表现为改着改着忘了原来的约束。1M 上下文窗口要解决的就是这个问题。它把 Codex 的上下文预算从默认值拉到 100 万 token让项目代码、命令行输出、对话历史在自动总结之前能保留更久。适合谁适合手里有大型仓库、需要连续多轮推理、或者经常让 Codex 读完整份技术文档再动手的开发者。如果你只是偶尔改改脚本默认配置其实更省资源。这篇教程聚焦落地怎么在config.toml里手动配置model_context_window怎么用一键脚本快速完成以及配置完怎么验证 1M 上下文真的生效了。全程可复制跟着做就行。2. 前置准备模型能力与 TaoToken 接入开启 1M 上下文有个硬前提你用的模型本身得支持这么大的窗口。如果模型只支持 128K你把model_context_window强行写成 1000000请求可能不会按预期执行甚至直接报错。所以第一步是确认模型文档里记录的上下文上限。本文以支持大上下文的模型为例演示配置骨架。实际数值请以你所用模型的官方说明为准不要盲目照搬 1000000 这个数字。接入侧我用的是 TaoToken 的 API 服务它兼容常见的 OpenAI 风格调用方式配置起来比较直接。你需要先拿到 API Key再把它填进 Codex 的配置里。获取入口在这里API Key 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后Codex 的接入文档可以参考接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你还没决定用哪个模型可以先在模型对话页面里试一下长文本表现确认它确实能吃下大段内容再动手改配置模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite这一步别跳过。我见过有人配置改完发现不生效排查半天最后发现是模型本身不支持白折腾。3. 手动配置 config.toml 的完整骨架Codex 的配置文件默认在用户目录下的~/.codex/config.toml。Windows 上对应C:\Users\你的用户名\.codex\config.toml。如果文件不存在手动创建一个即可。打开文件后关键是把下面这几行放在顶级位置也就是出现在任何[section]标题之前。这一点非常重要写进某个 section 内部是不会生效的。# ~/.codex/config.toml # 以下三项必须位于所有 [section] 之前 model gpt-5.6-sol model_context_window 1000000 model_auto_compact_token_limit 900000 # 接入 TaoToken 的 API 配置 [model_providers.taotoken] base_url https://taotoken.net/api api_key 你的_API_Key三个核心字段的含义对照如下配置项作用建议值model指定使用的模型按你实际可用的模型填model_context_window告诉 Codex 上下文预算1000000模型需支持model_auto_compact_token_limit触发自动历史压缩的阈值900000为什么压缩阈值设 900000 而不是直接顶到 1000000因为自动压缩本身也需要消耗 token 和时间。如果等到上下文已经逼近上限才触发压缩过程可能来不及完成或者把关键内容一起压掉。留出大约 10 万 token 的缓冲能让压缩在相对从容的状态下进行减少信息丢失。保存文件后必须重启 Codex 客户端并开启一个新会话旧会话仍然按之前的参数运行不会自动继承新配置。4. 单次 CLI 会话临时试用如果你不想动默认配置只想在单次命令行会话里临时验证 1M 上下文可以直接在启动命令里覆盖参数。这种方式不写入config.toml适合先做验证。codex -m gpt-5.6-sol \ -c model_context_window1000000 \ -c model_auto_compact_token_limit900000-c参数用于覆盖单个配置项优先级高于配置文件。实测下来这种临时覆盖的方式在排查配置到底有没有生效时特别有用先用命令行跑一次确认模型能正常响应大上下文再决定要不要写进配置文件长期使用。如果你用的是 TaoToken 的接入点记得在环境变量或配置里把 base_url 指向https://taotoken.net/api否则请求会打到默认地址上。5. 一键脚本与验证动作手动改配置对熟悉 TOML 的人不算事但字段位置、缩进、section 顺序都容易出错。一键脚本的价值在于把配置写入和基础校验一起做掉。脚本执行前建议先确认来源可信并了解它会修改哪些文件。下面是通用的一键配置思路你可以把它保存成setup-codex.sh后执行#!/usr/bin/env bash set -euo pipefail CONFIG_DIR$HOME/.codex CONFIG_FILE$CONFIG_DIR/config.toml mkdir -p $CONFIG_DIR # 备份原配置 if [ -f $CONFIG_FILE ]; then cp $CONFIG_FILE $CONFIG_FILE.bak.$(date %s) echo 已备份原配置 fi # 写入顶级配置项若已存在则替换 grep -q ^model_context_window $CONFIG_FILE 2/dev/null \ sed -i.bak s/^model_context_window.*/model_context_window 1000000/ $CONFIG_FILE \ || echo model_context_window 1000000 $CONFIG_FILE grep -q ^model_auto_compact_token_limit $CONFIG_FILE 2/dev/null \ sed -i.bak s/^model_auto_compact_token_limit.*/model_auto_compact_token_limit 900000/ $CONFIG_FILE \ || echo model_auto_compact_token_limit 900000 $CONFIG_FILE echo 配置写入完成当前内容 cat $CONFIG_FILE执行后脚本会打印最终配置内容你可以肉眼确认三个字段都在顶级位置。验证是否生效最直接的办法是启动一个新会话然后让它处理一段明显超过默认窗口的长文本观察是否还会在早期就触发历史压缩。更严谨的验证方式是查看 Codex 的会话日志或调试输出确认它读取到的model_context_window是 1000000。如果日志里显示的还是默认值说明配置没被正确加载回到第 6 节排查。6. 配置不生效的常见排查配置写了但没反应九成是位置问题。model_context_window必须写在所有[section]之前。如果你把它塞进了[model_providers.xxx]里面Codex 读不到。用grep -n ^\[ config.toml看一下第一个 section 在第几行确保三个字段都在它上面。改了配置但会话还是老样子Codex 不会热加载配置。改完必须重启客户端并且开新会话。旧会话的上下文参数在创建时就固定了继续用旧会话等于没改。模型不支持导致请求异常把model_context_window设成 1000000但模型实际只支持 128K请求可能被拒绝或返回错误。这时候先把数值调回模型文档标注的上限确认能正常跑通再考虑换支持大窗口的模型。成本突然变高1M 上下文意味着每次请求携带的 token 量大幅上升费用自然水涨船高。默认值本身就是针对性能和成本调优过的如果你的日常任务用不到这么大窗口保持默认反而更划算。别为了拉满而拉满。API 地址配错如果你用 TaoToken 接入确认base_url是https://taotoken.net/apiKey 填的是在控制台生成的那一串。地址或 Key 错了表现往往是请求直接失败而不是上下文不生效两者要区分开。控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite排查顺序建议先确认字段位置再确认重启和新会话最后确认模型能力和 API 配置。按这个顺序走基本能定位到问题。7. 长期编码场景的接入建议如果你只是偶尔处理超长文档单次 CLI 覆盖参数就够了。但如果你长期做跨文件重构、Agent 式连续编码建议把配置固化下来并且用 Coding Plan 这类面向持续编码的接入方式省去每次手动配的麻烦。Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite配置固化后记得定期检查模型文档有没有更新上下文上限。模型能力在变今天设的 1000000 可能过段时间就有更合适的值。另外把config.toml纳入你的 dotfiles 管理换机器时直接同步比每次重新配省事得多。最后提醒一句1M 上下文是特殊需求不是默认最优解。先想清楚你的任务是不是真的需要它再动手改配置。用对了场景它能让长任务顺畅很多用错了场景只是白白多花钱。