9Router Smart Routing 与 Auto Fallback 实战：三级回退体系、自动切换与配额优化指南-平芜编程栈

9Router Smart Routing 与 Auto Fallback 实战：三级回退体系、自动切换与配额优化指南

【免费下载链接】9routerUnlimited FREE AI coding. Connect Claude Code, Codex, Cursor, Cline, Copilot, Antigravity to FREE Claude/GPT/Gemini via 40+ providers. Auto-fallback, RTK -40% tokens, never hit limits.项目地址: https://gitcode.com/GitHub_Trending/9r/9router

9Router 通过内置的 Smart Routing（智能路由）模块，为 Claude Code、Codex、Gemini CLI、GitHub Copilot 等订阅型工具统一调度 40+ 上游 provider，用「订阅 → 低价 → 免费」三级回退链保证请求永不因配额耗尽或限流而中断。本文基于 gitbook/content/en/features/smart-routing.md 展开，并结合仓库内open-sse/services/combo.js、accountFallback.js、errorConfig.js等源码实现与对应测试，讲清楚三级回退的判定逻辑、自动切换的真实行为、预算控制与配额重置策略的落地方法。读完你将能：配置 Auto Fallback 与预算上限、按成本/质量/可用性设计 fallback 顺序、看懂配额追踪与告警，并据此规划 24/7 不间断的编码工作流。

一、Smart Routing 工作原理：从请求到三级回退

1.1 核心流程

9Router 的智能路由并不只是「请求转发」，而是一个带状态判断的决策链。文档给出的总体流程如下：

Request → 9Router → Check Tier 1 (Subscription) ↓ quota exhausted Check Tier 2 (Cheap) ↓ budget limit Check Tier 3 (Free) ↓ Response

每个请求进入 9Router 后，先尝试第一级（已有订阅），只有当配额用尽或触发错误规则时才会顺延到下一级，而不是在多个 provider 之间随机分发。这样设计的目的是：最大化你已付费订阅的使用率，把额外成本压到最低，同时保证 7×24 可用性。

1.2 三级回退体系

层级	定位	代表 provider	目标
Tier 1: SUBSCRIPTION（主用）	优先消耗已购订阅	Claude Code (Pro/Max)、OpenAI Codex (Plus/Pro)、Gemini CLI（每月免费 180K）、GitHub Copilot、Antigravity (Google)	让订阅价值最大化，基本零边际成本
Tier 2: CHEAP（备份）	订阅配额耗尽后的低价兜底	GLM-4.7（$0.60/1M 输入）、MiniMax M2.1（$0.20/1M 输入）、Kimi K2（$9/月包月）	比 ChatGPT API 便宜约 90% 的应急通道
Tier 3: FREE（应急）	零成本最后防线	iFlow（8 个模型）、Qwen（3 个模型）、Kiro（免费 Claude）	保证永不因配额中断

需要说明的是，上表中的价格、免费额度与模型列表来自项目文档的快照描述，实际额度以各 provider 当前的官方政策与你在 Dashboard 中看到的配额数据为准（9Router 本身支持在 Dashboard 中实时追踪与校准，详见配额追踪文档）。

二、自动切换的真实行为：三个典型场景

文档用三个场景描述了 9Router 监控配额并自动切换的机制。结合源码可以确认：自动切换并不是在「发出请求前」预判配额，而是在请求返回错误后按规则判定是否 fallback（见下文 3.2 的checkFallbackError逻辑）。

场景 1：订阅配额耗尽（逐级下探）

User request → cc/claude-opus-4-5 ↓ quota exhausted (5-hour limit reached) Auto switch → glm/glm-4.7 ↓ daily quota exhausted Auto switch → minimax/MiniMax-M2.1 ↓ 5-hour quota exhausted Auto switch → if/kimi-k2-thinking (FREE) ↓ Response delivered ✅

场景 2：限流（Rate Limiting）

User request → cx/gpt-5.2-codex ↓ rate limited (too many requests) Auto switch → glm/glm-4.7 ↓ Response delivered ✅

场景 3：Provider 不可用

User request → cc/claude-opus-4-5 ↓ provider error (503) Auto switch → next available model ↓ Response delivered ✅

