Claude/Codex 额度焦虑，你可能缺一层模型调度

同时订阅了三四个 AI 平台的开发者，账单和体验往往两头不讨好。

这边月度额度还没用完，那边 rate limit 突然卡死，请求排队等到超时。tool output 一跑长上下文，token 数字跳得比心跳还快。

想换个便宜点的 provider，又得逐一手动改配置文件里的 base URL 和 API key。

这些琐碎的摩擦，单看每一项都不算大事，堆在一起就是时间和钱的双重损耗。

decolua 的 9router 想处理的就是这组问题。

额度焦虑背后是调度问题

项目在 GitHub 有大约 7800 star、1200 多个 forks，定位是 FREE AI Router & Token Saver。

它的主张很直接，把市面上 40 多家 AI provider、100 多个模型，统一接到一个路由层下面，让开发者不用再为「接哪家、怎么切、额度怎么省」来回折腾。

路由层最直观的效果是省 token。

9router 用了 RTK 机制，项目文档给出的目标是把 token 消耗压降 20% 到 40%。这个数字先当项目方口径看，更值得关注的是它盯住了 coding agent 最容易烧钱的地方。

对 coding 场景来说，账单经常被长上下文、工具输出和反复往返的中间信息撑起来，那几句 prompt 反而只是小头。

9router 做压缩和调度，价值就在这里，把最吃 token 的部分尽量交给更合适的模型链路。

模型挂了，任务别跟着挂

自动 fallback 是另一张牌。

当某个 provider 触发 rate limit 或临时宕机时，9router 自动把请求切到免费或低价的备用模型上，不需要开发者手动改代码或换 key。

这层兜底对长时间跑的 coding agent 更有用。

任务跑到一半，某个 provider 突然限流，最烦的不是点一下重试，麻烦在整条流水线可能被打断。

Claude Code、Cursor、Continue、Aider 这类 AI coding 工具，背后都可以接 9router 做模型层。

开发者在一个地方配置好 provider 列表、额度上限、优先级策略，所有工具共享同一张路由表。

换工具不用重新配 key，加 provider 也不用逐个项目改配置。这个设计对工具链复杂的团队尤其有用，前端用 Cursor，后端用 Claude Code，运维脚本调 OpenRouter，尽量收进同一张路由表，额度消耗也更容易看清。

路由层不是越多越好

很多人用 AI 编程到后面，模型本身反而没那么烦，一堆账号、额度、路由规则才是日常噪音。

当你已经有明确的任务类型，比如代码补全、代码审查、文档生成、对话，它能帮你把任务匹配到成本更低、当前可用的模型上。

40+ providers、100+ models 这些数字当然吸睛，但我更关心的是，它把免费额度、按量付费、批量折扣这些不同计费方式放到同一层里处理。

对经常切模型的人来说，这比单纯多接几个模型更有用。

不过加一层路由，也等于多了一层要维护的东西。

9router 本身如果出问题，配置错误、路由策略偏差、某个 provider 的 API 格式突变，排查链路会比直连 provider 更长。另外，20% 到 40% 的 token 节省数字来自项目自述，真实收益取决于具体的调用模式。

短文本、低频次请求省不了多少。长上下文、高并发、多 tool call 的场景，压缩空间才大。

这个项目适合已经同时使用多个 AI provider、或者团队里多人共享 API 资源的场景。

选哪家模型、额度怎么分配、挂了怎么切，这些事如果都散在每个开发者自己的配置文件里，迟早会乱。9router 做的就是把这些规则收拢到同一层。

模型越来越多，下一阶段比拼的不只是模型能力，还有谁会调度。