CC Switch vs magpie 详细对比

一句话： 两者都能「让 Claude Code 用别家的模型」，但根本不是同一类工具——CC Switch 是配置管理器（帮你改配置文件，路由是可选增强），magpie 是本地网关（所有请求必经它转发，配置只是副产品）。

关于本文

• 对比对象：
  • CC Switch — farion1231/cc-switch，版本基准 v4.0.25（2026-11-02）
  • magpie — yetone/magpie，版本基准 v0.1.2829（2026-11-03）
• 资料来源：两者的官方中文 README、官方中文用户手册 / 文档站、英文完整参考文档、官方使用攻略、CHANGELOG。
• 写作原则：
  • 只写官方文档能支撑的事实；
  • 官方文档没写的，明确标注「文档未说明」，不臆测；
  • 两者都迭代很快，具体菜单文案和参数以应用内实际显示为准。
• 重要提醒：本文涉及「用订阅当供应商」「OAuth 反向代理」等能力，两者都有，也都可能违反厂商服务条款。对比不代表推荐，风险请自行评估。

目录

• 0. 30 秒结论
• 1. 本质差异：一个是配置管理器，一个是网关
• 2. 总览对照表
• 3. 逐维度详解
  • 3.1 技术形态与部署
  • 3.2 支持的 Agent 数量
  • 3.3 供应商与预设
  • 3.4 配置写入方式
  • 3.5 请求路径：直连 vs 必经网关
  • 3.6 路由能力
  • 3.7 故障转移
  • 3.8 会话粘性
  • 3.9 多模型并存（聚合 vs 路由组）
  • 3.10 协议转换与模型映射
  • 3.11 订阅与账号管理
  • 3.12 MCP 管理
  • 3.13 Skills 与提示词
  • 3.14 会话管理
  • 3.15 用量与成本
  • 3.16 额度与余额
  • 3.17 隐私与脱敏
  • 3.18 遥测
  • 3.19 多机共享与远程
  • 3.20 命令行与自动化
  • 3.21 插件与扩展
  • 3.22 数据、备份与同步
  • 3.23 安全模型
  • 3.24 许可与社区
• 4. 场景选型指南
• 5. 组合使用：两者能一起用吗
• 6. 从一方迁移到另一方
• 7. 各自的限制与坑
• 8. 版本与时效说明
• 附录 A：端口与路径对照
• 附录 B：术语对照
• 附录 C：命令与入口对照

0. 30 秒结论

一句话取舍：

• CC Switch = 「我要改配置，顺便有个路由」 → 轻、可退出、桌面优先。
• magpie = 「我要一个网关，配置顺手就改了」 → 重、常驻、策略强、可上服务器。

1. 本质差异：一个是配置管理器，一个是网关

1.1 CC Switch 的心智模型

你 → CC Switch 界面 → 改写各工具的配置文件 → 工具自己直连厂商

• 主产品是「配置文件的可视化管理」；
• 切换供应商 = 改写 settings.json / config.toml / .env 里的关键字段；
• 路由是可选功能：只有你想跨协议或要故障转移时，才进入路由模式；
• 直连模式下，CC Switch 可以退出，工具照常工作（配置已经写进去了）。

1.2 magpie 的心智模型

你 → magpie 界面 → 改写各工具的配置指向 127.0.0.1:3425 → 网关 → 厂商

• 主产品是「本地网关」；
• 给 Agent 选模型 = 把 Agent 的 base URL 指向网关 + 写入 provider/model；
• 所有请求必经网关（这是设计前提，不是可选项）；
• magpie 必须一直运行（或装成后台服务 magpie daemon install），否则所有 Agent 不可用。

1.3 这个差异带来的连锁效应

这条差异决定了一切：如果你只想要「一键换 Key」，CC Switch 更轻；如果你想要「统一入口 + 强策略」，magpie 更合适。

2. 总览对照表

2.1 基本盘

2.2 能力矩阵

图例：✅ 完整支持　🟡 部分支持 / 有条件　❌ 不支持

3. 逐维度详解

3.1 技术形态与部署

CC Switch

