事情是这样的。
最近在用 Codex 做项目，遇到一个挺现实的问题，同一个账号里有好几个模型，模型名看着都很厉害，可每次到底该用哪个，还是得自己选。特别是 gpt-5.6 出来之后，但是自己每次都忘记选，基本都是 gpt-5.6-sol high。
改一个按钮的 loading 状态，开最强模型，多少有点浪费。跑的都是人民币呀。😄
遇到跨模块的状态同步 bug，却为了省一点额度，硬让轻量模型反复试错，最后时间全花在重跑上。
模型越来越多，选择反而越来越像一道题。有时候忘记选，有时选的不够准确。
所以我做了 AutoRoute，一个给 Codex 用的路由 skill。它不负责替你写代码，默认情况下也不动你正在运行的会话——先分析任务，推荐更合适的模型和推理强度，并把切换命令准备好；你明确说要切，它才动手。
你可以把它理解成一个方向盘。
你只管说要做什么，它来帮你判断这次该用小模型快速处理，还是把任务交给更强的模型认真推一遍。
安装与使用
装好之后，Codex 会根据 skill 的描述自动判断什么时候用它——只要你的话里带上「该用哪个模型」「帮我路由一下」这类意思，它就会自己上，不用记任何命令。想更明确一点，也可以喊 $autoroute，效果一样。
所以全程都在 Codex 对话里完成，你不需要记住任何脚本路径，也不用单独开终端。比如直接这样说：
这个任务该用哪个模型？给 Button 组件加个 loading 状态。
它就会告诉你推荐结果和理由。
三种模式
AutoRoute 有三种模式，默认是 auto。名字听着唬人，其实区别很简单：
suggest：只动嘴。你问「这个任务该用哪个模型」，它回你建议和理由，到此为止。manual：最保守，直接沿用你当前的模型和推理强度做推荐，保证不动你现有的任何设置。auto（默认）：给建议，顺手把新会话的命令也准备好。
关键是，就算是 auto，默认也止步于「建议 + 准备好」，不会偷偷执行。你不发话，它就不碰任何东西。
发话之后有两条路，对应两个显式开关。--run 是老办法的自动化版：按推荐配置直接帮你开一个新的 Codex 会话；--session 是新版本加的能力——直接切当前会话。以前 Skill 确实碰不了已经在跑的 Codex 对话，只能另开新会话；现在它会找到你当前 Codex 所在的终端，替你敲 /model 和 /effort 命令，把眼前的对话切到推荐的模型上。两个开关都要你明确发话才动手，一旦指定就直接执行，中途不再要你确认。万一 --session 切换失败（比如没找到终端），它也不硬来，退回老办法把新会话命令递给你。
六维评分
这不是简单的关键词匹配。
AutoRoute 会从六个方向看任务：复杂度、改动范围、推理需求、风险、上下文大小，还有后续迭代长度。每一项是 0 到 5 分，最后合成一个任务等级，再分别决定模型和 effort。
模型和推理强度是分开选的。有些任务并不复杂，但需要多想几步，可能模型不用换，effort 先升一档就够了。反过来，有的任务描述看着不长，背后却牵扯生产数据、兼容性和回滚，那模型和 effort 都应该更谨慎。
而且 effort 现在支持七个档位：none / low / medium / high / xhigh / max / ultra。不同模型支持的档位不同，AutoRoute 会自动选择最接近且支持的档位。
自适应升级
它会根据运行中的信号自适应升级。测试失败次数增加、重试次数过多、改动文件突然变多，或者一次任务跨了好几种语言，都可能让评分升高，进而触发更高的 effort 或模型档位。比如重构同步层时，已经连续失败两次、重试三次、改了 14 个文件，推荐会从普通任务升级到 gpt-5.6-sol 加 high。
这很像一个靠谱的同事在旁边提醒你：事情已经比最开始想的复杂了，别再用原来的配置硬顶。
几个我觉得挺贴心的细节
模型可用性不是想当然的。 AutoRoute 第一次运行，或者缓存超过 15 分钟，会做一次轻量探测。探测被权限或沙箱拦住时，它也不会武断地说模型不可用，而是保留已经发现的目录继续路由，并在输出中标记 probe_status=blocked。这类细节平时不显眼，真到 provider 抽风、测试环境没有完整模型目录时，就能少踩不少坑。
每次 Codex 启动都会刷新。 仓库带了一个 codex-with-autoroute 包装脚本，替换系统里的 codex 命令，每次启动 Codex 都会重新探测模型可用性。你也可以自己加 shell alias。
配置也很灵活。 可以通过 ~/.codex/autoroute.json 配置默认模式、缓存路径等，也可以传 --workload 显式指定工作负载类型（simple / everyday / debugging / architecture / research / long_horizon / high_risk），让路由更精准。
几个实际的路由例子
我拿几类任务实际跑了一遍，路由结果很清楚。
- 给按钮加 loading 状态，AutoRoute 推荐
gpt-5.6-luna，推理强度low。 - 做一个带校验的设置表单，推荐
gpt-5.6-terra，推理强度medium。 - 调一个跨页面、偶发出现的 React 状态同步问题，推荐
gpt-5.6-sol，推理强度high。 - 设计一个带冲突解决、持久化和迁移计划的协同编辑架构，推荐
gpt-5.6-sol，推理强度high。 - 做多季度的仓库现代化规划（长周期任务），推荐
gpt-5.2，推理强度high——它更适合长周期工作；如果目录里没有它，会回退到其他与任务等级匹配的模型。
丑话说在前面
当然，它也不是算命的。任务描述写得越清楚，评分越靠谱。你如果只丢一句「把系统改好」，它只能按有限线索做保守判断。
另外，自动路由不等于一定省钱。模型不可用、任务失败、来回重试，都会把成本拉回来。真正应该看的，是成功率、结果质量、总 token、重试次数和耗时，仓库里放了评测脚本可以自己跑对比，别拿一两个任务就急着下结论。
最后
我觉得 AutoRoute 最适合的，不是那种每天只用一个模型、任务也很固定的人。它更适合下面这种状态：项目在持续变大，模型选择越来越多，任务有时是小修小补，有时又突然变成跨模块排查。你不想每次都从模型列表重新做一遍判断，但也不愿意把所有活都丢给最贵的那一个。
把模型选择交给规则，把最终决定留给自己。
这就是我做这个 skill 的出发点。
如果你也在用 Codex，欢迎把它装上试试。跑几个你熟悉的任务，看它的判断是不是符合你的直觉，再决定要不要接入日常工作流。
工具不应该增加新的负担。
它只需要在你犹豫「这次到底该用哪个模型」的时候，帮你少想一会儿。
以上，既然看到这里了，如果觉得这个项目有点用，欢迎去 GitHub 点个 star，也欢迎把你遇到的路由问题提出来。一个人的规则总有盲区，多跑几种真实任务，AutoRoute 才会越来越像一个真正能帮上忙的工具。
谢谢你看到这里，我们下次再见。
