Magpie：让 Claude Code 跑 Kimi，只需在菜单栏点一下

你机器上大概率同时躺着 Claude Code、Codex 和 Gemini CLI。它们连配置文件的格式都不肯统一：Claude Code 读 ~/.claude/settings.json，Codex 读 ~/.codex/config.toml，Gemini CLI 换成了另一套环境变量。你想让 Codex 试试 DeepSeek 的新模型，就得先手改 TOML，再默默祈祷下一个启动的进程别把它覆盖回去。

更烦的是第二层。你花钱买的 Claude 订阅只能在 Claude Code 里用，ChatGPT 订阅锁在 Codex 里，Copilot 席位捆在 VS Code 上。三个工具三份订阅，各自计费、各自限流、各自到点重置，额度算到哪一步全靠人肉记账。

magpie 就是冲着这两层来的。作者 yetone 上一个知名作品是 Neovim 里的 avante.nvim。仓库 2026 年 9 月 23 日建仓，MIT 协议，主语言 Go，截至 2026 年 10 月 31 日已经 26,792 Stars、2,250 Forks，最新版本 v0.1.2431。

一句话说清它干什么：在本机 127.0.0.1:3425 起一个网关，把所有 Agent 的 base URL 统一指过去，然后你在菜单栏点一下，就能让 Claude Code 跑 Kimi、Codex 跑 DeepSeek、Gemini CLI 跑 GLM。额度见底了，它自己换下一个账号。

不过菜单栏只是面子，真正撑起这个项目的东西 README 只用了两行带过。先把那两层拆开看。

它解决的问题比菜单栏大得多

网关本体值得单独说。它在同一个端口上同时暴露四套端点：/v1/chat/completions 走 OpenAI Chat，/v1/responses 走 OpenAI Responses，/v1/messages 走 Anthropic Messages，/v1beta/models/{model}:generateContent 走 Gemini 形态。任何 Agent 用自己最熟的方言进来，都行。

中间那层是协议无关的 IR。magpie 把请求解析成一套统一的中间表示，消息按类型分好，文本、图片、文件、tool call、tool result、thinking、联网搜索结果各有各的字段，确定目标厂商之后再按对方的方言重新编码出去。难点不在翻译，在于别把东西拍平：流式输出、工具调用、reasoning 内容、图片、token 计数，跨协议时最容易丢的就是这几样，IR 给它们都留了位置。

第二层是配置改写，这是我觉得工程上最讲究的地方。internal/edit 里给 JSON、JSONC、TOML、YAML、dotenv 各写了一个专用编辑器，只动你改的那一个键，注释、顺序、格式全部保留，原子写入，被替换的旧值进 stash，切回去时原样恢复。它还记着自己上次给每个 Agent 写过什么，万一别的程序把配置改坏了，面板上弹的是 Drift 警告，而不是默默覆盖回去。

把这两层画出来就能看清 magpie 的形状：它其实是两条路并行，一条写配置，一条转请求。

上面那条是控制面，你点菜单栏，它去改各 Agent 的原生配置文件；下面那条是数据面，Agent 发出去的请求打到网关，翻译完再转给上游。两条路只在网关这一层交汇，这也解释了为什么切换对 Agent 是完全无感的。

第三层是调度。路由组把多个模型打包成一个 group/xxx 的名字，五种模式语义各不相同：smart 优先用额度最早重置的订阅，order 钉死主力挂了才降级，rotate 每轮轮换，usage 按 token 用量带半衰期挑最少的，pace 按每周剩余额度除以剩余小时数来分。失败冷却也做得比人细，欠费歇 30 分钟，额度用尽歇 15 分钟，厂商自带 retry-after 就信厂商的，最长信一小时。

最野的一层是订阅复用。你在 Claude Code 里 OAuth 登录的订阅会被识别成一个 provider，~/.codex/auth.json 里的 ChatGPT 登录同理会变成另一个，Copilot 和 Gemini Code Assist 也算，Grok 也一样。识别完之后，这些账号能反过来供给其他所有 Agent。

Claude 这条路没走伪造。Anthropic 会把别人的 system prompt 判成第三方流量，直连就是封号。magpie 的做法是真的驱动本机那个 claude 二进制去发每一次生成，调用方的工具通过 MCP 桥接进同一轮对话，工具结果再续回同一个进程。

还有一层默认关着的隐私脱敏。打开之后，API key、私钥、token、邮箱、卡号在请求离开本机前被换成 {{API_KEY_xxx}} 这样的占位符，回复里再换回来，流式和 tool call 参数都换。同一个值永远同一个占位符，prompt cache 不会被打碎。

三条命令就能跑起来，但有四处会绊人

装法有四种，macOS 有签名公证的 dmg 和 zip，Windows 与 Linux 各有对应构建，官网脚本一条命令装完，还有 Go 环境和 Docker 镜像两条路。最省事的是下面这两条：

# 官网脚本（macOS / Linux）
curl -fsSL https://usemagpie.ai/install.sh | sh

# 有 Go 环境就走这条
go install github.com/yetone/magpie@latest

跑通只要三步：起本地服务、加一个渠道、给 Agent 指定模型。第三条命令才是有意思的那条。

magpie serve &
magpie provider add deepseek sk-xxxxxxxx
magpie claude deepseek/deepseek-v4-pro

它干的事是改 ~/.claude/settings.json，把 ANTHROPIC_BASE_URL 指向本地网关。新开一个会话，链路就变成 Claude Code 发 Anthropic 格式到 3425，网关翻成 OpenAI Chat 发给 DeepSeek，再把 SSE 事件翻回 Anthropic 的形状。

