卸载 cc-switch 之后,我把模型调度全交给了 magpie

写代码用上各路 Coding CLI Agent 以后，最让人心烦的是倒腾各家模型渠道的额度和配置文件。

起初我和很多朋友一样，装的是 CC Switch。它能管 Claude Code、Codex 等十个工具，能给每个工具选一个当前的模型供应商，同一时间只有一个生效，叫模型切换器比较合适。

我用了一段时间，卡住我的是四件事。

第一，同一个工具里没法按任务的轻重分流供应商。

第二，我手上有几个订阅，Claude、ChatGPT、Copilot 各一份，它们只能在自家客户端里用，别的 Agent 用不上。

第三，几个编程套餐快到重置日时还剩不少额度，我得自己记着去切。

第四，有些模型通过其内置网关兼容性不好，例如 Copilot 的模型。

上个月我把 CC Switch 卸了，所有模型调用接到 magpie 上。它在本地起一个网关，把各家 Agent 的接入点接过来。

现在我机器上挂着十几个模型来源，几套编程客户端同时跑，没再手改过一次环境变量，下面是我实际跑通的一套用法。

它到底做了什么

magpie 在本机起一个服务对接你手头的模型资源，同时提供 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini 和 Typesafe System one 五种接口，彼此之间互相转换，兼容流式输出、工具调用和推理内容。

模型资源分三类。

一类是 API Key，智谱、Kimi、DeepSeek、MiniMax、通义千问这些预设只要填 Key，OpenRouter、硅基流动这类中转站也一样。

一类是订阅，你在 Claude Code、Codex 里登录过的账号，magpie 会读出来当成供应商给其他 Agent 用，GitHub Copilot、Gemini、Grok 也能登录进来。

还有一类是本地模型，Ollama 和 LM Studio 都在预设里。

接管客户端的方式很克制。magpie 只改 Agent 配置里该改的那一个键，注释、顺序和格式原样保留。

它支持的 Agent 有五十多个，Claude Code、Codex、Gemini CLI、OpenCode、Pi、Qwen Code、VS Code Chat 都在里面，界面上只显示你电脑里装了的那些。

想不接某个 Agent 也只要一行，magpie claude default就把 Claude Code 恢复到接入前的样子，其他 Agent 同理，在窗口里直接关闭更直接。

安装和接入

macOS 和 Linux 一条命令装好，Windows 到 usemagpie.ai 下载安装包。

curl-fsSL https://usemagpie.ai/install.sh |sh

装完有菜单栏应用和窗口，日常加供应商、给 Agent 选模型、看路由，不用输命令，点几下就行。

服务器上没有桌面，可以用 magpie tui开终端界面，或者用 magpie web在浏览器里开同一套界面，网关就用 magpie serve启动。

先看看机器上装了哪些 Agent，各自用的什么模型。

magpie ls

它会把每个 Agent 当前的模型、推理档位和配置文件路径列出来。

然后加模型供应商。按量付费的 Key 直接加，比如 DeepSeek。

magpie provider add deepseek sk-…

编程套餐要单独说一下。GLM Coding Plan、Kimi Code、MiniMax Coding Plan 这类编程套餐，用的是专门的接口地址，额度按固定的时间窗口刷新。

Key 加对了，magpie 能从厂商那里读到每个窗口用了多少、什么时候重置，后面按额度路由靠的就是这份数据。

magpie provider add zhipu 你的CodingPlanKey plan=coding id=glm-planmagpie provider add kimi-code-cn 你的KimiCodeKeymagpie provider add minimax-cn sk-cp-… id=minimax-planmagpie models          # 汇总后的模型清单，名字都是 provider/model

三家的加法各不一样。智谱的 Coding Plan 和按量付费共用 zhipu这个预设，plan=coding让它走套餐的接口，套餐 Key 发到按量接口会被回一个「余额不足」。

Kimi Code 有自己的预设 kimi-code-cn，模型名是 k3、kimi-for-coding这些，和 moonshot-cn下面的不一样。

MiniMax 的套餐 Key 以 sk-cp-开头，加在 minimax-cn预设下就会被认出来。

id=给供应商起个名字，同一家既有按量 Key 又有套餐时用来区分，模型名前缀也跟着变成 glm-plan/…、minimax-plan/…。

原来在 CC Switch 里配过的供应商不用重抄。打开 App 的 Providers 页，magpie 会自动找到 CC Switch、Claude Code、Codex 里的本地配置，勾选后导入。

订阅类账号用登录命令。

magpie accounts add copilot      # GitHub Copilotmagpie accounts add claude       # 再登录一个 Claude 订阅magpie accounts                  # 每个订阅的账号、额度和重置时间

