【开源工具】Z-Switch：面向 Claude Code 与 Codex 的桌面供应商一键切换器

有没有新增功能如多key轮换？cc-switch目前没有任何功能更新和性能优化的倾向，issue积累了1.2K了

可以安排（同站多key还是不同站？）

同provider多key，cc-switch第一页就有这个issue

github.com/farion1231/cc-switch

[Feature Request] Provider 级多 Key 池：手动切换、组内轮询与会话粘性

已打开 09:21AM - 13 Jul 26 UTC

Jason-purse

Self Checks / 自检

• [x] I have read the FAQ section in README.

我已阅读 README 中的常见问题。
- [x] I have searched for existing issues, including closed ones.
我已搜索过已有的 Issue，包括已关闭的。

Related App / 涉及应用

Codex, General / 通用

Problem or Motivation / 问题或动机

我的实际配置中有两个不同的上游中转站，每个站点各有约 10 个 API Key。它们的端点、倍率、协议兼容性和响应处理能力可能不同。

CC Switch v3.16.5 当前是一条 Provider 记录绑定一套凭据，路由层则是每个应用一条扁平的 failover 队列。为了表示上述配置，只能创建 A-1 ... A-10、B-1 ... B-10 共 20 条 Provider 记录，再把它们放进同一个队列。这样缺少两个重要语义：

1. 用户不能把 A 当作一个可手动切换的逻辑 Provider，并只在 A 的 Key 池内循环。
2. 组内 Key 轮换、组间 Provider 切换和会话粘性没有明确边界，容易把不同上游混在同一个会话中。

这对 Codex Responses 尤其重要。reasoning / compaction 中的 encrypted_content 可能绑定到生成它的 Provider 或 API Key；如果同一会话按请求轮换到另一把 Key 或另一个 Provider，后续请求可能出现 invalid_encrypted_content，或者目标上游无法继续处理此前的压缩内容。

我希望顶层仍保留 CC Switch 现在直观的手动切换体验：用户点击切到 Provider A 后，流量只在 A 的 Key 池内调度；点击切到 Provider B 后，再使用 B 的 Key 池。自动跨 Provider 混合不应是默认行为。

Proposed Solution / 建议方案

增加“逻辑 Provider + Provider 内 Key 池”的双层路由，并让手动 Provider 切换成为一级控制：

1. Provider 内多 Key 池
- 一个 Provider 保存共享的 endpoint、协议、模型映射和其他配置。
- Provider 下可配置多把 Key，并支持启用/禁用、别名、优先级、配额/冷却状态和独立用量统计。

2. 手动切换逻辑 Provider
- 主界面仍由用户直接选择 A 或 B。
- 选中 A 时，只使用 A 的 Key 池；B 不接收流量。
- 用户切到 B 后，新会话/新请求再进入 B 的 Key 池。

3. 会话级 Provider + Key 粘性
- 对 Codex Responses 等有状态场景，默认在创建会话时从当前 Provider 的池中选择一把 Key，并将该会话固定到 provider_id + key_id。
- 新会话可以在池内 round-robin / priority / quota-aware 分配，但同一会话不要每个请求换 Key。
- 对无状态或明确兼容的 API，可提供可选的 request-level round-robin。

4. 跨 Provider fallback 必须显式配置
- 默认只在当前手动选择的 Provider 内重试/换 Key。
- 可选配置 A -> B 的 Provider 级 fallback，但只有 A 的 Key 池不可用时才进入 B。
- 若在会话中途切换 Key/Provider，需提供明确策略：保持旧会话粘性、提示重新开会话，或在用户显式开启时清理/降级不兼容的 encrypted_content；不要静默混用。

5. 可观察性
- 请求日志显示逻辑 Provider、脱敏 Key 标识、选择原因（manual / round-robin / quota / fallback）和会话粘性状态。

期望行为示例：```text
Provider A: A1 ... A10
Provider B: B1 ... B10

用户手动选择 A
Session S1 -> A/A3（后续请求保持 A/A3）
Session S2 -> A/A4（新会话可在 A 池内分配）
B 不接收流量

用户手动选择 B
新 Session S3 -> B/B1
已有 S1/S2 默认仍保持原粘性，或按用户选择的迁移策略处理
```### Additional Context / 补充信息

相关需求已有部分实现或讨论，但目前没有一项覆盖完整组合：