三种场景的最终效果一致：零停机、无缝体验。区别在于触发切换的错误类型——配额类错误走逐级回退，瞬态服务错误（如 503）则会进入短暂的冷却等待后继续回退（详见 3.3）。

三、模型选择逻辑：配额、成本层级、重置时间与健康度

3.1 四个决策维度

9Router 选择「当前最佳模型」时综合考量以下因素：

Quota availability（配额可用性）——检查 provider 是否还有剩余配额；
Cost tier（成本层级）——偏好顺序为订阅 → 低价 → 免费；
Reset timing（重置时机）——考虑配额何时重置，优先使用「刚重置过」的 provider；
Provider health（健康度）——跳过最近报错的 provider。

文档给出了对cc/claude-opus-4-5发起请求时的完整决策示例：

1. Check Claude Code quota ✅ Available → Use cc/claude-opus-4-5 ❌ Exhausted → Continue to step 2 2. Check fallback tier (if configured) ✅ GLM quota available → Use glm/glm-4.7 ❌ Exhausted → Continue to step 3 3. Check free tier ✅ iFlow available → Use if/kimi-k2-thinking ❌ All exhausted → Return quota error

3.2 源码实现：fallback 主循环

上述逐级尝试逻辑在 open-sse/services/combo.js 的handleComboChat中实现。核心要点（combo.js 的 L229-L331）：

按顺序遍历模型列表：对每个模型调用handleSingleModel，日志中记录Trying model i/N: xxx与成功/失败原因；
成功即返回：只要result.ok（2xx）就立即返回该响应，不再尝试后续模型；
失败时解析错误：从响应体中提取error.message、retryAfter等字段，并记录所有模型中最早的 retryAfter，用于最终向客户端返回可重试提示；
判定是否回退：调用checkFallbackError(result.status, errorText)决定是「继续回退」还是「直接返回该错误」；
瞬态错误加冷却：对于 503/502/504 且冷却时间 ≤ 5s 的情况，先等待冷却再落到下一个模型，避免「provider 短暂过载就被立刻跳过」（源码注释明确指出这修复了 combo 在瞬态 503 下穿透的问题）；
全部失败时返回 503：源码注释说明，不使用 406 而使用 503，是因为「provider 不可用或没有可用凭证」属于服务不可用而非请求本身非法，503 更准确且客户端可重试。当错误信息包含 "no credentials" 时也会归一化为 503。

3.3 源码实现：错误分类与冷却规则

open-sse/services/accountFallback.js 的checkFallbackError按「文本规则优先、状态码规则其次」的顺序匹配 open-sse/config/errorConfig.js 中的ERROR_RULES：

规则类型	匹配内容	冷却行为
文本规则（按顺序）	`no credentials`	固定 2 分钟
`request not allowed`	固定 5 秒
`improperly formed request`	固定 2 分钟
`rate limit`/`too many requests`	指数退避
`quota exceeded`/`capacity`/`overloaded`	指数退避
状态码规则（兜底）	401 / 402 / 403 / 404	固定 2 分钟
429	指数退避
默认（未匹配）	任意错误	瞬态冷却 30 秒

指数退避的参数位于 errorConfig.js 的BACKOFF_CONFIG：基础间隔 2 秒、最大 5 分钟、最高 15 级，即 1s → 2s → 4s → … 封顶 4 分钟；provider 上报的限流冷却时间（如 Codex 的resets_at）上限为 30 分钟（MAX_RATE_LIMIT_COOLDOWN_MS）。测试 tests/unit/base-executor-retry.test.js 覆盖了该退避行为。

另外accountFallback.js还提供了**模型锁（model lock）**机制：当某模型的错误触发冷却后，会在连接记录上写入modelLock_${model}字段并设置过期时间（buildModelLockUpdate、isModelLockActive），冷却期内该模型被视为不可用，从而在「组合回退」与「同 provider 多账号」场景下避免反复命中同一故障模型。

四、Dashboard 配置选项

以下配置均在 Dashboard 中完成（本地默认地址http://localhost:20128，登录密码见 Dashboard 首启引导）。

4.1 开关 Auto Fallback

Dashboard → Settings → Smart Routing → Toggle "Auto Fallback" ON/OFF

