Codex CLI 接入 Qwen 3.8 Max：6 行配置、258K 上下文封顶的解法、实测成本

Codex CLI 能用 Qwen 3.8 Max 吗？

能，走网关，而且完整的 agent 循环跑得通。 Codex 里没有它的内置条目，所以你要声明一个自定义 provider，指向一个会说 Responses API 的端点。整套配置一眼看完：

你能做到的：       在 Qwen 3.8 Max 上跑完整 Codex agent 循环（apply_patch、shell、多轮）
需要的时间：       6 行 TOML，约 5 分钟
需要准备的：       codex-cli 0.146.x、一个 ofox API key，不需要 ChatGPT 订阅
模型 slug：        bailian/qwen3.8-max
传输协议：         responses（2026 年 Codex 唯一接受的值）
你拿到的上下文：   默认 258,400 token，不是模型支持的 100 万
封顶的解法：       model_catalog_json，不是 model_context_window
三任务成本：       $0.0804，GPT-5.5 上是 $0.5387（实测 2026-08-06）
价目表：           $2 / $6 per 1M 输入/输出，缓存读取 $0.25

Qwen 在 2026 年 8 月 3 日发布了 3.8 Max，100 万上下文，价格大约是 GPT-5.5 的五分之一。Codex CLI 是花这笔预算最顺手的地方。连接能通，配置也短，但中间有两件事会安静地让你多花钱：Codex 实际给模型的上下文窗口，和跑完之后 CLI 打印的那个 token 数。

下面两个数都是在 codex-cli 0.146.1 上量出来的。

在 Codex 里用 Qwen 3.8 Max，能做什么、不能做什么？

你拿到的是真正的 agent 循环，不是一个聊天框。 实测里 Qwen 3.8 Max 读文件、用 Codex 的 apply_patch 工具打补丁、跑 python3 验证自己的修复、然后汇报结果。最后那件事比听起来重要。apply_patch 正是同一条路径上好几个模型翻车的地方：同一个网关下的 Claude Sonnet 5 会拒绝 Codex 的 freeform 工具形状，报 tools.0.custom.strict: Extra inputs are not permitted；DeepSeek 和 Grok 则死在 Encrypted content is not supported with this model。Qwen 3.8 Max 不会。

你拿不到的：

• 完整的 100 万上下文。 Codex 把未知模型卡在 258,400 token。能解，但不是靠大多数教程点名的那个配置项。
• Codex 自带的系统提示词。 一旦你提供自定义模型目录来解开封顶，就也得自己提供 base_instructions。OpenAI 编译进去的那份提示词对第三方 slug 不开放。
• 一个可信的账单显示。 tokens used 那行会少算掉命中缓存的部分，某次运行里那部分占了输入的 85%。
• 按 ChatGPT 套餐计费。 这是 API key 通道。你的 Codex 周限额不受影响，ChatGPT 订阅也一样。

什么时候该这么配，什么时候不该？

当你的问题是 Codex 账单、而不是模型质量的时候。 下面所有判断都假设你已经在天天用 Codex，也清楚自己花了多少。

适合的情况：

• 你在 GPT-5.5 上正在烧穿 Codex 的周上限，想给日常那三分之二的活（重构、测试脚手架、代码讲解）换个便宜模型。
• 你想用一把 key 同时够到 Qwen、GPT、Claude 系模型，不想维护三套鉴权。
• 你已经在用 Codex，不想为了用上一个中国前沿模型去换一个 CLI。

不适合的情况：

• 你需要 Codex 调好的系统提示词和 skills 行为。自定义目录条目会把它换成你自己写的那份。
• 你的活确实要超过 258K 上下文，但你不愿意维护一个 JSON 目录文件去解开它。
• 你只想比模型质量，不打算跑 agent。那直接发 API 请求更简单，整层都能跳过。