Cursor、Kiro、Zed 这些订阅已经从 magpie 内置挪到了社区插件，在 App 的插件页装对应插件后登录。magpie 的维护者把它们挪出去，原因是直接调用这些订阅可能违反厂商条款，用之前自己掂量一下，封号别怪我没提醒。

给 Agent 指定模型是一行命令，比如 magpie claude deepseek/deepseek-v4-pro。我更常用的是下面的路由组。

核心在路由组和组内策略

把各家 Key 收在一处转发，很多本地网关都能做，我日常用得最多的是路由组。路由组是一组模型，Agent 把它当一个模型来选，名字是 group/<id>。

编程任务对模型的要求是分层的。读一段日志、改个变量名、做一次只读搜索，用不着顶配模型。跨几十个文件的重构或者并发死锁，中档模型常常绕圈子，还会写出隐蔽的bug。

我按这个分了三个档位组。

• code-fast
  接轻任务，放快、额度充裕的型号，比如 GLM 套餐里的 glm-5.3-flash、MiniMax 套餐里的 highspeed 系列、Kimi Code 的 kimi-for-coding-highspeed。
• code-main
  应付日常大部分修改和小功能，放各家的主力中档，比如 GLM 套餐里的 glm-5.3、Kimi Code 的 kimi-for-coding、MiniMax 套餐里的 MiniMax-M3，再垫一个按量付费的 deepseek/deepseek-v4-pro。
• code-max
  留给最难的任务，放 Kimi Code 里的 k3这类旗舰，有 Claude 订阅的话 Opus 5.5 也放这里。

分好档之后，组里有好几个模型，请求进来先给谁，由组的 routing决定。

magpie 有五种策略：

smart、usage、pace都看账号的额度窗口。一个账号的某个窗口用到 90%，新对话就排到别人后面，到 98% 再往后排，已经在它上面的对话会留到 98% 才挪走。

按量付费的 Key 没有额度窗口，在 usage和 pace下只能按顺序或者最近发过多少 token 来排。GLM Coding Plan、Kimi Code、MiniMax Coding Plan 这些套餐和订阅账号有额度窗口。

我的配法是这样：

• code-fast
  用 usage，轻请求量大，谁的窗口用得少就倒给谁。这里我只放套餐里的模型。按量 Key 在 usage下按用了 0% 算，放进来会一直排在套餐前面，套餐的额度反倒用不上。
• code-main
  用 pace，三个套餐的额度都按窗口刷新，没用完的一到重置就作废，pace让快要重置的那个先上。DeepSeek 按量付费，没有窗口，pace把它排在套餐后面，套餐都满了才轮到它，正好兜底。
• code-max
  用 order，难做的任务就要排在第一的那个模型，它答不了才往下走，不为了均摊额度把重构等高难度任务交给便宜模型。

magpie group add code-fast models=glm-plan/glm-5.3-flash:high,minimax-plan/MiniMax-M2.7-highspeed,kimi-code-cn/kimi-for-coding-highspeed routing=usagemagpie group add code-main models=glm-plan/glm-5.3:high,kimi-code-cn/kimi-for-coding,minimax-plan/MiniMax-M3,deepseek/deepseek-v4-pro:high routing=pacemagpie group add code-max  models=kimi-code-cn/k3:high,deepseek/deepseek-v4-pro:max routing=ordermagpie groups

成员后面的 :high、:max是推理档位，一个模型能选哪些档，用magpie models查看。

magpie 不认识的模型名会直接拒绝建组，填之前先查清单。已经建好的组用 magpie group set code-fast routing=usage改策略，models+=追加成员，models-=去掉成员。

另外，一个对话被某个账号答过以后，只要厂商那边的提示词缓存还值得保留，后续请求就留在这个账号上，这由组的 stays控制，默认 auto，一般不用动。

用原生意图规则自动分档

档位分好了，总不能每发一句话就手动换一次模型名。magpie 自带规则引擎，可以在三个档位组上面再套一个总入口组，嵌套挂上前面三个组。

magpie group add code-auto models=group/code-main,group/code-max,group/code-fast routing=order

成员顺序有讲究。组里的规则一条都没命中时，这一轮按组的平常顺序走，所以默认档 code-main要排第一。

然后给这个组配一个判断意图的模型，再写两条规则。判断模型选小而快、不带推理的，我用的是 TypeSafe 的 Jev，先 magpie provider add typesafe <key>加进来。

magpie group rule add code-auto use=group/code-fast intent="a question, an explanation, reading logs, running a command, a one-line or mechanical change, a read-only code search"classifier=typesafe/jev-latestmagpie group rule add code-auto use=group/code-max intent="a change across several files, a bug whose cause is unknown, concurrency, performance or security issues, an architecture decision, a long multi-step plan"magpie group rule code-auto     # 看规则列表和判断模型