ON（默认）：自动执行层级切换，请求总能找到可用的下一级；
OFF（严格模式）：主模型不可用时直接返回错误，不做任何回退，适合「只想用订阅、拒绝额外成本」的场景。

4.2 设置预算上限

Dashboard → Settings → Budget Control → Daily limit: $5 → Monthly limit: $50

当预算到达上限时，9Router 会自动切换到免费层（Tier 3），付费 provider 不再被选中，从而保证「超支不可能发生」。配额追踪文档还补充了预算告警的两级阈值（如日预算 80% 与 100% 告警）以及「超限自动切免费层」的行为，见 gitbook/content/en/features/quota-tracking.md。

4.3 配置回退顺序

Dashboard → Settings → Fallback Priority → Drag to reorder providers within each tier

在每一层内拖拽调整 provider 优先级。文档给出的自定义顺序示例：

Tier 1: Gemini CLI → Claude Code → Codex Tier 2: MiniMax → GLM → Kimi Tier 3: iFlow → Kiro → Qwen

4.4 配额重置通知

Dashboard → Settings → Notifications → Email when quota resets → Alert when 80% quota used

除邮件外，配额追踪文档还提到可选 Webhook 投递与 Dashboard 内通知，且支持「配额 80% / 90% / 耗尽 / 重置」四个告警节点，详见 quota-tracking.md 的 Alerts 章节。

五、四种典型配置示例

5.1 示例 1：基础自动回退（默认三级）

Setup:

Model: cc/claude-opus-4-5-20251101 Fallback: Auto (default 3-tier)

Behavior:

Morning (fresh quota): Request → cc/claude-opus-4-5 ✅ Afternoon (quota exhausted): Request → glm/glm-4.7 ✅ (auto switched) Evening (GLM quota out): Request → minimax/MiniMax-M2.1 ✅ (auto switched) Late night (all paid quota out): Request → if/kimi-k2-thinking ✅ (free tier)

Cost：约 $5–10/月额外开销（大部分用量被订阅覆盖）。这个量级与文档对「100M tokens 月成本」的测算一致：80M 走订阅（$0）+ 15M 走 GLM（$9）+ 5M 走 MiniMax（$1）≈ $10。

5.2 示例 2：预算敏感型路由

Setup:

Dashboard → Settings: Daily budget: $2 Monthly budget: $20 Fallback: Enabled

Behavior:

Day 1-15 (within budget): Requests → glm/glm-4.7 (cheap tier) Cost: $1.50/day Day 16 (budget reached): Requests → if/kimi-k2-thinking (free tier) Cost: $0 Next month (budget resets): Requests → glm/glm-4.7 again

Result：月支出恒 ≤ $20，且始终可用。

5.3 示例 3：纯订阅模式（严格模式）

Setup:

Dashboard → Settings: Auto Fallback: OFF Strict mode: ON

Behavior:

Request → cc/claude-opus-4-5 ✅ Quota available → Success ❌ Quota exhausted → Return error (no fallback)

Use case：只想使用已付费订阅、零额外成本时使用。

5.4 示例 4：纯免费模式

Setup:

Model: if/kimi-k2-thinking Fallback: qw/qwen3-coder-plus → kr/claude-sonnet-4.5

Behavior:

All requests → Free tier only Cost: $0 forever

Use case：个人项目、学习与实验。

六、最佳实践与回退链设计

6.1 最大化订阅价值

Strategy: - Set subscription models as Tier 1 - Monitor quota usage in dashboard - Use cheap tier only when subscription exhausted

示例 combo：cc/claude-opus-4-5 → glm/glm-4.7 → if/kimi-k2-thinking

6.2 面向成本优化

Strategy: - Use Gemini CLI free tier first (180K/month) - Fallback to GLM/MiniMax (ultra-cheap) - Emergency: iFlow (free)

示例 combo：gc/gemini-3-flash-preview → glm/glm-4.7 → if/kimi-k2-thinking

6.3 面向质量优化

Strategy: - Use best models (Claude Opus, GPT-5.2) - Fallback to good cheap models (GLM-4.7) - Last resort: Free tier