停止规则： 如果你只是想给短任务换个便宜模型，做到第 3 步就可以停。第 4 步的目录活只有在你的 session 长到会撞上封顶时才划算。

开始之前需要准备什么？

一个当前版本的 Codex、一把网关 key，OpenAI 那边什么都不需要。

有一条命名规则很容易踩。在自定义 provider 下要用带命名空间的 slug bailian/qwen3.8-max；在 OpenAI 原生鉴权下则写裸模型名如 gpt-5.5，不带前缀。这个前缀是网关的目录命名空间，不是模型身份的一部分，在一份配置里混用两种写法是拿到 model-not-found 最快的方式。

怎么在 Codex CLI 里配置 Qwen 3.8 Max？

三步：装、声明 provider、跑。 下面这份配置是在 0.146.1 上真跑通的版本，不是一个待你改造的模板。

第 1 步：安装 Codex 并设置 key

npm i -g @openai/codex
export OFOX_API_KEY="sk-of-..."
codex --version   # 期望 0.146.x

这里不要用 codex login --with-api-key。那条路会把一个 OpenAI key 写进 auth.json 给内置 provider 用，而自定义 provider 读的不是它。

第 2 步：写 provider 块

创建 ~/.codex/config.toml：

model = "bailian/qwen3.8-max"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox"
base_url = "https://api.ofox.io/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

六行 provider 配置，每一行都有它的理由：

• wire_api = "responses" 现在是唯一被接受的值。传 "chat" 是启动即报错，不是警告，报错指向 OpenAI 的弃用讨论帖。当前的配置参考文档写得很直白：responses「是唯一支持的值，省略时也是默认值」。
• env_key 指定 Codex 读哪个环境变量。这行漏掉 Codex 不会报错。它会退回到 auth.json 里那把 OpenAI key 并把它发给你的网关，结果是一个 401，看上去在怪你的 key，实际问题是发出去的是另一把。
• requires_openai_auth = false 跳过 ChatGPT 登录界面。它的含义跟老教程里说的 key 格式那套没关系。

第 3 步：跑起来

codex exec --sandbox workspace-write "median() is wrong for even-length input. Fix it in stats.py."