magpie

结论：服务器 / NAS / SSH / 纯终端场景，magpie 是唯一选择；CC Switch 必须依赖图形桌面。

3.2 支持的 Agent 数量

CC Switch：12 个，深度适配

Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、Pi、MiniMax Code、Kimi Code、Oh My Pi。

特点：

• 每个工具都有专属的配置写入逻辑（知道每个工具该改哪些键）；
• 有功能矩阵（哪些工具支持 MCP / Skills / 提示词 / 会话 / 用量）；
• 切换式（5 个）与共存式（7 个）区分明确；
• 只显示已安装或配置过的工具。

magpie：70+ 个，广度覆盖

Claude Code、Claude Desktop、Codex、Gemini CLI、Antigravity CLI、OpenCode、OpenChamber、MiMo Code、DevEco Code、Pi、oh-my-pi、StepCode、MothX、PenguinHarness、Aside、OmO、Prime Agent、Goose、Cursor CLI、Zed、VS Code Chat、VSCodium Chat、JetBrains Air、Copilot CLI、Crush、DeepSeekRuntime、Command Code、fx、Devin、Hermes Agent、Kimi Code、jcode、Qwen Code、Muse Code、Empryo、MiniMax Code、Droid、Cline、Qoder、Grok Build、ZCode、WorkBuddy、CodeBuddy、Raycast、Kiro Crew、T3 Code、OpenHanako、AtomCode、Snow CLI、Alma、OpenClaw、AstrBot、QwenPaw……

特点：

• 官方参考文档有逐 Agent 的文件 / 字段对照表；
• 支持任意能填 base URL 的工具（直接指向网关）；
• 只显示本机已装的 Agent；
• 有些 Agent 需要重启才生效（文档逐条说明）。

结论：你用的工具冷门 → magpie；你只用主流 5 个 → CC Switch 适配更深（尤其是 Claude Desktop、Codex 的特殊选项）。

3.3 供应商与预设

CC Switch 的独特之处：

• 统一供应商：一份配置同步到 Claude Code / Codex / Gemini CLI，改一处全同步；
• 端点测速面板：一个供应商配多个端点，测完选最快的；
• 预设快照提醒：文档明确警告「旧卡不会自动升级」。

magpie 的独特之处：

• 模型别名：把 grok-4.6@500k 这种怪名字映射成 grok-4.6，且能参与自动组；
• 自动组：两家供应商有同名模型时，自动合并成 auto/<模型> 路由组；
• provider 级 header / User-Agent 覆盖：某些编程套餐只认特定 UA。

3.4 配置写入方式

都只改「关键字段」

两者都会保留插件、Hook、权限、MCP、注释和排版。

备份策略

3.5 请求路径：直连 vs 必经网关

这是最影响日常体验的差异。

CC Switch

直连模式：  Claude Code ──────────────────────► api.anthropic.com
路由模式：  Claude Code ──► 127.0.0.1:15721 ──► 供应商
聚合模式：  Claude Code ──► 127.0.0.1:15721 ──► 按模型分发到不同供应商

• 默认是直连；
• 只有点了「开始路由」或「切换到聚合模式」才走本地；
• 路由模式下配置文件写 PROXY_MANAGED 占位符；
• 退出 CC Switch 会自动写回直连配置。

magpie

始终：      Claude Code ──► 127.0.0.1:3425 ──► 供应商

• 没有「直连模式」（对 Agent 而言）；
• Agent 配置永远指向网关；
• 网关退出 = Agent 全部不可用；
• 用 magpie daemon install 解决常驻问题。

实际影响

3.6 路由能力

CC Switch：简单直接

• 四种连接模式：直连 / 路由 / 聚合（+ Claude Desktop 的模型映射）；
• 上游格式转换：Anthropic ↔ OpenAI Chat ↔ OpenAI Responses ↔ Gemini Native；
• 整流器：自动修复部分上游不兼容请求（如 Thinking 签名、不支持图片时降级）；
• 路由设置：按应用独立配置超时、重试、熔断。

没有的能力：