不在支持列表里的工具也能接，只要它允许自定义 base URL，设三个环境变量就完事。注意 API key 随便填，网关只监听 loopback，官方示例里就直接写 magpie 这个字符串：

export OPENAI_BASE_URL=http://127.0.0.1:3425/v1
export ANTHROPIC_BASE_URL=http://127.0.0.1:3425
export GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:3425

一次请求在网关内部到底走几步，光看文字容易糊，画成时序图就清楚了，客户端、网关入口、协议翻译、上游、回流，五个阶段。

图上那个 IR 环节是全部价值的所在。没有它，四套协议就是四个互相翻译的补丁；有了它，才是一层能持续扩的模型。

坑也不是没有，而且每一条都能在 issue 区翻到原始报告，原话比我转述刺眼得多，不过这些还不是全部：

• 有用户反复遇到 504，报错原文是 “magpie held this request for 30s without routing it to any provider”，请求挂满 30 秒没路由出去就被掐了
• Claude Code 桥接那边，一条消息里的第二个 tool call 到 Codex 会变成空参数，而且这一轮可能静默结束
• MCP hub 的每个 tools/call 都会重列全部上游，共享一个 40 秒预算，一个上游卡住就拖累所有客户端
• GUI 直接打开 ?view=plugin-xxx 这种深链，插件列表还没加载完就先弹回 Providers 页

谁该装，谁装了会后悔

判断标准 README 自己写得很坦白：能帮到你的是这样一批人，用不止一个 Agent、不止一个 provider、或者不止一个账号。不过反过来也成立，只用一个 Agent 配它自家套餐的，装它纯属给自己加一层转发。

把同类工具摆一起看，三类人根本不用装。想把模型网关给线上应用用的，那是 LiteLLM 的活，它做的是服务端统一上百个模型、预算管控和审计。想要渠道管理、分发和计费面板的，New API 更对口。只想在几个 Claude Code 供应商之间切配置的，CC Switch 这种单点工具就够。

四者的定位差得比名字看上去还要远，摆在一张图上比用嘴说清楚得多，尤其最后那一格。

不过 magpie 占的是个人桌面这一格，不上生产、不做计费出租、不管团队，只管你这台机器上一堆 Agent 和一堆渠道之间的接线。作为替代方案它只对个人开发者成立，至于订阅复用这条贴着厂商规则走的路，重要工作账号上别赌。

四个星期堆出两千五百个 issue

先看硬指标，单个数字没什么意义，几个凑在一起才有味道，尤其最后那一行。

Bus Factor 这一项得单独拆。全仓 5,703 次提交里，yetone 本人占了 5,058 次，接近 89%，第二贡献者 69 次，第三 50 次。这个结构意味着迭代节奏完全绑在一个人身上，而他同时还维护着 avante.nvim。更少见的是贡献模型，main 分支的 PR 策略是 collaborators only，README 写得很直白，这个仓库不接受 pull request，只有维护者能提，想要功能就去 Discord 描述。

2,540 个 open issue 放在一个五周的仓库上，这个比例不正常。好处是修得快，v0.1.2429、2430、2431 三个版本在 10 月 31 日 17:05 到 17:13 的八分钟里发完，厂商上午发模型，下午就进列表。代价是你得容忍行为漂移，生产环境用建议钉死版本。

社区里有一句我印象很深，来自一篇中文技术博客的实际使用记录：最值钱的不是菜单栏点一下，而是路由组加额度感知那套调度，以前全靠感觉换号，现在按失败类型精确冷却，人彻底不用管这件事了。这话比 README 里任何一段都有说服力，不过它只说了好的一面。

我的判断：值钱的是调度，不是那个菜单栏

我的判断是，magpie 的价值重心和最显眼的地方错位了。菜单栏那个交互是它的传播素材，真正撑住日常使用的是调度器和配置编辑器，这两块恰好都不上镜。

一开始我把它归进又一个模型切换器那一类。CC Switch 这类同类工具做的是同一件事，只是范围窄一点。翻完 internal/ 下那 69 个包之后我改了口，这不是切换器，是把 Agent 的运行时环境当成一个需要统一治理的对象。

被高估的是 intent routing。让一个小模型先读每轮请求判断难度，简单的给便宜模型，思路没错，但每轮多一次分类调用，分错的代价比省下的钱大。个人一天几百个请求，开着基本是给自己加调试面。

趋势上它在上升，而且升得很急。但从 Star 和 Watcher 的比例看，26,792 个星只换来 35 个 watcher，这种结构通常意味着关注度远大于深度投入，多数人是被趋势榜推过来点了个星。真正的风险在别处：单维护者加每天几个版本，意味着任何一次上游变更都可能让某条路径失效几天，订阅复用还贴着 ToS 走，被风控一次就得自己想办法。

回到最初那个问题，它到底会不会变成平白多出来的一层故障点，取决于你把哪个 Agent 放在哪条链路上。位置选对了它省事，选错了它就是那条多出来的腿。

资源地址

先用三个渠道跑一周

如果你手上已经有两个以上的 coding agent，现在就可以装。但别一上来就开订阅复用，先把两三个 API key 加进去，用路由组的 order 模式跑一周，确认工具调用和流式输出在你的工作流里没问题。

如果你还在观望，盯两个指标就够了。一是上游厂商对第三方客户端的判定口径，二是 daily warm-up 和额度调度能不能稳定下来。这两点决定了 magpie 会不会从个人玩具变成日常依赖。

顺便说一句，这类项目的时间窗口一向很短。厂商只要把多模型切换直接做进 CLI，那个菜单栏就没那么必要了。它真正的护城河是六十多个 Agent 的配置写回逻辑，那玩意儿没法一晚上追上来。