Codex 的模型分层卡人的地方往往不是「该用哪个模型」而是~/.codex/mini.config.toml里那三行——model、model_reasoning_effort、approval_policy全写了可这条轻量 profile 的请求究竟从哪条通道出去、用哪把 Key 鉴权文件里一个字没提。想让 mini 和旗舰两条线各自跑到该去的地方先把模型来源补上打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册账号并创建一把 API KeyTaoToken 在这里提供的就是一把 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. 在模型广场挑好两档模型再创建 Key2.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_sourcetaotoken_aicg_blog_end 上的模型广场当时列表为准。你在挑的时候按能力档位选要承担补注释、写单测、格式化的那一档和要承担多文件重构、架构分析的那一档各选一个把准确的 ID 字符串复制出来别凭记忆手打。顺手确认一下自己的用量预期。轻任务天天跑消耗累积起来很快如果是长期写代码的场景可以先去 Coding Plan 看一眼套餐形态是否够用避免配完两天就撞额度线。3. 改 ~/.codex/config.tomlprovider 与 profile 分成两层3.1 顶层声明 model_providers.taotokenCodex 的配置文件放在~/.codex/config.tomlprovider 段写在这里。注意这里填的是接口地址不是官网地址两者别混# ~/.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_KEYbase_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_KEYYOUR_API_KEY改完记得source一下当前会话或者干脆新开一个终端窗口。Key 从 https://taotoken.net/?utm_sourcetaotoken_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 401Key 没进到进程环境里最典型的是401 Unauthorized。九成情况是env_key指向的变量在当前终端里不存在——可能是 export 写在了别的 shell 配置文件里也可能改了.zshrc但没重开终端。先用echo $TAOTOKEN_API_KEY确认一下输出为空就是它。另一种可能是 Key 复制时头尾带了空格或换行删干净重新粘贴。6.2 404 或 model_not_found模型 ID 是手打的接口能连上但返回找不到模型通常是model字段里的字符串跟模型广场上的不一致。别凭原文里的示例型号照抄直接回 https://taotoken.net/?utm_sourcetaotoken_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。