• 按意图选模型；
• 按文件夹选模型；
• 按时段选模型；
• 按成本选模型；
• 按权重分配；
• 按周额度配速。

magpie：策略极其丰富

规则（rules）还能按条件分流：

还有：

• 嵌套路由组（最多 8 层，禁止循环）；
• 意图路由（小模型判断，超时可配）；
• 自动组（同名模型自动合并）。

结论：路由策略 magpie 完胜。CC Switch 的路由是「够用」，magpie 的路由是「专业」。

3.7 故障转移

CC Switch：队列 + 熔断器

magpie：路由组 + 账号级切换

结论：CC Switch 的熔断参数更可调（适合精细运维）；magpie 的切换策略更多样（适合多账号/多订阅）。

3.8 会话粘性

如果你有多账号且关心「一个对话别在账号间跳来跳去导致缓存失效」，magpie 的 strict 很有用。

3.9 多模型并存（聚合 vs 路由组）

这是两者最容易被混淆的地方。

CC Switch 聚合模式

效果：Claude Code / Codex 的 /model 列表里同时出现多家供应商的模型。

/model
├── gpt-5.6-sol          （默认供应商）
├── ccs-deepseek-v4-pro  （DeepSeek）
├── ccs-kimi-k3          （Kimi）
└── ccs-grok-4.6         （Grok）

• 选哪个模型，请求就发给哪一家；
• 不需要回 CC Switch 切换；
• 非默认供应商的模型带 ccs- 前缀；
• 不做故障转移；
• 只支持 Claude Code 和 Codex；
• Claude Code 需要 2.1.243+。

magpie 路由组

效果：Agent 把一个组当作一个模型来选。

Agent 选择：group/daily-coding
       ↓
magpie 网关按策略在组内成员之间分发

• Agent 看到的是 group/<id>，看不到组内各成员；
• 按 smart / order / weight 等策略分发；
• 支持故障转移；
• 支持嵌套；
• 所有 Agent 都能用（不限 Claude Code / Codex）。

关键区别

一句话：聚合是「把选择权交给你」，路由组是「把选择权交给策略」。

3.10 协议转换与模型映射

CC Switch 的模型映射 UI 更直观（表格填写）；magpie 的别名机制更适合批量（一条命令改一批）。

3.11 订阅与账号管理

各自的特色

CC Switch：

• 「切卡即切号」：给每张官方卡绑一个 Claude 账号，点卡片就换号，正在运行的会话不用重启；
• 「一个窗口一个号」：从卡片「打开终端」，该终端固定用这个账号（本质是 CLAUDE_CONFIG_DIR）；
• 合规对照表：逐条对照 Anthropic 官方要求，说明为什么这套做法合规；
• 限制：不支持 Claude Desktop、不支持 WSL。

magpie：

• 多账号自动切换：不需要手动切，网关按策略分配；
• 每日预热：在选定时间启动 Claude / ChatGPT 账号的 5 小时窗口；
• magpie accounts switch claude next：命令行切到下一个还有额度的账号；
• 限制：Claude 订阅请求通过本机 Claude Code 运行，所以要保留 Claude Code。

3.12 MCP 管理

CC Switch：矩阵式

        Claude  Codex  Gemini  Grok  OpenCode  Hermes  Pi  MiniMax
fetch      ✅     ✅     ✅     ✅      ✅       ✅    ✅    ✅
time       ✅     ❌     ✅     ✅      ✅       ✅    ✅    ❌
memory     ✅     ✅     ❌     ✅      ✅       ✅    ✅    ✅

• 每行一个 MCP，每列一个应用，开关控制同步；
• 支持从应用导入已有配置；
• 支持模板（fetch / time / memory / sequential-thinking / context7）；
• 支持粘贴配置自动识别格式；
• 支持 Deep Link 导入；
• 连通性检查（v4.0.25 新增，30 秒超时，最多 3 并发）。

magpie：资料库 + MCP router

• 资料库：MCP 服务器只写一次，magpie 按每个 Agent 的格式写进它的文件；
• MCP router：把资料库里的多个 MCP 服务器合成一个 magpie 入口（/mcp/magpie/hub），Agent 只配一个；
• 每个工具名格式为 <server>__<tool>；
• 命令在首次调用时启动，10 分钟无调用后结束。

