1.6万Star,他把所有AI编程工具接进一个菜单栏

我现在的开发机上有四个 AI 编程工具：Claude Code 写重构，Codex 啃不熟悉的代码库，Gemini CLI 处理长文档，OpenCode 干杂活。

四个工具，四个配置文件，四种格式。settings.json 里塞着 Claude 的模型名，config.toml 里是 Codex 的 provider 组合，还有一个 .env 专门存 key。

真正烦的不是填一遍，是改一遍要改四处。DeepSeek 出了个便宜的新模型，我想在这四个里都试一下，就得开四个文件、对四份文档、确认四个参数名是不是同一个意思。

一个叫 magpie 的项目把这些收进了一个菜单栏图标里。26 天，1.6 万 Star。

这一屏就是产品本体。左边是电脑上装了的 Agent，右边是它现在用的模型，点一下换一个。

这张表反常的地方不是能换，而是换的组合本身。Claude Code 是 Anthropic 的工具，现在可以跑 Kimi；Codex 是 OpenAI 的工具，现在可以跑 DeepSeek。以前这种组合要想办法改环境变量、架中转、或者干脆放弃，现在是在一个下拉框里选。

这是我看完文档后格外认可的一个设计决定。

大多数「配置管理」工具的做法是：接管你的配置文件，重新生成一份。结果是你原来写的注释没了，字段顺序乱了，哪次它版本升级把你的自定义项吃掉，你根本不知道。

magpie 的做法是外科手术式改写：只动你改的那一个键，settings.json、config.toml、opencode.jsonc、config.yaml 里的注释、顺序、缩进都原地保留，写入是原子的。

一个开关文件，和一套接管文件的系统，长期用下来的体验差别会很大。前者你随时可以停下来，后者你只能希望维护者不出错。

它不是给每个 Agent 各写一套适配，而是自己在本机起一个网关，地址是 127.0.0.1:3425，同时会说四种方言：

Agent 把请求发给这个端口，magpie 负责翻译并转给真正提供模型的厂商，流式输出、工具调用、推理内容都在翻译范围内。所以 README 里那句「支持 60 多个 Agent」不是逐个硬编码出来的适配列表，而是只要这个工具能填 base URL，它就能用。

不方便走界面的时候，三组环境变量也能接上（按需挑一组）：

用的时候前面加 export 即可，比如 export OPENAI_API_KEY=magpie。

这条是很多人真正的动力。

你在 Claude Code 里登录了 Claude 订阅，在 Codex 里登录了 ChatGPT 订阅，这些登录态本该只属于它们自己。magpie 把登录过的账号当成一个 provider 暴露给其他所有 Agent——不用复制 token，不用粘贴 key。

也就是说，写脚本这件事可以让 Codex 用你 ChatGPT 订阅里的模型来干，讨论方案可以让 Claude Code 用，额度各自算各自的。

Agents 页显示的是「已接入」状态和每个 Agent 能看到的模型数量

它读取登录信息的方式是读 Agent 自己的文件或钥匙串（macOS 钥匙串、~/.claude、~/.codex 这些）。这一点必须写清楚，因为不是所有人都愿意：官方给了三个关闭途径——设置里的「订阅账号」开关、magpie accounts discovery off、或者只对这一次运行生效的 MAGPIE_NO_ACCOUNTS=1。API Key 那类 provider 不受影响。

这是整个项目里格外「工程」的一块，叫路由组。

一个路由组是几个模型的集合，Agent 把它当成一个模型来选，写成 group/daily-coding。网关把请求分摊到这个组里所有成员的 key 和账号上。分摊策略有六种：

文档里还有一句我觉得更值得看：只要厂商的提示词缓存还值得保留，对话就留在回答它的那个账号上。 这句话说明作者真的想过边界——如果每次都重新挑账号，缓存全废，省下来的额度还不够补缓存的钱。

路由组还能嵌套，另外还有一个「意图路由」：让一个小模型读每轮新消息，写测试的活交给强模型，闲聊交给便宜模型。

路由页把每一次「为什么选它」都摊开写：命中规则、实际耗时、token 数

用量页按官方价格算花费，token 的输入输出分开、缓存读写分开、推理单独计，每个 key 和每个账号的余额窗口都能看，还能 OTLP 导出到你自己的可观测系统。

上面这张图是官方的演示数据，不是实测数据——但结构值得注意：它把「缓存读取」单独拎出来了。对长会话来说，缓存命中率往往比单价更决定最终花费，很多工具只告诉你花了多少钱，不告诉你钱花在哪。

我原本想统计「多久更新一次」，拉完数据发现这个问法不成立。

yetone/magpie-releases 里从 v0.1.925 到 v0.1.1290，共 360 个 release，全落在 15 天里。10 月 14 日一天 15 个，15 日 19 个，16 日 14 个。

这算不上勤奋，更像是一种跟不上的焦虑。模型一周一个新版本，各家 API 参数名各写各的，Agent 的配置文件格式也在变。一个把所有 Agent 接在一起的项目，本质上是在替所有上游收拾残局，上游一动它就得跟。

代价也很明显：open issue 1,130 个（另有 17 个 PR）。对一个建仓 26 天的项目来说，这个数字说明需求涌入的速度远超处理速度。项目已经关闭了 1,212 个 issue，但池子还在涨。

这篇不是软文，所以下面几条必须写：

其一，它不接受 Pull Request。 README 里明确写着「本仓库不接受 Pull Request，只有维护者能提交」，想改功能只能去 Discord 说清楚，由维护者实现。对想参与的人来说这是硬门槛，对只想用的人来说反而意味着代码质量由一个人把关。

其二，它不替你跑 Agent。 magpie 只改配置、起网关，真正干活的还是你原来的 Claude Code、Codex。所以它退出时，连着网关的 Agent 会失去连接——终端版 TUI 在运行时同时兼任网关，关掉就没了。

其三，它有默认开启的使用统计。 每天向 PostHog 发一次：随机 ID、版本、系统架构，以及你用到的 agent、provider、model 的自有 id（你自己添加的 provider 只记作 custom）。不发提示词、不发 key、不发用量。可以在设置里关，也可以设 DO_NOT_TRACK=1。

其四，它要读你的登录态。 前面说过，这是复用订阅的前提，也是这个工具格外需要你自己判断的一步。

其五，不花钱指的是软件本身。 项目 MIT 协议、下载不收钱，但你调用的每个模型都还在按厂商的价格花钱。它省的是「重复买同一份额度」和「额度用尽时的等待」，不省调用量。

安装、加 provider、切模型，三步就够跑起来：

逐行对应：第一段安装，第二段加 provider，第三段让 Claude Code 换上 DeepSeek。Mac 版已签名公证，也可以 go install 或跑 Docker。

如果你习惯终端，magpie tui 里功能是全的，不用开界面。想备份整套方案换台机器，magpie save work 存一份，到新机器 magpie use work 就回来了。

判断标准其实很简单，README 自己给了：

我觉得还能再补半句：如果你在意自己的配置文件长什么样，它也比那些接管式方案更值得试。

数据说明：Star 16,419、Fork 1,184、open issue 1,130（另有 PR 17 个）、Release 360 个，均为 2026 年 10 月 19 日 GitHub API 实测值；功能描述依据仓库 README 与官方文档，未逐项实机验证。

配图来自 magpie 官方仓库（site/public/img）与 README，界面截图版权归原作者，文中提及的 Claude、ChatGPT、Codex、Gemini、Kimi、DeepSeek 等名称与标识归各自权利人所有。