• #1278：Provider 分组、多 Key 管理及轮询策略。
• #4831：同 URL 多 Key 的批量导入和列表分组。
• #3153：组级本地路由和 fallback，但主要面向模型/Provider 分组。
• #3926：会话/线程级 Provider 粘性和并发调度。
• #4957：Provider + API Key 双层轮询；当前描述的 request-level Key round-robin 对 Codex encrypted_content 场景仍需要 session/key affinity 约束。
• #2581（closed, unmerged）：记录了切换 Provider/API Key 后 invalid_encrypted_content 的恢复尝试。
• #4464：跨 Provider 会话历史中 encrypted_content 无法解密的实际问题。

本 issue 不是单纯的 UI 文件夹分组，而是希望明确这些能力如何组合成安全、可手动控制的两层路由语义。

Contribution / 参与贡献

• [ ] I am interested in contributing to this feature.

我有兴趣参与开发此功能。

收到，这个功能下个版本安排，争取加快。

建议增加从cc-switch导入站点

建议佬友把grok build switch也做了，CC Switch目前没有 ^-^

你看代码，cc switch马上就有了，代码已经合并了，就是没有发版

github.com/farion1231/cc-switch

feat(grokbuild): add first-class Grok Build support (#5453)

main ← YUZHEthefool:feat/grokbuild-support

已合并 07:50AM - 17 Jul 26 UTC

YUZHEthefool

+4530
-246

Summary / ??

Add Grok Build CLI as a first-class switchable app backed by it…s native ~/.grok/config.toml format.

• manage, import, browse, and switch Grok Build providers with structured [models] / [model.*] configuration
• expose an independent /grokbuild/v1/responses route with its own provider namespace and failover queue
• make routed hot switches transactional so failed writes restore the previous provider, backup, and live config
• integrate Grok Build with MCP, prompts (~/.grok/AGENTS.md), Skills, native sessions, settings, and tray switching
• add complete Grok CLI lifecycle management in Settings > About: installation status, current/latest versions, refresh, one-click install/upgrade, bulk upgrades, conflict diagnostics, and manual install commands
• align Grok provider icons with existing apps: custom providers use the name-initial fallback, presets keep their own icons, and legacy auto-assigned Grok icons are normalized without overriding explicit user choices
• add schema migrations and regression coverage for provider switching, routing rollback, MCP serialization, sessions, and UI flows

Related Issue / ?? Issue

Fixes #5407

Related prior discussion: #4825

Implementation Notes

• Grok remote MCP keeps Grok-native headers and omits Codex-only type / http_headers fields.
• Provider switches and proxy teardown preserve [mcp_servers.*] entries in config.toml.
• Session management reads native ~/.grok/sessions/**/summary.json and chat_history.jsonl, and resumes with grok --resume <session-id>.
• Prompt auto-import covers both first launch and database migration paths.
• CLI installation and updates use the official @xai-official/grok package; updates stay anchored to the detected npm/Volta/pnpm/Bun installation, including Grok-specific WSL directory overrides.
• Grok provider cards now follow the shared icon semantics: blank custom icons render provider initials, preset icons remain provider-specific, and the compatibility path distinguishes old automatic Grok icons from explicitly selected ones.

Screenshots / ??

No static screenshot included. The complete Tauri debug build was manually verified on Windows 11 with real Grok provider, session, and Skills data.

Verification

• npm run typecheck
• npm run format:check
• npm run test:unit -- --testTimeout=15000 (72 files, 462 tests)
• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test with isolated LOCALAPPDATA (1,995 passed, 2 ignored, plus all integration suites)
• npx tauri build --debug --no-bundle --ignore-version-mismatches with the existing production frontend bundle

Checklist / ????

• [x] pnpm typecheck equivalent passes via the repository npm run typecheck script
• [x] pnpm format:check equivalent passes via the repository npm run format:check script
• [x] cargo clippy passes with warnings denied
• [x] Updated all four locale files for user-facing text

感谢佬友的建议，下个版本尽快安排

支持一下子，支持支持！ 快快更新

佬考虑做多端点的路由吗，比如我想opus用any的，sonnet拿GLM充当，这种需求。

我看ccs那边是有个代理模式当网关，可惜没实现这种多端点

这是个好东西啊 CCS真的是太复杂了 研究好半天 有的时候还搞错

另外能不能一键导入CCS的配置呀 这个都是在用户本机 也不存在什么侵权

我的ccswitch就是打不开, 网上各种办法都试了, 正好用用佬的尝试一下