对比

3.13 Skills 与提示词

CC Switch 的 Skills 生态更成熟（直接搜 skills.sh、检查更新、一键全部更新）；magpie 的资料库更强调「一处定义、多处写入」。

3.14 会话管理

CC Switch：阅读器级

• 列表：按时间 / 按项目分组，显示标题、活跃时间、最后一条消息摘要；
• 搜索：标题、项目目录、首末消息、会话 ID；
• 详情：正文、思考、工具调用、工具结果、图片分开呈现；
• 摘要：每一轮折叠成一行（多少步、改了几个文件、几处失败），失败步骤标红；
• 目录：右侧对话目录，可跳转；
• 查找：会话内查找；
• 导出：复制整段为 Markdown，或导出文件；
• 恢复：macOS 一键在终端恢复；其他平台复制命令；
• 删除：批量删除（不可撤销）。

magpie：轻量级

• 会话列表：每个 Agent 对话的花费和标题；
• 一键重开：在终端里重新打开；
• 上下文分析：每个请求的上下文窗口用了多满、多少来自缓存、被什么占着（这个 CC Switch 没有）。

CC Switch 是「会话阅读器」，magpie 是「会话成本视图」。

3.15 用量与成本

magpie 的「上下文分析」是独有功能：能告诉你提示词里系统提示词、工具定义、指令文件、文件读取各占多少，还有百分制得分和「MCP 偏重」这类标签。

3.16 额度与余额

CC Switch

• 卡片底部显示「5 小时剩余 62%」+ 重置倒计时；
• 剩余不到 10% 时文字加深加粗；
• 支持自定义 JS 脚本查询（{{baseUrl}}、{{apiKey}} 等变量）；
• 预设模板：通用模板、NewAPI、Sub2API。

magpie

• magpie quota 查看每个套餐剩余；
• 额度卡片：5 小时 / 周 / 月窗口 + 重置时间；
• 每日预热：在选定时间启动 Claude / ChatGPT 的 5 小时窗口；
• 额度刷新：默认自动，可设「仅手动」；
• 共享 magpie 的额度：本机显示共享端的最近读取结果。

对比

3.17 隐私与脱敏

这是 magpie 的独有护城河。

magpie 本地脱敏

• 默认关闭，在 设置 → 隐私 打开；
• 请求离开电脑前，把 API Key、私钥、Token、密码、邮箱、身份证、银行卡等换成 {{API_KEY_k3v9x2mq}} 占位符；
• 回复里的占位符再换回原值（流式文本和工具调用参数都算）；
• 同一个值每次占位符相同，所以对话上下文、提示词缓存、thinking 签名都不受影响；
• 原值只在内存，磁盘记录只留类型、长度和开头几个字符；
• 失败即不发送（返回 503），绝不退回成不脱敏；
• 可选用本地模型查找规则找不到的人名、地址（AstrLink Guard 约 39 MB / Privacy Filter 约 1.6 GB）；
• 可按 provider 跳过（本地 Ollama、LM Studio 等）。

不能遮的：思考内容（厂商签名）、ID 和工具定义、图片和文件数据。

CC Switch

没有脱敏功能。 官方文档未提供任何「请求内容脱敏」能力。

对比

如果你经常让 Agent 读 .env、配置文件、带 token 的日志，magpie 的脱敏是刚需。

3.18 遥测

⚠️ 注意：CC Switch 官方文档未说明遥测情况，不能据此断定「没有遥测」。关注隐私的话，建议自行检查源码或抓包。magpie 的遥测行为是公开、可关、有文档的。

3.19 多机共享与远程

CC Switch：配置同步，不共享网关

• 云同步：WebDAV / S3 兼容存储，同步数据库；
• 每台机器独立运行，各自连各自的供应商；
• 没有「把另一台电脑当网关」的能力。

magpie：真正的远程网关