意图用中文写也行。之后在 Agent 里把模型设成这个组。

magpie claude group/code-automagpie codex group/code-auto

我对着官方文档和源码看了它每一轮具体做了什么。你发消息的那一刻，magpie 把你最新一条消息的文字和带编号的意图列表发给判断模型，同一会话上一轮被判成哪一类也会一起告诉它，只是接着上一轮的短句沿用上一类。

判断模型回一个数字，第一条命中的规则把对应的组排到最前面，其他成员排在后面做失败转移。

之后 Agent 调工具的几十个请求都留在这个组上，等你下次发言再重新判断，缓存不会在一轮中间被打断。

subagent 的轮次按它自己的消息单独判断。判断模型 8 秒没回答或者答不出来，这一轮沿用上一轮的类别，没有上一轮就按组的平常顺序走，请求不会失败。

路由页会把判断模型说了什么、这一轮去了哪里逐条写出来，规则不准的时候先看这里。

还有一条我觉得很实用的规则。Claude Code、Codex 压缩上下文的那一步，可以单独交给便宜模型写摘要。

magpie group rule add code-auto use=group/code-fast compact

按客户端、目录和时间分流

规则还能按请求从哪来、在哪个目录、什么时间来分流。

我在台式机上跑着一个 magpie，挂着 Claude 订阅。笔记本上的 magpie 把它加成远程 magpie，就能用它的供应商和路由组。

magpie provider add remote-magpie sk-magpie-… url=http://192.168.1.20:3425 id=office

远程那台的 Opus 我想放进笔记本的 code-max，给 Codex 和 Pi 啃硬骨头。笔记本上的 Claude Code 自己已经登录着同一个订阅，我不希望它的请求再绕到台式机上去抢额度。这时不用把模型移出组，加一条暂停规则就行。

magpie group set code-max models=office/claude/claude-opus-5-5,kimi-code-cn/k3:high,deepseek/deepseek-v4-pro:maxmagpie group rule add code-max pause=office/claude/claude-opus-5-5 agents=claude

第一行把 Opus 排到 code-max的第一位，暂停规则生效时，来自 Claude Code 的请求在这个组里完全看不到它，从 k3开始用，别的成员失败了也不会转给它。来自 Codex 或 Pi 的请求照常先用 Opus。

同样的写法能按目录隔离资源。下面第一条让保密目录里的请求碰不到台式机上的 Opus，第二条让核心仓库里的活一律先走性能档。

magpie group rule add code-max pause=office/claude/claude-opus-5-5 folders=~/work/secretmagpie group rule add code-auto use=group/code-max folders=~/work/core at=1

规则从上往下看，第一条命中的生效，at=1把目录规则放到意图规则前面，核心仓库里的任务连判断模型都不用问。

目录是 Agent 在请求里告诉模型的工作目录，Claude Code、Codex、OpenCode、Pi 都会带。还有 time=和 days=，可以在某家的高峰价时段把请求挪到别家。

MCP、技能和指令写一次

多个 Agent 一起用，另一件烦心事是每个 Agent 各有一份 MCP 配置、一套技能目录和一个指令文件，格式还都不一样。

magpie 的资料库把它们统一管理。你写一次，它按各个 Agent 的格式分别写进去，删的时候只删自己写的部分。

magpie library                                   # 每个 Agent 拿到了哪些指令、MCP 和技能magpie library mcp add github npx -y @modelcontextprotocol/server-github agents=claude,codex,pimagpie library instructions set ~/notes/AGENTS.mdmagpie library instructions agents claude,codex,pi   # 指令默认不发给任何 Agent，要指定magpie library sync# 新装了 Agent，或者手改过之后重新写一遍

技能在 App 的资料库页从 GitHub 装，之后 magpie library skill update拉新版本，在资料库里改过的技能批量更新时会原样留着。

插件和中间件

magpie 的插件跑在 Bun 上，第一次用时自动下载。一类插件是供应商，登录、列模型、发请求都由它负责，OpenCode 的登录插件和 pi 的扩展包都能直接装。

另一类是网关中间件，一段 JavaScript 能看到每个 Agent 发出和收到的内容，可以改写或拒绝请求。

社区现成的有给某些模型统一加系统提示词的 system-prompt，去掉回复里 <think>标签的 think-tags，模型改名的 model-map，这些插件都可以挑着用。

magpie plugin add pi-antigravitymagpie plugin add @magpie-community/middleware-model-mapmagpie plugin options model-map '{"mapping": {"fast": "deepseek/deepseek-flash"}}'

排查和对账

模型资源收拢到一处以后，看额度和对账也简单了。

magpie quota