示例 combo：cc/claude-opus-4-5 → cx/gpt-5.2-codex → glm/glm-4.7

6.4 7×24 可用性

Strategy: - Always include free tier in fallback - Monitor quota reset times - Distribute usage across providers

示例 combo：cc/claude-opus-4-5 → glm/glm-4.7 → minimax/MiniMax-M2.1 → if/kimi-k2-thinking

6.5 进阶：能力感知的自动切换（源码补充）

除了按配额/成本回退，仓库在 combo.js 的 L63-L82 还实现了按请求能力重排 combo 模型的逻辑reorderByCapabilities：

先通过detectRequiredCapabilities从请求体中识别当前对话需要的硬能力（vision / pdf / audioInput / videoInput）与软能力（如 search），检测覆盖 OpenAI chat、Claude messages、Gemini contents、Responses input 等多种格式；
再将 combo 模型按能力匹配度分为三档：Tier 0（满足全部硬能力 + 软能力）、Tier 1（只满足硬能力）、Tier 2（其余），做稳定排序后把最匹配的模型浮到最前面，且不会丢弃任何模型（回退链保持完整）。

该行为由 tests/unit/combo-autoswitch.test.js 验证：例如当请求携带图片时，vision能力会被检测出来，无视觉能力的模型不会排在最前；测试断言「floats vision-capable model to front, keeps fallback」且模型数量不变。这意味着Smart Routing 不仅能按配额回退，还会避免把带图/带 PDF 的请求路由到不支持这些模态的模型上。

6.6 进阶：round-robin 轮询策略（源码补充）

combo.js 的 L140-L186 提供了getRotatedModels：当 combo 策略为round-robin时，可配置stickyLimit（每个模型连续处理的请求数），按「每 N 个请求切换一次」的方式在模型间轮转；策略为fallback时则保持顺序尝试、不做轮转。测试 tests/unit/combo-routing.test.js 验证了默认每请求轮换、按stickyLimit粘滞以及各 combo 独立维护轮换状态等行为。适合在多个等价低价模型之间分摊负载、避免单点触发限流。

七、配额重置策略：围绕重置时间排布使用

不同 provider 的配额类型与重置节奏差异很大，文档给出的对照表是规划全天工作流的关键依据：

Provider	配额重置	策略
Claude Code	5 小时滚动 + 每周	早晨使用（配额最新鲜）
Codex	5 小时滚动 + 每周	在 Claude 配额耗尽后使用
Gemini CLI	每日（1K 次）+ 每月（180K）	全天分散使用
GLM-4.7	每日 10:00 AM（UTC+8）	晚间使用，次日早晨重置
MiniMax M2.1	5 小时滚动窗口	任意时间，滚动窗口自动追踪
iFlow / Qwen / Kiro	无限	应急兜底

结合 quota-tracking.md 的补充细节：Gemini CLI 是「请求数（每日 1,000）+ 月度 completions（180,000）双维度」；Claude Code 按模型分别统计 5 小时用量并每周一 00:00 UTC 周重置；GLM-4.7 为「每日 10M tokens、北京时间 10:00 重置」；MiniMax 为「每 5 小时 5M tokens 的连续滚动窗口」，最旧用量到期后额度自动释放。文档给出的每日例行节奏如下：

08:00 - 13:00: Claude Code (fresh 5h quota) 13:00 - 18:00: Gemini CLI (1K/day quota) 18:00 - 22:00: GLM-4.7 (cheap, resets 10AM) 22:00 - 08:00: MiniMax or iFlow (5h rolling or free)

把「重置时间」作为组合设计的输入，正是 combos.md 中reset-optimized组合的思路：早晨组合放刚重置的订阅模型，晚间组合放次日才重置的低价/免费模型。

八、监控与告警

8.1 Dashboard 配额追踪

Dashboard → Quota Overview: Claude Code: 2.5h / 5h remaining (50%) Gemini CLI: 450 / 1000 requests today GLM-4.7: 5M / 10M tokens (resets in 8h) MiniMax: 3M / 5M tokens (rolling 5h)

8.2 实时通知

Dashboard → Notifications: ⚠️ Claude Code quota 80% used (1h remaining) ✅ GLM-4.7 quota reset (10M tokens available) 💰 Daily budget 50% used ($2.50 / $5)