• 局域网共享：一台机器开启共享，生成网关密钥；
• 远程 magpie：其他电脑把它添加为 provider（office/…）；
• 共享端保存供应商、订阅、密钥、路由组；
• 本机仍运行 magpie，只借用模型；
• Docker + NAS：在服务器上跑一个 magpie，给全屋设备供模型。

对比

3.20 命令行与自动化

CC Switch

• 官方无 CLI；
• 社区版 CC Switch CLI 提供 TUI + 命令行；
• 支持 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw、Hermes、Pi；
• 与桌面版共用 ~/.cc-switch。

magpie

完整 CLI：

magpie ls                              # 列出每个 Agent 及设置
magpie providers                       # 你的 provider
magpie models                          # 所有可选模型
magpie claude deepseek/deepseek-v4-pro # 设置模型
magpie save work && magpie use work    # 方案
magpie quota                           # 额度
magpie usage 7d                        # 用量
magpie group add ...                   # 路由组
magpie daemon install                  # 后台服务
magpie backup / restore                # 备份恢复
magpie tool generate_image "..."       # 生图
magpie tui / web / serve / tray        # 多种运行方式

对比

3.21 插件与扩展

CC Switch

• 没有插件系统；
• 只有用量查询脚本（JavaScript，自定义 API 查询逻辑）。

magpie

• 插件 = provider 插件：兼容 OpenCode 的 provider 插件，也支持 pi 扩展包；
• 插件负责登录、列模型、发请求；
• 运行在 Bun 上（首次使用时自动下载）；
• 网关中间件：onRequest / onEvent / onResponse 钩子，可改写或拒绝请求；
• 现成中间件：param-override、model-map、system-prompt、word-guard、think-tags；
• 社区插件库：magpie-community/plugins。

中间件示例：

export function onRequest(body, ctx) {
  if (body.model === "fast") return { ...body, model: "deepseek/deepseek-chat" };
}

对比

3.22 数据、备份与同步

magpie 的备份是加密的，CC Switch 的 SQL 备份是明文的（含 API Key）。备份文件请妥善保管。

3.23 安全模型

CC Switch

magpie

如果要暴露到局域网，magpie 的安全设计完整得多（密钥 + 限额 + IP 白名单 + TLS）。CC Switch 的本地路由没有认证机制，只适合本机使用。

3.24 许可与社区

magpie 不接受 PR 是一个重要的社区差异——想要功能只能去 Discord 提。

4. 场景选型指南

4.1 决策树

你主要想解决什么？
│
├─ 只想换 API Key / 换中转站，越简单越好
│   └─► CC Switch
│
├─ 想在 Claude Code 的 /model 里同时看到 GPT、Kimi、DeepSeek
│   └─► CC Switch 聚合模式
│
├─ 想让 Claude Code 用 GPT（或 Codex 用 Claude）
│   ├─ 想要图文教程一步步来 ──► CC Switch
│   └─ 想要命令行 + 策略路由 ──► magpie
│
├─ 有 3 个以上 Claude/ChatGPT 账号，想自动分配
│   └─► magpie（路由组 + 账号切换）
│
├─ 想按「这个问题简单还是复杂」自动选模型
│   └─► magpie（意图路由）
│
├─ 想让提示词里的 .env 内容不发给厂商
│   └─► magpie（本地脱敏）
│
├─ 想在 NAS 上跑一个网关，全家设备共用
│   └─► magpie（Docker + 远程 magpie）
│
├─ 主要用终端，讨厌 GUI
│   └─► magpie（TUI / CLI）
│
├─ 想管理 MCP / Skills / 提示词 / 看会话记录
│   └─► CC Switch
│
├─ 想给多个 Claude 订阅「切卡即切号」
│   └─► CC Switch
│
└─ 只想用一个 Agent + 一个官方订阅
    └─► 两者都不需要

4.2 典型用户画像

5. 组合使用：两者能一起用吗

技术上可以，但需要小心。

5.1 为什么会想组合

• CC Switch 的 MCP / Skills / 会话管理更好用；
• magpie 的路由策略 / 脱敏 / 多账号更强；
• 有人想「CC Switch 管配置，magpie 管转发」。

