[Feature Request] 支持模型级别的故障转移

[huanghuoguoguo]

背景

开启 Proxy 后，用户通过 takeover 机制不再感知 URL 和 API Key，但会指定 model 来选择使用的模型。多个 provider（如 coding plan）可能都支持同一个模型，这为模型级别的容灾提供了基础。

当前问题

现有的故障转移是 provider 级别 的：切换 provider 时会应用该 provider 的 model mapping，导致请求的模型名可能发生变化。

例如：

• qwen provider mapping: claude-sonnet-4 → glm-4.7
• 方舟 provider mapping: claude-sonnet-4 → minmax

当 qwen 失败切换到方舟时，请求的 model 从 glm-4.7 变成了 minmax，而方舟其实也支持 glm-4.7。

需求

支持 模型级别的故障转移：根据请求指定的 model，只切换到支持该模型的 provider。

请求: { model: "glm-4.7", ... }
    ↓
Proxy 查询: 哪些 provider 支持 glm-4.7?
    - qwen: ✓
    - 方舟: ✓
    ↓
qwen 失败 → 方舟接管 → 仍然请求 "glm-4.7"

实现建议

模型列表缓存（而非持久化）

provider 的模型列表可能随时间变化，建议：

1. 内存级缓存模型列表（不写入数据库）
2. 极低频率定时刷新（如每天一次或每周一次）
3. 提供手动刷新命令：cc-switch provider refresh-models <id>
4. 或在 Proxy serve 时启动后台刷新任务

这样既避免数据库复杂度，又保持模型列表相对新鲜。

关联

• 已有 fetch-models 命令可获取模型列表，但目前只用于展示
• 可复用现有的模型扫描逻辑（OpenAI 兼容、Gemini 格式等）

[lm970585581]

现有的故障转移是 provider 级别 的：切换 provider 时会应用该 provider 的 model mapping，导致请求的模型名可能发生变化。

现在支持 provider 级别 的故障转移吗？请问是怎么开启的呢

[huanghuoguoguo]

问一下cc怎么开，我记得是p。

[huanghuoguoguo]

设计方案

核心问题：当前故障转移会改变请求模型

开启 Proxy + auto_failover 后，切换 provider 时会重新应用 model mapping：

用户请求: model="claude-sonnet-4"
    ↓ qwen mapping
实际发送: model="glm-4.7"
    ↓ qwen 失败，切换方舟
    ↓ 方舟 mapping（claude-sonnet-4 → minmax）
实际发送: model="minmax"（变了！）

问题：方舟可能也支持 glm-4.7，但因为 provider 级别切换，model mapping 把请求模型改了。

---

设计理念：用户应关注模型，而非提供商

开启 takeover 后，用户通过 Proxy 不感知 URL 和 API Key，但仍需切换 provider。更合理的体验是：

用户只关心"用什么模型"，Proxy 负责找到支持该模型的 provider。

配合 Claude Code 的 settings.local.json 机制（当前目录配置优先，不重启即可切换），用户可以：

cd ~/project-a
cc-switch provider export provider-a  # 导出配置到 .claude/settings.local.json
claude --model glm-4.7  # Proxy 自动路由到支持该模型的 provider

---

实现方案

1. 新增开关：让用户选择策略

开关	策略	行为
model_level_failover_enabled = false	Provider 优先（原有）	切换 provider 时重新应用 model mapping
model_level_failover_enabled = true	Model 优先（新增）	只切换到支持该模型的 provider，model 保持不变

开关位置： 放在 TUI 的 Settings → Proxy 子页面（LocalProxySettingsItem），用户可在 Proxy 配置界面直接勾选切换，显示 [enabled] 或 [disabled] 状态。

向后兼容：默认关闭，保持原有行为。

2. Model 优先模式的核心逻辑

请求到达 → 提取 model 字段
    ↓
查询缓存：哪些 provider 支持这个 model？
    ↓
按优先级尝试：
    1. 当前 provider（如果支持）
    2. failover_queue 中支持的其他 provider
    ↓
切换 provider → model 保持不变（不重新映射）

3. 模型列表来源

Provider 支持的模型 = 多来源合并（优先级从高到低）：

来源	说明
自动获取	调用 provider 的 /v1/models 接口获取模型列表（如果支持）
配置推断	从 model mapping 的 keys 推断（接口不支持时作为补充）
无 mapping	透传模式，理论上支持所有模型（故障转移时优先级最低或跳过）

推断逻辑：

// Provider 配置了 model mapping：
{
  "modelMapping": {
    "claude-sonnet-4": "glm-4.7",
    "claude-opus-4": "glm-4-opus"
  }
}
// 推断该 provider 支持：claude-sonnet-4, claude-opus-4（请求端的模型名）

合并策略：

• 有 /v1/models 接口且成功返回 → 使用接口返回的列表
• 接口失败或不支持 → 使用 model mapping keys 推断
• 两者都没有 → 不支持

退化策略：

• Model 优先模式下，如果找不到任何支持该 model 的 provider
• → 退化为 Provider 优先模式（原有故障转移行为）
• → 同时输出日志警告，告知用户这种情况

4. 缓存设计

缓存位置：内存（不存数据库）

理由：

• 模型列表变化不频繁，重启 Proxy 重新获取即可
• 预计新增 model_cache.rs 实现内存缓存（HashMap + RwLock）
• TTL 24小时，过期自动重新获取

启动时机：Proxy 启动时后台任务

• 对当前 provider + failover_queue 中所有 provider 并行获取模型列表
• 获取失败时使用 model mapping 推断作为 fallback
• 只有成功构造支持模型列表的 provider 才进入 proxy 池
• 此机制可过滤失效 provider（key 失效、接口不可用等）
• 不阻塞 Proxy 启动，后台静默完成

刷新时机：

场景	行为
Proxy serve 启动	后台任务，对所有 provider 并行获取/推断，过滤无效 provider
手动刷新命令	提供命令立即刷新模型列表，重新过滤 proxy 池

设计说明：

• Proxy 运行期间不自动刷新（简化逻辑）
• 需要刷新时：使用手动命令或重启 proxy
• 后续可扩展：监听配置变更自动同步（provider 级别故障转移也未实现此功能，后续再考虑实现）

---

预计修改文件

文件	改动内容
settings.rs	添加 model_level_failover_enabled 字段到 AppSettings
proxy/types.rs	AppProxyConfig 添加新字段
proxy/provider_router.rs	根据开关决定路由策略
proxy/handler_context.rs	根据开关调用选择方法
proxy/forwarder.rs	Model 优先模式切换时不重新映射 model
proxy/model_cache.rs	从 model mapping 推断支持模型列表
cli/tui/app/app_state.rs	LocalProxySettingsItem 添加新项
cli/tui/app/content_config.rs	处理开关切换逻辑
cli/tui/ui/config.rs	渲染开关状态
cli/i18n/texts/*.rs	添加相关文本

---

功能增强总结

1. 用户可选策略：新增开关，TUI Proxy 设置页面可直接勾选，向后兼容
2. Model 优先体验：用户只关心模型，Proxy 自动路由
3. 多来源模型列表：自动获取（/v1/models 接口）+ 配置推断（model mapping），无需额外字段
4. 配合 settings.local.json：当前目录配置，不重启切换

---

如果这个设计方向符合项目理念，我来实现这个功能。