Astra 出来以后，我身边越来越多人开始聊同一个问题：模型是真的强，但额度也是真的不够用。

大家一边想让 Agent 全程用最好的模型、开最高的推理档，一边又忍不住盯着剩余额度。简单任务舍不得用，复杂任务又怕用到一半没额度。最强模型明明已经握在手里，用起来却像在刷一张随时可能爆掉的信用卡。

这种焦虑对我来说并不新鲜。

在 Astra 出现之前，我已经在 Sol 上被狠狠教育过一次。当时我给一个长任务配上 Sol、最高推理档和 Goal，想着模型更强、推理更深，再让它持续工作，成功率总该高一点吧。

结果这一波几乎烧完了我当周所有 token。任务是做了，但接下来几天我都没有好模型可用，正常工作反而受到了影响。

也是从那时开始，我认真研究起了一件不那么性感、但更实际的事：怎么把好模型留给真正需要它的任务。

所以 Astra 并没有让我开始研究省 token。它只是把一个我在 Sol 时代踩过的坑，变成了更多 Agent 用户都能感受到的问题。

新 SOTA 不是旧 SOTA 的退役通知

每次新 SOTA 出来，我们很容易产生一种朴素的冲动：既然新的更强，那就把旧的全换掉。

但不管是 Astra 与 Sol，还是 Fable 与 Opus，我现在的答案都是：显然不应该。

SOTA 代表的是能力上限，不是所有任务的默认档位。大部分日常开发任务根本碰不到 Astra 的智能上限。边界明确的需求实现、已有代码里的普通修改、一次有清晰验收条件的排查，往往不需要模型在未知世界里反复探索。

而 Sol、Opus 这样的上一代强模型，也不会因为新模型出现就突然变笨。在跨模块集成、架构判断、方案复核这些任务里，它们的能力依旧足够，性价比甚至可能更加突出。

新 SOTA 的正确位置，应该是路由表里新增的最高档位，而不是一封发给所有旧模型的退役通知。

先把“省 token”这件事算对

最开始做优化时，我也很自然地盯着总 token 看：这个星期用了多少，比上个星期少了多少，哪个模型的单价更低。

后来我发现，只看这个数字很容易把自己带沟里。

假设我把一个原本能一次完成的任务交给便宜模型，来回重试了五次，最后还得换回高级模型收尾。表面上每次调用都便宜了，实际上任务交付得更慢、更贵。

更极端一点，如果一个任务消耗很少，但最终根本没有闭环，它对工作产出的贡献就是零。把这种消耗和真正交付的任务混在一起统计，得到的“平均成本”也没什么意义。

所以我后来把目标改成了：

Cost / Successful Delivery：每完成一个真实闭环，需要付出多少成本。

这里的分母非常重要。

我只统计真正闭环的父任务，并且只把属于这批任务、发生在闭环之前的成本放进分子。未完成的任务、无法归属的子任务、闭环之后又重新打开产生的成本，都不能随手摊进来。

省 token 的目标也因此变了：不是让一次对话尽可能便宜，而是让每个任务更稳定、更快、更便宜地走到终点。

我现在怎么给任务选模型

过去我选模型，多少还带着一点排行榜思维：复杂任务用最强模型，简单任务用便宜模型。

现在我更关心的是任务的状态：初始信息清不清楚，执行路径稳不稳定，工具返回结果之后要不要重新规划，以及失败会不会影响多个系统。

模型和推理强度也必须放在一起选。选了 Sol 还是 Astra，只回答了“由谁来做”；开 medium、high 还是 xhigh，才决定了“让它想多深”。

我目前使用的路由大致如下：

任务形态	路由	我为什么这样选
只读检索、代码定位、资料盘点	Luna / medium	判断压力不高，适合低成本并行侦察
范围固定、可以机械验收的微小修改	Spark / xhigh	任务小，但需要严格遵守固定规则
边界清楚的日常实现	Terra / high	能覆盖大部分普通研发任务
跨模块集成和长链路实现	Sol / high	需要更强的上下文理解，但通常不必动用最高档
架构、方案和风险复核	Sol / xhigh	强判断任务，值得多给一点推理预算
初始状态未知、工具反馈会持续改变计划	Astra / high	真正需要边做边重新规划
强耦合因果和困难不变量	Astra / xhigh	只留给最高智能不可替代的场景

这里最容易被误解的一点是：任务“代码很多”或者“看起来很复杂”，并不自动等于需要 Astra。

如果初始状态已知，修改边界和验收条件也很明确，那么即使工作量不小，Sol 或 Terra 也可能更合适。相反，一个代码量不大的问题，如果每一次工具返回都会推翻前面的判断，还牵涉多个系统的状态变化，就更值得让 Astra 接手。