预期结果：Codex 读文件、调用 apply_patch、跑脚本检查自己的修改、打印总结。我们的测试仓库从一行 return xs[n // 2] 变成了正确的偶数长度分支加一个空输入保护，模型自己跑 python3 stats.py 读回 2.5 完成验证。

到这一步跑通，接入就是活的。后面讲的是 Codex 一路上报给你的那两个数。

为什么 Codex 把我的上下文窗口卡在 258,400？

因为 Codex 只知道 OpenAI 自家模型的能力，其它一律走保守默认值。 第一次运行你就会看到：

warning: Model metadata for `bailian/qwen3.8-max` not found.
Defaulting to fallback metadata; this can degrade performance and cause issues.

这条警告读起来像是无关痛痒的噪音。它不是。Codex 内置一张编译进去的模型条目表，表外的任何 slug 都退回一套固定档案。读 session 日志能看到代价：

grep -o '"model_context_window":[0-9]*' \
  ~/.codex/sessions/2026/08/06/rollout-*.jsonl | tail -1

"model_context_window":258400

Qwen 3.8 Max 在 ofox 模型页上写的是 1,131,072 token。Codex 给它 258,400，约等于你付费买到的 23%。长会话会比该有的时间点早得多开始自动压缩，而你完全看不出原因。

model_context_window 能解决吗？

不能，而且这一条值得你在信之前先测一遍。 网上针对这个问题流传的建议是在 config.toml 顶部加 model_context_window。这确实是个真实存在的键，文档里写的是「当前模型可用的上下文窗口 token 数」。在这里它没生效。

四条里有三条是大家推荐的修法。在 0.146.1 上只有第四条让数字动了。

那到底怎么解开完整上下文窗口？

把 model_catalog_json 指向一份把模型声明完整的 JSON 文件。 Codex 对这个文件校验很严，ModelInfo 结构体有 39 个字段。一个错一个错地绕过校验器之后，得到的是下面这份，能干净加载：

{"models": [{
  "slug": "bailian/qwen3.8-max",
  "display_name": "Qwen3.8 Max",
  "description": "Qwen3.8 Max via ofox",
  "context_window": 1131072,
  "max_context_window": 1131072,
  "effective_context_window_percent": 100,
  "default_reasoning_level": "medium",
  "supported_reasoning_levels": [
    {"effort": "low", "description": "low"},
    {"effort": "medium", "description": "med"},
    {"effort": "high", "description": "high"}],
  "shell_type": "shell_command",
  "visibility": "list",
  "supported_in_api": true,
  "priority": 1,
  "support_verbosity": false,
  "default_verbosity": "low",
  "truncation_policy": {"mode": "tokens", "limit": 10000},
  "apply_patch_tool_type": "freeform",
  "web_search_tool_type": "text_and_image",
  "input_modalities": ["text", "image"],
  "supports_image_detail_original": false,
  "supports_parallel_tool_calls": true,
  "tool_mode": "direct",
  "multi_agent_version": null,
  "use_responses_lite": false,
  "include_skills_usage_instructions": false,
  "auto_review_model_override": null,
  "auto_compact_token_limit": null,
  "comp_hash": "3000",
  "reasoning_summary_format": "experimental",
  "default_reasoning_summary": "none",
  "minimal_client_version": "0.0.1",
  "prefer_websockets": false,
  "supports_reasoning_summary_parameter": true,
  "supports_search_tool": false,
  "experimental_supported_tools": [],
  "additional_speed_tiers": [],
  "service_tiers": [],
  "default_service_tier": null,
  "availability_nux": null,
  "upgrade": null,
  "model_specialty": null,
  "memory_consolidation": null,
  "base_instructions": "You are Codex, a coding agent running in the Codex CLI. Use apply_patch for file edits."
}]}

存下来然后加载：

codex exec -c model_catalog_json=/path/to/catalog.json \
  --sandbox workspace-write "your task here"

警告消失，session 报出完整的 1,131,072。agent 循环照常工作：同一个 median 修复在目录生效的情况下依然走 apply_patch 跑通。

决定用这条路之前，先把最后一个字段看清楚。base_instructions 是必填且必须是字符串，也就是说你在用自己写的东西替换掉 Codex 的系统提示词。OpenAI 编译进去的那份指令有好几千词，覆盖工具使用纪律、输出格式和自主性规则。上面那行占位符在实测里足够让 agent 正常工作，但它不等价。如果你的 session 在 258K 里放得下，跳过这一整步是一个站得住的选择。

配置过程中会撞上哪些报错？

大部分是鉴权错误，而且都在怪错对象。 下面每一行都是在 0.146.1 上复现出来的，不是从别人的教程里抄的。

其中两条值得单独强调，因为它们会主动误导你。漏掉 env_key 那一条会报出一个关于你从来没打算发出去的 key 的鉴权错误。而 codex login status 根本不做网络校验，所以它会高高兴兴地报告登录正常，同时每个请求都在失败。诊断鉴权只能靠发一个真实请求；/v1/models 也不行，因为 ofox 的目录是公开的，不带 key 也返回 200。完整的排查矩阵见我们的 Codex CLI 401 unauthorized 报错。

在 Codex 里跑 Qwen 3.8 Max 实际花多少钱？

三个真实编码任务约 $0.08，同样三个任务在 GPT-5.5 上是 $0.54。 两次运行走的是同一个 CLI、同一个网关、同一个仓库、同样的 prompt，日期 2026-08-06。

价格取自当天的 ofox 模型页：Qwen 3.8 Max 输入 $2/M、输出 $6/M、缓存读取 $0.25/M；GPT-5.5 输入 $5/M、输出 $30/M、缓存读取 $0.5/M。

底层 token 数也放上来，光看总额没法核：

6.7 倍这个差距是真的吗？

一部分是。价目表能解释输入 2.5 倍、输出 5 倍；剩下的来自配置差异和任务级波动，不是因为 Qwen 是个更高效的模型。 有两件事把实测差距推到了价格差之上，引用这个数字之前都值得知道。

第一件是系统提示词。GPT-5.5 命中 Codex 的内置目录，每一轮都收到 OpenAI 的完整指令集。Qwen 3.8 Max 跑在自定义目录下，收到的是前面那份一行的 base_instructions。这个差异搭在每一轮的输入 token 上。

第二件是轮次数，由模型自己决定。在「讲解仓库」这个任务上，GPT-5.5 走了 8 次 API 往返、7 次工具调用；Qwen 是 4 次和 3 次。那一行的 11.5 倍基本上就是这么来的。而在类型标注任务上模式反过来了，Qwen 用了 6 次往返、GPT-5.5 是 5 次，Qwen 仍然更便宜——每轮固定开销的差异在这里露得最干净。

三个任务，各跑一次，一个仓库。缓存命中率会随你之前调了什么而漂移。把 6.7 倍当作这套配置在那一天的账单，把价目表本身给的 2.5 倍 / 5 倍当作你能稳稳指望的下限。想看以 benchmark 而不是账单为主的对比，见 Qwen 3.8 Max 对比 DeepSeek V4 Flash。

为什么 Codex 显示的 token 数比我的账单低？

因为 tokens used 那行减掉了命中缓存的输入。 那次 median 修复打印的是 tokens used 5,859。同一次运行的 session 日志：

{"input_tokens": 37401, "cached_input_tokens": 32512,
 "output_tokens": 970, "total_tokens": 38371}

38,371 减 32,512 等于 5,859。显示的那个数是总 token 减去缓存部分，作为边际成本的代理指标还算合理，作为你的发票的代理指标就很糟。那 32,512 个缓存 token 是按缓存读取价计费的，不是免费。真实数字从日志里捞：

grep -o '"total_token_usage":{[^}]*}' \
  ~/.codex/sessions/2026/08/06/rollout-*.jsonl | tail -1

reasoning effort 对账单影响大吗？

没有 token 数看上去那么大。 同一个任务、同一个模型，只改 model_reasoning_effort：

reasoning 输出涨了 2.5 倍。账单涨了 3.3%。在 agent 循环里主导的是对话重放，reasoning 只是薄薄一层。这跟「为了省钱把 effort 调低」的常见建议是相反的，至少对 Codex 里的 Qwen 3.8 Max 是这样。按输出质量选 effort，把预算这个理由拿掉。

要加的限定是：这个结论适用于短的 agent 型任务。一个工具调用很少、推理很长的单次请求会改变这个比例。

怎么在团队里共享这套配置？

用 profile，这样没人需要改一个共享文件来切模型。 profile 是让共享配置不退化成三个人各自私货的办法。两套栈各定义一次，每个开发者按项目自己选：

[profiles.cheap]
model = "bailian/qwen3.8-max"
model_provider = "ofox"
model_reasoning_effort = "medium"

[profiles.heavy]
model = "openai/gpt-5.5"
model_provider = "ofox"
model_reasoning_effort = "high"

codex exec --profile cheap "add tests for the parser"
codex exec --profile heavy "redesign the scheduler's backpressure"

推开之前，团队要先定三件事：

• key 留在环境变量里。 env_key 读的是变量名，所以配置文件本身不含密钥，可以进仓库。别让任何人往里面粘明文 key。
• 目录文件要有个固定位置。 如果你要解开完整上下文窗口，model_catalog_json 指的是绝对路径。把 JSON 提交进仓库、各人按相对路径引用，否则你会收到一堆「在我机器上是好的」的反馈，实际是「文件在别的路径」。
• 锁定 CLI 版本。 wire_api = "chat" 的移除让用了一年的配置一夜失效。把测试过的版本号跟配置写在一起。

共享 ~/.codex/config.toml 的布局在我们的 Codex config.toml 深度解析和多 provider 配置指南里讲得更细。

进阶：哪些模型能在这里真正替代 Qwen？

不是所有挂在 OpenAI 兼容网关后面的模型都能活过 Codex 要求的 Responses API 这条路。目录里列出 /v1/responses 是必要条件而不是充分条件，而且失败在你发出真实请求之前是无声的。下面六行都在同一个网关上于 2026-08-06 实跑过：

encrypted-content 这两条在你这端修不了。Codex 把 reasoning.encrypted_content 硬编码进了每个请求，没有开关。这就是为什么一个模型可以列出正确的端点却仍然失败。

想在花掉一整个 session 之前先筛一遍候选：

curl -s https://api.ofox.io/v1/models -H "Authorization: Bearer $OFOX_API_KEY" \
  | jq -r '.data[] | select(.supported_endpoints | index("/v1/responses")) | .id'

然后发一个真实请求。那个列表能滤掉明显不行的，滤不掉隐蔽的。各模型当前的价格和协议支持在 ofox 模型页上。

还有哪些选择值得考虑

• ofox 网关。 一把 key、两种协议，本文用的模型 slug 都在上面。Qwen 3.8 Max $2/$6，缓存读取 $0.25/M。
• 阿里云 DashScope 直连。 国际站的兼容模式 base 确实暴露了 /responses 路径；不带 key 时返回 401 而不是 404，说明端点存在。我们没有 DashScope 的 key 去跑 Codex 循环，所以这条当作未验证而不是已确认。阿里在它的 Model Studio OpenAI 兼容性文档里写了兼容模式。
• OpenRouter。 模型覆盖广，不过 Codex 的 Responses 要求同样会把可用范围收窄，跟这里一样。
• 继续用 GPT-5.5。 如果你对 Codex 调好的系统提示词和 skills 行为的需求大于对便宜 5 倍输出价的需求，那是个真实的取舍，不是一个明显错误的选择。

常见问题

只为了价格值得换到 Qwen 3.8 Max 吗？ 对日常 agent 型的活，价目表上的差距大到值得动：输入 2.5 倍、输出 5 倍。对一个错答案就要赔进一次调试的活，先评质量。定价细节和发布规格在我们的 Qwen 3.8 Max 发布拆解里。

这会影响我的 ChatGPT 或 Codex 套餐额度吗？ 不会。自定义 provider 是 API key 通道，计费独立。你的 Codex 周上限不受影响。

能在 Codex 里用 Qwen 3.8 Max 的图像输入吗？ 模型接受文本和图像输入，上面那份目录条目也把两者都声明了。Codex 循环内部的图像处理不在这次实测范围里。

258K 封顶上游会修吗？ Codex 从编译进去的目录里解析模型元数据，所以只要这个设计不变，第三方 slug 就会一直退回默认值。目录文件是今天官方给的逃生口。

References

• Codex CLI 配置参考，wire_api 与 model_catalog_json 键（核对于 2026-08-06）：https://learn.chatgpt.com/docs/config-file/config-reference
• OpenAI Codex discussion 7782，弃用 chat/completions 支持：https://github.com/openai/codex/discussions/7782
• Qwen 3.8 Max 发布博客，阿里 Qwen 团队：https://qwen.ai/blog?id=qwen3.8
• 阿里云 Model Studio OpenAI 兼容性文档：https://www.alibabacloud.com/help/en/model-studio/compatibility-of-openai-with-dashscope
• bailian/qwen3.8-max 与 openai/gpt-5.5 的 ofox 模型页价格快照（2026-08-06）
• 本地实测：codex-cli 0.146.1、macOS 26.4 arm64，session 日志在 $CODEX_HOME/sessions/2026/08/06/