Codex 的模型分层，卡人的地方往往不是「该用哪个模型」，而是~/.codex/mini.config.toml里那三行——model、model_reasoning_effort、approval_policy全写了，可这条轻量 profile 的请求究竟从哪条通道出去、用哪把 Key 鉴权，文件里一个字没提。想让 mini 和旗舰两条线各自跑到该去的地方，先把模型来源补上：打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册账号并创建一把 API Key，TaoToken 在这里提供的就是一把 Key 加一个 Base URL，其余上下文管理照旧交给 AGENTS.md 和 .codexignore。
很多人照着原文的「方法五：模型分层」配完，codex --profile mini "为 src/utils/format.ts 的所有函数补上 JSDoc 注释"这条命令照样能跑，于是以为配置没问题。直到某天默认来源换了一次、Key 轮换了一次，mini 这条线忽然开始报鉴权失败，才发现 profile 从来就没说自己走哪条来源。这篇文章就把这行补上，顺带把两档模型的任务分工说清楚。
1. 先看清 mini.config.toml 缺的是哪一行
1.1 三行配置本身没有错
原文给的这份轻量 profile 长这样：
# ~/.codex/mini.config.toml model = "gpt-5.4-mini" model_reasoning_effort = "low" approval_policy = "on-request"单看这三行，语义是完整的：选一个小模型、把推理强度调到最低、审批策略设为按需询问。补注释、写单测、修 lint 这类任务确实不需要深度推理，低强度足够了。问题在于配置只描述了「怎么用模型」，没有描述「模型从哪来」。
Codex 在加载配置时，会先读顶层的~/.codex/config.toml，再叠加--profile指定那份文件里覆盖的字段。一份 profile 里没有出现的键，就沿用顶层或内置默认值。所以mini.config.toml里没写 provider，不等于它不走 provider，而是它走了「别人替它决定的那一条」。你本地恰好只配了一条可用通道时，看不出问题；一旦顶层默认来源变了、或者那把默认 Key 失效了，mini 线就跟着一起挂。
1.2 profile 真正需要显式声明的两项
要让一条 profile 独立成立，除了模型和推理强度，还得补两项：
model_provider：指向一个在配置里声明过的 provider 名称，决定请求发给谁。- 对应的凭据来源：由 provider 段里的
env_key指向一个环境变量，运行 Codex 前把这个变量 export 好。
补齐之后，mini 这条线才真正是「自己的模型 + 自己的通道 + 自己的 Key」，跟旗舰 profile 互不干扰。这也是切换模型或供应商时最容易被跳过的一步——大家习惯改model一行，却忘了 provider 是另一维度的东西。
2. 在模型广场挑好两档模型，再创建 Key
2.1 注册并创建 API Key
动手改配置之前，先把材料备齐。打开 TaoToken 完成注册登录，进控制台创建一个 API Key。创建出来的这串字符就是后面env_key指向的环境变量值，本文统一用YOUR_API_KEY指代，实际使用时替换成你自己那把。
有一点要养成习惯：Key 不要写进配置文件本身，也不要提交到 Git。Codex 的 provider 段支持env_key这种间接引用，目的就是让配置文件可以安全地共享、同步、写进 dotfiles 仓库，而密钥留在 shell 环境里。
2.2 两档模型 ID 都从模型广场复制
下一步是把要用的模型 ID 抄下来。原文里轻量档和旗舰档是两个具体型号名，但模型广场的列表是会变的，一切以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 上的模型广场当时列表为准。你在挑的时候按能力档位选：要承担补注释、写单测、格式化的那一档，和要承担多文件重构、架构分析的那一档，各选一个，把准确的 ID 字符串复制出来，别凭记忆手打。
顺手确认一下自己的用量预期。轻任务天天跑，消耗累积起来很快，如果是长期写代码的场景，可以先去 Coding Plan 看一眼套餐形态是否够用，避免配完两天就撞额度线。
3. 改 ~/.codex/config.toml：provider 与 profile 分成两层
3.1 顶层声明 model_providers.taotoken
Codex 的配置文件放在~/.codex/config.toml，provider 段写在这里。注意这里填的是接口地址，不是官网地址，两者别混：
# ~/.codex/config.toml（顶层） model = "YOUR_FLAGSHIP_MODEL_ID" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"base_url就是https://taotoken.net/api，末尾不带/v1，也不加任何后缀。这一点重复强调不算啰嗦，它是最常见的翻车点之一：客户端内部会自己补路径，你多写一段就变成双份，请求直接打到不存在的地址上。
env_key写的是环境变量名，不是 Key 本身。名字随你起，只要和 shell 里 export 的那一个对上。
3.2 profiles.mini 和 profiles.flagship 各自显式挂 provider
接下来把两份 profile 都补完整。原先那份mini.config.toml可以直接删掉，也可以保留作为独立文件用--profile指向，但内容都要加上 provider：
# ~/.codex/config.toml 继续追加 [profiles.mini] model = "YOUR_LIGHT_MODEL_ID" model_provider = "taotoken" model_reasoning_effort = "low" approval_policy = "on-request" [profiles.flagship] model = "YOUR_FLAGSHIP_MODEL_ID" model_provider = "taotoken" model_reasoning_effort = "high" approval_policy = "on-request"两个 profile 引用的是同一个 provider 名，也就是同一把 Key、同一个 Base URL，区别只在model和model_reasoning_effort。这正好符合原文的意图：模型分层省的是用量和注意力，不是让两条线去连两个不同的账号。你要是想把两条线拆到两把 Key 上做额度隔离，也可以再声明一个 provider 段，改个env_key名即可，结构完全一样。
3.3 把 Key 放进环境变量再启动
配置存好之后，在 shell 里把 Key 注入环境。写进~/.zshrc或~/.bashrc都行：
export TAOTOKEN_API_KEY=YOUR_API_KEY改完记得source一下当前会话，或者干脆新开一个终端窗口。Key 从 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建，如果不小心把 Key 贴进了配置文件，回控制台吊销重发一把更省事，别在一个可能被同步走的文件里留下长期有效的凭据。
4. 两条任务线分别验证：补 JSDoc 与多文件重构
4.1 mini 线先跑一条低风险任务
配置改完别急着上大活儿，先拿一条边界清晰的小任务验证通道。这条命令就是原文用来演示轻量档的：
codex --profile mini "为 src/utils/format.ts 的所有函数补上 JSDoc 注释"跑之前确认三点：当前目录是不是项目根目录、TAOTOKEN_API_KEY有没有在当前终端里生效、模型 ID 是不是刚从模型广场抄下来的那串。命令正常返回，说明 provider 段被读到了、Key 通过了、模型名也对得上。看到 diff 只落在src/utils/format.ts一个文件里，那就说明这条线既走通了通道，也没越界去动别的文件。
4.2 旗舰线复用同一把 Key 验证多文件重构
紧接着验证另外一条，这条要的是全局理解能力，跟 mini 的分工完全不同：
codex --profile flagship "重构 src/lib/auth/ 目录，把 JWT 验证逻辑提取成独立模块"两条命令用的都是同一把TAOTOKEN_API_KEY，这一点是刻意的：它证明分层分的是模型，不是账号。跑完之后对照原文那份「任务与模型对应关系」的思路检查一下——补注释、修 lint 这类固定模式的活儿走轻量档，多文件重构、陌生大型项目的理解走旗舰档，单文件重构落在中间。真正要避免的是拿旗舰档去干改注释的活，模型能力富余不会让结果更好，只会让用量曲线更陡。
5. 来源换了，省上下文的那套方法一条都不用改
5.1 AGENTS.md 仍然控制读取范围
有一点必须说清楚：把模型来源指到统一通道，解决的是「请求发到哪、用哪把钥匙」，它不解决上下文浪费。Codex 该扫的文件一个都不会少扫，项目根目录没有 AGENTS.md 时那种「贪婪读取」依然会发生。
所以原文那套做法原样保留。项目根目录放一份 AGENTS.md，用两三百字写清楚关键目录、不要读的路径、技术约定，把「让 Codex 自己探索项目结构」这件事提前拦下来。模块多了就加子目录级的 AGENTS.md，越靠近文件优先级越高，这套分层机制跟模型走哪条通道没有任何关系。
5.2 .codexignore 还是最省事的一刀
.codexignore也照旧。构建产物、依赖目录、锁文件、快照文件列进去，中型项目一扫就能少掉绝大部分无关文件。这类排除跟 provider 配置是两个正交的维度：前者决定「读什么」，后者决定「发给谁」。切换供应商的时候只动 config.toml，.codexignore一个字都不用碰。
顺带提一句任务拆分。原文把它列为最直接的提升手段，这个判断在换了通道之后依然成立。一次只给一个边界清晰的任务、指定到目录或文件名、明确说明改什么不改什么，比任何模型或通道的调整都更立竿见影。
6. 切换 provider 之后容易撞上的几个报错
6.1 401：Key 没进到进程环境里
最典型的是401 Unauthorized。九成情况是env_key指向的变量在当前终端里不存在——可能是 export 写在了别的 shell 配置文件里，也可能改了.zshrc但没重开终端。先用echo $TAOTOKEN_API_KEY确认一下，输出为空就是它。另一种可能是 Key 复制时头尾带了空格或换行，删干净重新粘贴。
6.2 404 或 model_not_found：模型 ID 是手打的
接口能连上但返回找不到模型，通常是model字段里的字符串跟模型广场上的不一致。别凭原文里的示例型号照抄，直接回 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场复制当前可用的那串。ID 里带日期后缀的尤其容易抄错一位。
6.3 base_url 多带了 /v1
如果你的请求路径看起来像是被拼了两遍，检查base_url。正确写法是https://taotoken.net/api，不带/v1、不带尾斜杠。客户端自己会补后面那段路径，你多写就重复了。这个错的表现有时不是 404，而是一个看起来莫名其妙的路径错误，所以排查时先把这行念一遍。
6.4 --profile 的名字和配置里对不上
还有一种「配置明明改了却没生效」的情况：codex --profile mini里的名字，必须和配置中[profiles.mini]的表名完全一致，大小写也算。写成Mini或者顺手改成别的名字，Codex 找不到对应 profile 就会静默回落到默认配置，表现出来就是「我还是在用旗舰模型跑注释任务」，用量曲线能看出来。
配置保存好、两条命令都跑过之后，建议去控制台核对一下这次调用是否记上了账：用同一把 Key 在 TaoToken 模型对话 里手发一条消息，能看到返回就说明通道、Key、模型三者都对得上；需要再建一把 Key 做隔离就去 控制台 API Keys，长期高频跑轻量任务的话顺手看下 Coding Plan。