换句话说，真正触发最高档模型的，不只是复杂度，还有未知程度和重规划压力。

还有些工作，根本不需要模型

模型路由解决的是“需要智能判断的任务交给谁”。在这之前，还有一层更直接的过滤：这件事真的需要模型吗？

如果目标集合有限、每一项执行相同算法、过程中不需要逐项做语义判断，验收方式也完全一致，那就应该让批处理脚本直接做。让 Agent 一项一项读、一项一项改，只是在用昂贵的 token 模拟一个循环。

长时间等待也是类似的问题。任务已经提交给外部系统后，保存句柄、低频查询状态、完成后再回来验收就够了。没有必要让高级模型守在原地，一遍遍问“好了吗”。

这两件事确实能省下不少 token，但它们不是整套机制的主角。把明显不需要智能的工作清出去以后，剩下的关键问题仍然是：需要语义判断的任务，应该匹配多少智能和多少推理预算。

数据跑完了：不是少花 token，而是做完更多事

规则跑了一段时间以后，我回看了本地两个月的 Codex 日志。

这次没有直接比较总 token，而是重新识别真实闭环的任务，把每个任务在闭环前产生的成本归到它自己身上，再计算单次闭环交付成本。成本按照模型公开价格估算成 API 等价值，只用于前后比较，不代表我的 Codex 订阅账单。

为了尽量减少任务结构变化的干扰，我重点比较了模型档位和路由规则稳定前后各 14 天的数据：

前后两个窗口的平均任务复杂度从 3.33 变为 3.00，基本还在同一档。在这个前提下，平均单次闭环成本从 $13.21 降到 $6.57，平均交付时间从 10.69 小时降到 4.88 小时；同样 14 天内，闭环任务数则从 12 个增加到了 24 个。

这才是我真正想要的结果：不是一张“本周少用了多少 token”的漂亮报表，而是更高的真实任务吞吐量。

不过，数据里还有一个不能藏起来的细节：同期中位成本从 $1.44 上升到了 $2.62，中位交付时间也从 0.20 小时上升到了 0.76 小时。

这意味着机制的收益并不是“让每一个小任务都变得更快、更便宜”。它更明显地压低了那些极端昂贵、极端耗时的长尾任务。后一个窗口里完成的中等体量任务更多，典型任务的中位数反而有所上升，但少数任务不再轻易吞掉整周预算，整体平均成本和平均时间才大幅下降。

这其实比一条整齐向下的曲线更符合我的体感。我最初想解决的，本来就不是几毛钱的小任务还能不能再省一点，而是避免下一次 Sol + 最高推理档 + Goal 再把整周额度一口吃掉。

这份对比也不是严格的 A/B 实验。路由、批处理和异步规则在相近时间陆续落地，任务复杂度评分本身也只是对任务结构的归类，不能据此计算每项措施分别贡献了多少。Astra 路由刚加入不久，目前更没有完整的后窗数据。

所以我能说的是：机制落地之后，在任务复杂度大体相当的窗口里，单任务平均交付成本和时间下降了，闭环吞吐量上升了；但我不能把全部变化都归功于某一条路由规则，更不能提前宣布 Astra 已经替我省了多少 token。

Goal 不应该拿到一张空白支票

回头看，当初真正把我额度烧光的，并不只是 Sol 贵，也不只是推理档开得高。

问题在于，我把强模型、最高推理档和一个持续反馈循环叠在一起，却没有给它明确的预算和停止条件。每一项设置单独看都有合理性，组合起来却相当于给任务递了一张空白支票。

所以我现在只在明确需要跨轮持续推进时才创建 Goal，而且必须同时给出 token budget、停止条件和升级规则。普通的一次性任务，哪怕步骤很多，也不因为“看起来麻烦”就自动进入无限循环。

高智能模型可以自主推进，不代表它应该无限推进。

最后

Astra 很强，我也仍然希望在真正困难的问题上用到它。

但现在的我不会再因为它是最新、最强的模型，就让它接管所有任务。Sol 和 Opus 没有因为新 SOTA 出现就失去价值，Terra、Luna、Spark 也不是单纯的“降级选项”。它们共同组成了一条更完整的能力曲线。

当任务真正需要在未知状态里探索、根据反馈不断重规划时，我希望 Astra 能毫无顾虑地上场。也正因如此，我更不愿意让它把额度花在一个普通检索、一次机械修改，或者一段漫长的等待上。

省 token 从来不是少用模型，而是一直有得用。

新 SOTA 的意义，是帮我们解决过去解决不了的问题，而不是用更昂贵的方式重新完成所有旧问题。

如果你也想在 Codex 中使用同一套任务—模型—推理能力路由，我把完整规则整理成了一份可以直接复制的 Prompt：

Codex Token Efficiency Routing Prompt