每个订阅、套餐和按量账户各占一行。前面加的 GLM、Kimi Code、MiniMax 套餐在这里能看到 5 小时窗口用了百分之多少、7 天窗口什么时候重置，按量账户显示余额，一张表看完。

怀疑某次请求没落到预期的模型上，就导出当天的明细。

magpie usage --csv today

每一行是一次请求。Agent 要的模型和实际回答的模型都在，还有供应商和主机、各类 token 数、首字耗时和总耗时，以及按官方价折算的美元花费。

App 的用量页还能按会话看花费，按账号和上游 Key 出账单，不用在四五家控制台之间来回登录。

意图规则看不到的东西

上面这套我用了一阵，分档大体是对的，也碰到过几次判不准。翻路由记录看原因，都出在判断模型看不到上一轮的回答。

最典型的是「按这个思路改」。前面说过，接着上一轮的话会沿用上一轮的类别。可上一轮我问的是「这个问题怎么改比较好」，被判成了轻任务；模型回了一个要改好几个文件的方案，判断模型看不到这份回答，「按这个思路改」也就跟着上一轮判成了轻任务。

还有几种情况它同样无从知道，比如我开着计划模式在做设计，或者上一轮的工具调用连着失败了一半。我说一句「上一轮做得不对」，它也只按这句话本身归类，不会因此升档。

另外它没有降档缓冲，前后两轮在 code-fast和 code-main之间来回切，提示词缓存就很难命中，白付钱了。

上一轮回答其实就在请求体里，magpie 判档时没有用它；计划模式、subagent 类型这些则只在 Agent 自己手里。

我为此写了鹊桥 Magpie Bridge（命令 mbridge），在 magpie 旁边跑一个小进程，Claude Code、Codex 和 Pi 各装一个插件，把这些上下文交给它判档。

它补上的东西有这些：

• 判档时带上一轮回答，「按这个思路改」能判到该去的档。
• 计划模式直接走最高档，Explore这类只读subagent 固定走最快档。
• 我说上一轮不对，或者上一轮工具失败过半，下一轮自动升一档并保持两轮。
• 升档立即生效，降档要等距上次请求满 300 秒或者连续两次判低，给缓存留时间。
• 可选的轮末复核，判这一轮到底解决没有，没解决就让下一轮升档。
• 所有分数记日志，mbridge router calibrate用你自己的流量算建议阈值，还能开线上 A/B 看到底省了多少。

鹊桥不碰组内调度。它在 magpie 里建自己的三个档位组 mb-fast、mb-balanced、mb-perf和一个入口组 mbridge，每一轮只决定这一轮走哪个档位组，档位组里面先用哪个账号还是 magpie 说了算。

所以上面调好的 code-*组可以原样接上，把鹊桥的三个档位组各指向一个就行，usage、pace、order照常生效。

curl-fsSL https://raw.githubusercontent.com/weiping/magpie-bridge/main/install.sh |shmbridge router init --preset cn --groups-only      # 建 mb-* 四个组，写 ~/.config/magpie-bridge/router.jsonmagpie group set mb-fast     models=group/code-fastmagpie group set mb-balanced models=group/code-mainmagpie group set mb-perf     models=group/code-maxC=~/.config/magpie-bridge/router.jsonjq '.classifier = "typesafe/jev-latest" | .classify_timeout_ms = 4000'"$C">"$C.tmp"&&mv"$C.tmp""$C"magpie claude group/mbridge                        # Claude Code 从 code-auto 换到鹊桥的入口组cd ~/code/your-project && mbridge router init --preset cnclaude plugin marketplace add weiping/magpie-bridgeclaude plugin install magpie-bridge@magpie-bridgembridge router check

code-auto留着也不碍事，哪个 Agent 还没装鹊桥的插件，就继续让它用 code-auto。

Codex 和 Pi 的插件、每条规则的细节和校准方法，鹊桥的 README 里有完整说明。安装使用详读：给编码 Agent 按轮选模型：简单活交给便宜模型，难活交给最强模型

只用一个 Agent、对分档精度没那么在意的话，magpie 自带的意图规则已经够用。

写在最后

折腾这些客户端，我想要的是环境搭好以后，注意力全还给业务代码。现在换模型、换账号、给新装的 Agent 补 MCP，这些事都交给了 magpie，哪个 Agent 顺手就用哪个。

工具该退到幕后的时候，就让它安安静静待在幕后。

参考资料

• magpie 仓库（https://github.com/yetone/magpie）
• magpie 中文文档（https://usemagpie.ai/docs/zh/start）
• magpie 意图路由文档（https://usemagpie.ai/docs/zh/intent）
• 鹊桥 Magpie Bridge（https://github.com/weiping/magpie-bridge）