5.2 冲突点

5.3 可行的组合方式

方式 A：CC Switch 只管扩展，magpie 管模型

1. 用 magpie 配置所有 Agent 的模型（指向 127.0.0.1:3425）；
2. 用 CC Switch 管理 MCP / Skills / 提示词，但不要在 CC Switch 里切换供应商。

⚠️ 风险：CC Switch 打开供应商页时可能会重新写入配置。建议在 CC Switch 里把该 Agent 从侧栏隐藏。

方式 B：CC Switch 管 Claude Code，magpie 管其他 Agent

• 各管各的工具，互不干扰；
• 适合「Claude Code 用 CC Switch 的聚合，Codex 用 magpie 的路由组」。

方式 C：串联

Claude Code → CC Switch 路由(15721) → magpie(3425) → 供应商

• 理论上可行（CC Switch 的上游填 http://127.0.0.1:3425）；
• 不推荐：两层转换、两层故障转移、排障困难。

5.4 官方态度

• CC Switch 文档：未提及与 magpie 共存；
• magpie 文档：提到可以导入 CC Switch 的配置（「导入能读取你在 CC Switch、Claude Code、Codex 和 Alma 里配置的 provider」）。

这说明 magpie 把 CC Switch 视为「迁移来源」，而不是共存对象。

5.5 建议

选一个作为主，另一个卸载或隐藏。 同时用两个「配置管理者」迟早会互相覆盖，排障成本远大于收益。

6. 从一方迁移到另一方

6.1 CC Switch → magpie

magpie 有官方导入：

1. 打开 magpie → 供应商 → 导入…；
2. 它会读取 CC Switch 配置的 provider；
3. 勾选要导入的，确认；
4. 之后在 Agent 页重新给每个工具选模型；
5. 验证：magpie ls + magpie provider test <id>。

注意：

• 导入的是一份拷贝，之后两边不再同步；
• 订阅登录需要重新登录（导入不含 OAuth 凭据）；
• CC Switch 写入的配置会被 magpie 覆盖——建议先在 CC Switch 里把 Agent 恢复成官方配置。

6.2 magpie → CC Switch

CC Switch 没有官方的 magpie 导入。

手动步骤：

1. 在 magpie 里运行 magpie providers，导出 provider 列表；
2. 在 CC Switch 里逐个添加供应商（预设或自定义）；
3. 每个 Agent 重新选模型；
4. 在 magpie 里运行 magpie <agent> default，把配置恢复原样；
5. 再让 CC Switch 接管。

或者：CC Switch 支持深度链接导入，可以自己生成 ccswitch:// 链接批量添加。

6.3 迁移检查清单

• 已记录所有 provider 的名称、base URL、Key、模型 ID
• 已记录每个 Agent 当前用的模型
• 已记录路由组 / 聚合的成员和策略
• 已备份原工具的配置文件
• 已导出旧工具的配置（magpie backup / CC Switch SQL 导出）
• 迁移后逐个 Agent 验证能正常对话
• 迁移后卸载或停用旧工具，避免互相覆盖

7. 各自的限制与坑

7.1 CC Switch 的已知限制

7.2 magpie 的已知限制

7.3 两者共同的坑

8. 版本与时效说明

建议：动手前先看最新 Release Notes。两家的界面文案和菜单层级都可能在两个版本之间变化。

附录 A：端口与路径对照

A.1 端口

A.2 数据目录

A.3 各工具配置文件（两者都改这些）

附录 B：术语对照

附录 C：命令与入口对照

最后总结：

CC Switch 是「配置的遥控器」——它让你不用手改 JSON，顺便提供了一条够用的本地路由。轻、可退出、桌面优先、扩展管理强。

magpie 是「模型的交换机」——所有请求必经它，配置只是它顺手做的事。重、常驻、策略强、能上服务器、有脱敏。

如果你只想要「换个 Key 就完事」，选 CC Switch；
如果你想要「一个能思考、能分配、能保护隐私的模型入口」，选 magpie。

不要两个一起用——两个配置管理者迟早会互相覆盖。