8.3 用量分析

Dashboard → Analytics: Today: 50M tokens - 30M via Claude Code (subscription) - 15M via GLM-4.7 ($9) - 5M via iFlow (free) Cost: $9 (vs $1000 on ChatGPT API) Savings: 99%

8.4 配额追踪的 API 化（源码补充）

配额与用量不仅能在 Dashboard 查看，仓库还提供了结构化 API。在 quota-tracking.md 中定义了如下接口形态（以本地服务localhost:20128为例）：

GET http://localhost:20128/api/quota Authorization: Bearer your-api-key

返回各 provider 的used / limit / unit / percentage、reset（类型、窗口、下次重置时间）与cost（今日/本月）。类似地：

GET http://localhost:20128/api/usage?period=today

返回请求数、token 总量、成本及按模型的拆分。仓库侧open-sse/services/usage/目录下的实现（如minimax.js对 MiniMax 用量接口按「先主后备、瞬态错误回退」的顺序探测）与src/lib/usageDb.js等持久化模块共同支撑了这一能力，适合把配额状态接入自己的监控脚本或 CI 通知。

九、故障排查

Issue: "All providers quota exhausted"（所有 provider 配额耗尽）

Solution:

打开 Dashboard 配额追踪器查看各 provider 剩余量；
等待配额重置（查看倒计时）；
在回退链中加入免费层（Tier 3）；
或调高预算上限。

Issue: "Too many fallback switches"（回退切换过于频繁）

Solution:

检查主 provider 是否宕机；
提高配额上限（升级订阅）；
改用更便宜的主模型（如用 GLM 代替 Claude）。

补充：从源码看，频繁切换的另一常见诱因是瞬态错误。handleComboChat对 503/502/504 且冷却 ≤ 5s 的错误会先等待冷却再回退（combo.js L291-L298），checkFallbackError对rate limit/too many requests/quota exceeded等文本规则统一走指数退避，因此「看似频繁」的切换往往意味着主 provider 正在限流或过载，应优先排查主链路的健康度与配额状态。

Issue: "Unexpected costs"（出现意外成本）

Solution:

Dashboard → Analytics 复盘用量；
设置日/月预算上限；
非关键任务切换到免费层；
使用带免费兜底的组合（combo）。

十、组合（Combos）：自定义回退链

Smart Routing 的三级体系是系统内置的默认策略，而Combos 允许你在 Dashboard 中自定义任意长度的回退链（combos.md）。例如：

Combo name: premium-coding Models: 1. cc/claude-opus-4-5-20251101 (try first) 2. glm/glm-4.7 (if #1 quota exhausted) 3. minimax/MiniMax-M2.1 (if #2 quota exhausted)

创建后在任意兼容客户端中把Model直接填为组合名（如premium-coding）即可，9Router 会在该组合内按序尝试直到成功。Combos 与 Smart Routing 的关系是：前者是「你自定义的回退顺序」，后者是「系统默认的三级回退与自动判定引擎」，两者共享同一套 fallback 循环与错误分类逻辑（handleComboChat同时服务两者）。常用组合建议：复杂任务用premium-coding、简单任务用budget-combo、实验用free-combo、生产代码用quality-first。

十一、总结

9Router 的 Smart Routing 把「配额管理」从人工盯盘变成了自动化的三层决策：先用订阅、再用低价、最后免费兜底，配合checkFallbackError的错误分类（文本规则 → 状态码规则 → 瞬态默认值）、指数退避冷却与模型锁机制，实现了对配额耗尽、限流和 provider 故障三类异常的自动降级。实际使用中，建议：

默认开启 Auto Fallback，并在回退链尾部保留免费层，保证 7×24 可用；
用Dashboard 预算上限 + 配额追踪控制成本，预算达到即自动切免费层；
结合各 provider 的重置时间表设计日常使用节奏（早晨订阅 → 午后 Gemini → 晚间 GLM → 深夜 MiniMax/iFlow）；
按任务类型创建多个Combo，并善用能力感知自动切换与 round-robin 策略分摊负载。

相关延伸阅读：Combos 自定义回退链、Quota Tracking 配额与用量监控。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考