电脑上的 AI 工具越装越多，Codex、ZCode、WorkBuddy、Qoder、MiniMax Code......为了领免费的赛博鸡蛋，装着装着就这么多了。做一个项目，经常需要来回切换工具，还要记得当前使用哪个工具，改到了哪一步。
就这样我 256 GB 硬盘的 Mac 安装了十多个工具，看着就让人头大。每天都出现硬盘告警。
Mac 空间本来就紧张，工具装得那么多，作为生产力的工具感觉成了我的负担。自己也想过，其实并不需要那么多工具，可是谁又能禁得住免费鸡蛋的诱惑呢？
1 当前的困境
1.1 工具多了，工作也被切碎了
几个工具打开同一个目录，源码可以还是那一份。但聊天记录、索引、附件和工作区状态，往往各存各的。文件是接上了，前面聊过什么、试过什么，换个工具不一定能接着来。
要是再给每个工具各 clone 一份仓库，或者建独立 worktree，工作目录也会多出来。里面的 node_modules、虚拟环境和构建输出还可能重复。不过，包管理器和编译缓存能不能共享，得看实际配置，不能看见几个 App 就说项目复制了几份。
这让我想收一收：日常尽量留在一个主力工具里，确实需要其他能力时再切过去。多工具协作有它的用途，但我不想每做一件小事，都先决定该打开哪一个。但是免费的鸡蛋也很香啊......放不下
1.2 硬盘已经在提醒我
这是我 2026 年 11 月 12 日的硬盘盘点：可用空间约 9.5 GB，几个工具目录已经占了好几个 GB。下面是当时记下来的大小，里面具体是什么，还没全部拆清。
| 位置 | 当时大小 | 需要区分的内容 |
|---|---|---|
~/.codex |
约 22 GB | sessions、会话 SQLite、生成图片等，不能整目录当缓存 |
~/.minimax |
约 9.7 GB | 主要在 v2 目录；会话、附件、缓存各占多少尚未拆清 |
~/.zcode |
约 5.2 GB | agents、artifacts、db 和插件缓存混在其中 |
| Qoder CN / ZCode 的 Application Support | 约 2.6 / 2.4 GB | 当时归为工作区数据与缓存，需要继续细分 |
| Trae CN 数据与应用 | 约 2.5 GB | 应用本体和已有项目记录要分别看 |
| 8 个应用本体 | 合计约 6.8 GB | 应用本体的统计，与上一行有交叉 |
这些数字看着挺大，但不能直接加起来说能清多少。有些统计有交叉，目录里也不全是缓存。会话数据库、生成图片和附件，里面可能还有以后要找的东西，不能看它占空间就直接删。
少用几套工具，能少积累一些新数据，旧的还得另外整理。所以我也得想想，再加一套系统，到底是在省事，还是又多一份要维护的东西。
1.3 想少留几个入口，又舍不得已有额度
但只留一个工具，也有让我犹豫的地方。其他账号里还有已经付过钱的订阅、签到送的积分，以及限时领取的免费额度。模型和用量不一定在我最顺手的工具里，不用觉得可惜，为了用它们来回切，又回到了原来的麻烦。
这么看，我舍不得的未必是这些 App，而是它们背后的模型和额度。最好是工作还在顺手的工具里做，要用哪家的模型，再选哪一家。
2 我需要一个什么样的网关
AI 网关可以放在工具和模型来源之间。工具继续读项目、操作终端、修改文件；模型请求先发给网关，再转到所选来源，回复仍回到原工具里。
text
支持自定义模型的主力工具或脚本
→ 本地 AI 网关
→ 选定的模型来源和账号
→ 回复经网关返回原工具我对它的要求也不复杂：手里的账号或接口能接，常用工具能调用，调用后还能看出来用了哪一家。不然只是多了一个地方填配置，原来的麻烦还在。
不过，这个"模型池"只是把能调用的模型列到一起，各家余额还是各家的。旧聊天、索引和项目副本不会跟着合并，另一款工具的界面操作、审批能力也不会一起带过来。少切工具是一回事，硬盘里的旧数据还得另算。
如果一个工具自带的模型和额度已经够用，那直接用就行。我还想折腾这一步，是因为其他账号里的额度也想用上。那就看看，哪些网关能接得上。
3 可以选择哪些网关
先看这些 AI 网关能接哪些模型来源，再看能给哪些工具用，最后才看用量管理这些功能。下面是对照公开文档整理的，我没有全部装一遍做对比，所以这里只谈功能和适用场景，不排谁快谁稳。
| 方案 | 适合解决的事 | 放到我的情况里怎么选 |
|---|---|---|
| 单工具原生配置 | 直接使用自带模型或自定义 API，少维护一个组件 | 模型和额度够用时，先用这一条 |
| CC Switch | 管理多款编码工具的配置，部分工具支持本地路由、聚合和故障切换 | 如果主要是配置散落，还想一起管理 MCP、Skills 和提示词，值得比较；具体能力按工具区分 |
| Claude Code Router（CCR） | 为多种编码 Agent 提供统一入口、路由、失败切换和请求记录 | 如果要控制请求走向、排查调用问题，可以纳入选择，当前范围已不只 Claude Code |
| CLIProxyAPI | 将支持的 CLI／账号来源提供成兼容 API | 和我的账号复用需求接近，要逐项核对来源、协议和客户端入口 |
| LiteLLM | 自托管统一 API，管理路由、用量、虚拟密钥和访问权限 | 多项目或团队统一管理时更值得考虑；虚拟密钥等功能还需要配置数据库 |
| New API | 自托管多渠道网关，管理模型、用户、额度和费用 | 要向多个应用或成员提供模型服务时更切题，需要维护服务和持久数据 |
| Magpie | 在桌面端或 CLI 管理 Agent 模型配置，经本地网关接入来源 | 有这次需要的 WorkBuddy、Qoder 社区插件，可以先从我已有的账号试起 |
这些产品功能已经有重叠，不能只按"改配置"或"转发请求"分成互不相关的几类。比如 CC Switch 已有本地路由，CCR 也已覆盖多种 Agent。LiteLLM 的数据库条件则要结合所用功能看，见其虚拟密钥文档。
我现在主要是自己用，团队权限、费用分配这些暂时用不到。先把手里的账号和常用工具接起来，别一上来又搭个大平台。
4 为什么我选择了用 Magpie
Magpie 本身免费、开源，有桌面端和 CLI。我不用为了试这个入口再买一份订阅；它的 WorkBuddy、Qoder 社区插件，也和我手里的账号对接。这两个理由，足够让我先装起来看看。
最想用起来的，还是账号里这些用量。订阅已经付过钱了，签到和活动又能领一些；要是能做掉一部分日常任务，也能少买点额外用量。不过这几笔账得分开：
| 资源 | 我想怎么用 |
|---|---|
| 已付费订阅 | 在顺手的工具里继续用已有模型和剩余用量 |
| 签到积分 | 按支持的模型和倍率，覆盖一部分整理笔记、解释脚本等日常待办 |
| 限时赠送额度 | 有适合的任务、又在有效期内时使用，不为赶过期时间凑任务 |
积分不能直接当 tokens 算，免费额度也不是无限用。能调哪些模型、先扣哪份余额，还得看各家的规则。Magpie 能不能把入口接起来是一回事，最后省了多少，是用过以后才能算的账。
按入门文档，先添加模型来源，再给 Agent 选模型；订阅登录和请求由相应插件处理。接下来先把来源和工具接起来，再处理签到、活动额度和回退。这份记录对应 2026 年 11 月 12---13 日，机器是 Apple Silicon Mac，安装时 Magpie 版本为 0.1.3853。
5 完整接入配置：把账号里的模型接到常用工具
名字一多，很容易把"谁提供模型"和"在哪个工具里用"混在一起。先分清这三个角色：
| 对象 | 在这里做什么 | 例子 |
|---|---|---|
| 模型来源（Provider） | 提供模型调用和账号用量 | WorkBuddy、WorkBuddy AI、Qoder、Qoder CN、ZCode |
| 使用工具（Agent） | 我实际读项目、写代码或整理材料的地方 | MiniMax Code、WorkBuddy、ZCode 等 |
| Magpie | 接入来源、管理模型清单、转发请求，并为支持的工具写入接入配置 | 本机网关 127.0.0.1:3425 |
同一个名字可以出现在两边。ZCode 可以给其他工具提供模型，也可以作为工具使用别家的模型。接账号和接工具，是两件事。
下面的 magpie ... 都是在 Mac 终端执行，由 Magpie 处理，不是在 MiniMax Code 的聊天框里输入。日常选模型仍可以在 App 里做，不用为了网关把工作搬到终端。
5.1 安装桌面端和命令行
先在 Mac 终端运行官方安装脚本，它会安装 Magpie 桌面端和 magpie 命令：
sh
curl -fsSL https://usemagpie.ai/install.sh | sh第一次直连一直没下完。我按 Ctrl-C 中止，带上现有代理重跑后安装成功：
sh
curl -fsSL https://usemagpie.ai/install.sh | sh -s -- --proxy http://192.168.0.31:20172这里的代理是我当时已有的网络配置，不是安装 Magpie 必须照填的地址。
最后落盘两样东西：/Applications/magpie.app 和 ~/.local/bin/magpie。打开 App，界面是中文的，快速上手提示添加模型来源、接入 Agent、设置路由，其中路由是可选项。
当时还弹了一个 macOS 提示：「magpie 尝试从其他 App 访问你的数据，已被阻止」。我没有额外放行，后续记录里的配置读取和调用仍完成了。仅凭这个提示，不能确定具体拦住了哪次访问。
5.2 看它识别到了哪些工具
sh
magpie ls这条命令由 Magpie 列出本机识别到的工具、配置位置和当前模型，不会发起模型问答。我这台机器当时检出 17 个，包括 MiniMax Code、ZCode、两个 WorkBuddy、两个 Qoder 等。
刚打开时，选择器里主要是 GPT。结合当时的登录态和配置看，是 Codex 的 8 个订阅模型先被发现了。但我想接的是其他账号里的模型和额度，工具被识别到，还不等于这些来源已经接好。
5.3 安装来源插件，登录已有账号
这里安装的是来源插件，不是再装一遍 WorkBuddy、Qoder 桌面 App：
sh
magpie plugin add workbuddy
magpie plugin add qoder
ZCode 来源当时已经显示登录，另外几家还写着 not signed in。按需要的来源继续授权：
sh
magpie plugin login workbuddy
magpie plugin login workbuddy-ai
magpie plugin login qoder
magpie plugin login qoder-cnlogin 后面填的是提供模型的来源。跟着浏览器或设备授权页完成登录，再看对应来源是否显示已登录。这一步还没有决定 MiniMax Code 用哪个模型。
WorkBuddy 登录踩了一次坑。我先选"复用桌面端登录态"，报错提示桌面端 5.6 及之后的凭据加密保存，Magpie 无法复用，建议改用浏览器登录。重跑选浏览器，利用已有会话完成了授权。WorkBuddy AI 同样走浏览器；Qoder 和 Qoder CN 走设备授权页。
最初记录的模型数是 WorkBuddy 15 个、WorkBuddy AI 16 个、Qoder 17 个、Qoder CN 4 个、ZCode 4 个。后来目录有变化，所以这些是当时的数，不是固定规格。随 Qoder 插件附带的 QwenWork 和企业版没有登录，我没有把它们算成可用来源。
同一个模型名可以出现在不同平台。比如 MiniMax 模型也能由 WorkBuddy AI 提供，请求仍走 WorkBuddy AI 的账号和用量。名字相同，不代表余额相通。
5.4 分开配置来源范围和对外模型
我需要的是把几家的特定模型聚到一起，不是把账号里所有模型都搬进来。这里有两层限制，少一层都会配偏。
第一层，决定每个工具能用哪些来源。 每个工具排除自身对应的来源和 Codex，其他需要的来源保留。ZCode 自己不重复显示 zcode/*，但其他工具仍要能用它。
第二层，决定各来源拿出哪些模型。 两个 WorkBuddy 各只保留 Hy3、Hy4、DeepSeek 4.1 Flash、GLM 5.3 Flash；两个 Qoder 各保留 Qwen4-Max-Preview、Qwen3.8-Flash、DeepSeek-Flash、GLM-5.3-Flash，不把其他模型一起放进来。
按实际目录里的显示名，我要保留的是这些模型：
| 来源 | 对外保留的模型 |
|---|---|
| WorkBuddy | Hy3、Hy4、DeepSeek-V4.1-Flash、GLM-5.3-Flash |
| WorkBuddy AI | Hy3、Hy4、DeepSeek-V4.1-Flash、GLM-5.3-Flash |
| Qoder | Qwen4-Max-Preview、Qwen3.8-Flash、DeepSeek-Flash、GLM-5.3-Flash |
| Qoder CN | Qwen4-Max-Preview、Qwen3.8-Flash、DeepSeek-Flash、GLM-5.3-Flash |
| ZCode | GLM-5.3、GLM-5.3-Flash、GLM-5.2、GLM-5-Turbo |
正文表格用模型显示名。命令里的 qmodel_latest 对应 Qwen4-Max-Preview，qfmodel 对应 Qwen3.8-Flash，dfmodel 对应 DeepSeek-Flash，gfmodel 对应 GLM-5.3-Flash；它们是来源接口使用的 ID，不是另几个模型。
这里的 Hy4 是目录里名为 Hy4 的 hy4free，没有把 hy4std 和 Hy3 X 等其他条目顺带加入。两个 Qoder 的 qmodel_latest 都标为 Qwen4-Max-Preview，gfmodel 标为 GLM-5.3-Flash，dfmodel 标为 DeepSeek-Flash。这个 DeepSeek 的版本后来也查到了：国际版官方说明和 CN 官方说明都明确写出，选择器里的 DeepSeek-Flash 对应 DeepSeek-V4.1-Flash-1017 。所以这里可以确认是 4.1 系列的 1017 版，依据是两家的官方命名说明，不是让模型自己回答身份。配置和界面仍保留来源实际使用的 dfmodel 和 DeepSeek-Flash 名称。
Qoder CN 的目录还得注意刷新：本地旧目录最初只列出 Qwen3.8-Flash，同步后才返回了上述三项，不能拿 Qwen3.8-Flash 当 Qwen4 的替代。此前用量查询显示其附加积分为 1600 / 1600 credits、剩余 0，但名单内三个条目在这次逐项调用中都返回了预期文本。这个积分窗口不能代表账号全部可用权益，也不能仅凭它推断所有模型都不能调用；具体扣到哪份权益仍需上游用量明细确认。
前面走偏的地方也在这里：一度停用了整个 ZCode 来源，其他工具的白名单也漏了它；后来又把"保留其他来源"理解成"放开所有模型"，清掉模型限制，于是 MiniMax 里出现了 58 个、WorkBuddy 里出现了 41 个。两种结果都不是我要的范围。
修正时先留了回滚副本，再按表里的 ID 写回 Magpie 保存的模型勾选清单，并按工具排除自身来源。来源白名单和模型勾选是一起生效的。以 MiniMax Code 为例，勾选清单确定后，由 Magpie 执行：
sh
magpie visible minimax-code zcode,workbuddy,workbuddy-ai,qoder,qoder-cn
magpie visible minimax-code --only-picked
magpie sync第一条限定来源；第二条只显示已经按表选定的模型，避免来源里的其他模型或新条目自动混进来；第三条同步模型目录和写入各工具的模型清单。--only-picked 不会替我选模型，只执行它却没有先设置勾选清单，得不到上表的范围。
这次还遇到一个实际差异：网关清单已经收窄，App 配置文件却仍是旧的全量清单。同步后，再核对工具配置和重启后的界面，才把这两边对齐。
最终各工具的聚合清单如下，数量对应 11 月 13 日这次检查：
| 工具 | 配置中的聚合模型数 | 其中 ZCode 模型数 | 自身来源 / Codex |
|---|---|---|---|
| Claude Code | 20 | 4 | 0 / 0 |
| MiniMax Code | 20 | 4 | 0 / 0 |
| Qoder | 16 | 4 | 0 / 0 |
| Qoder CN | 16 | 4 | 0 / 0 |
| WorkBuddy | 16 | 4 | 0 / 0 |
| WorkBuddy AI | 16 | 4 | 0 / 0 |
| ZCode | 16 | 0 | 0 / 0 |
表里是当前工具配置和网关接口的限定清单。两个 Qoder 都补回 Qwen3.8-Flash 后，MiniMax Code 为 20 个、WorkBuddy 为 16 个；没有把两个 WorkBuddy 的 GPT、Grok、Kimi 等模型放进来。下文保留实际 App 聊天验收结果，但本次补回模型后没有重做 App 菜单检查，已打开的工具还需重新加载清单。
此前，运行中的 /v1/models 一度漏列 Qoder CN 的三项，导致 MiniMax 对应接口只有 15 个、WorkBuddy 只有 11 个，而 App 配置和菜单已经是 18、14 个。核对当前网关版本 0.1.3958 的目录读取逻辑及插件变更检查，可以看到 CLI 和桌面网关各自保有 Provider 内存快照；网关优先读取已有快照，磁盘目录更新不等于另一个进程立即换成新目录。这与当时"文件已更新、运行中接口仍旧"的现象相符。
继续复查时，运行中目录已经恢复。随后又执行了一次 magpie sync，逐项对照限定 ID，确认工具配置与运行中网关现在一致：补回 Qwen3.8-Flash 后，MiniMax 20 个、WorkBuddy 16 个，两个 Qoder 的四个条目都已包含；其余工具也符合上表，自身来源和 Codex 仍未加入。这里恢复的是目录同步，没有放开全量模型，也没有修改 Magpie 源码或重启网关服务。至于此前究竟由哪个刷新事件让旧快照恢复，现有日志没有记下来，不能补写一个确定的历史触发原因。
这里筛的是 Magpie 聚合清单，没有移除 App 原生模型。MiniMax 自带的 M3、M3.1-Flash 和 WorkBuddy 原生菜单仍在。这次也没有独立的 MiniMax 来源接入，不能因为装了 MiniMax Code，就写成 MiniMax 订阅也接进来了。
5.5 先确认网关能调用来源
账号登录以后，我先用一条文本请求检查网关到来源这一段：
sh
curl -s http://127.0.0.1:3425/v1/chat/completions \
-H "Authorization: Bearer magpie" \
-H "Content-Type: application/json" \
-d '{"model":"workbuddy-ai/deepseek-v4.1-flash-sg","messages":[{"role":"user","content":"你是什么模型？一句话回答"}]}'这是 curl 向本机 Magpie 发请求，再由 Magpie 调 WorkBuddy AI 的 DeepSeek，会产生真实调用，可能消耗账号用量。它不是 MiniMax Code 发出的消息。
回复回来了，说明这次请求有了结果。模型自称"我是谁"不能当身份凭据，还得对照所选来源、模型 ID 和调用记录。
按名单里的四个模型分别核对，两个来源都完成了真实请求。下面直接用模型显示名列结果；请求仍使用 WorkBuddy 已有的网关身份。
| 模型 | Qoder | Qoder CN |
|---|---|---|
| Qwen4-Max-Preview | HTTP 200，MODEL_SCOPE_OK |
HTTP 200，MODEL_SCOPE_OK |
| Qwen3.8-Flash | HTTP 200，QWEN38_OK |
HTTP 200，QWEN38_OK |
| DeepSeek-Flash | HTTP 200，MODEL_SCOPE_OK |
HTTP 200，MODEL_SCOPE_OK |
| GLM-5.3-Flash | HTTP 200，MODEL_SCOPE_OK |
HTTP 200，MODEL_SCOPE_OK |
两个来源各四项，共八项都拿到了预期回复。这次请求由脚本发往正在运行的网关，不是再到 App 聊天框逐项点击发送；两款 App 的实际界面收发验证放在下面。这些结果证明名单内条目这次能够调用，不等于已经比较过编码质量、长会话稳定性或实际扣分。最初六项调用期间检查的七个配置文件哈希未变；补回 Qwen3.8-Flash 时仅增加了对应条目，没有为了测试临时放开其他模型。
5.6 在 MiniMax Code 里选择聚合模型并发消息
这一步的配置对象是 MiniMax Code，执行配置的是 Magpie。在 Magpie 的 Agents 页找到 MiniMax Code，从已经接入、对它可见的模型里选择一个，由 Magpie 写入接入配置。没有另一条"把 MiniMax Code App 导入进去"的命令。
命令行同样可以选模型。比如要给 MiniMax Code 选择名单内 WorkBuddy AI 来源的 GLM-5.3-Flash，命令是：
sh
magpie minimax-code workbuddy-ai/glm-5.3-flash拆开看就清楚了：
| 部分 | 在这里指什么 |
|---|---|
magpie |
执行配置的程序 |
minimax-code |
被配置的使用工具 |
workbuddy-ai |
提供模型的来源 |
glm-5.3-flash |
这次选中的模型 ID |
合起来就是"用 Magpie 给 MiniMax Code 选 WorkBuddy AI 来源的 GLM-5.3-Flash"。它会修改当前模型配置，不是登录 MiniMax 订阅，不是导入全部模型，也不会立刻发出聊天消息。这条用于说明命令各部分的主体；实际界面验证选的是后面说的 ZCode 模型。我仍然可以在约定的模型范围里按任务换来源。
查看可选清单，用另一条只读命令：
sh
magpie models minimax-code多了 models 就是查清单，前面那条则是改选择。模型 ID 按实际清单选，不用照着旧记录固定填一个。
实际界面验收时，我退出并重新打开 MiniMax Code，在 Magpie 分组里核对了 ZCode、两个 WorkBuddy、两个 Qoder 的模型，没有重复接入自身来源，也没有 Codex 来源。当前补回 Qwen3.8-Flash 后的配置数以 5.4 为准，不把旧界面的数量写成最新验收结果。
实际聊天验证使用的是 ZCode 的 GLM-5.3-Flash，在 App 聊天框发送验证消息，界面回复：
MiniMax界面验证通过
对应时段的网关日志也记录为 agent: minimax-code、provider: zcode、model: GLM-5.3-Flash，状态 200。对外模型名单收回后，也重启核对过当时的界面条目，保留的还是同一个 ZCode 模型，没有把此前收发成功扩写成其他模型也全部调用成功。
5.7 在 WorkBuddy 里使用其他来源
WorkBuddy 配置的是 ~/.workbuddy/models.json，WorkBuddy AI 则是 ~/.workbuddy-ai/models.json，别因为名字相近就当成同一份。
我新打开 WorkBuddy，界面显示版本 5.11.2。实际界面验收时，在选择器的"自定义模型"区核对了 ZCode、WorkBuddy AI、Qoder 和 Qoder CN 的模型；这个聚合区没有 workbuddy/* 和 codex/*，也没有名单之外的模型。
实际消息同样选择 ZCode 的 GLM-5.3-Flash，从聊天框发送后收到了：
WorkBuddy界面验证通过
网关日志里对应的来源也是 ZCode，状态 200。这样我可以留在 WorkBuddy 的界面里，用别家账号提供的模型，不用为了这一条消息再去切 ZCode App。
这两款 App 有实际菜单检查和 ZCode 短消息收发记录；补回 Qwen3.8-Flash 后，本次核对了配置和网关清单，没有把旧的 App 检查当成新菜单已验收。其他模型的逐一生成、项目文件读写、工具调用、长会话稳定性、代码质量，还得拿实际任务看，不能一起算通过。至于这次用了哪份额度，放到后面的用量核对里说。
6 额外配置：处理其他入口、积分、活动额度与回退
前面是把来源和常用工具接起来。这一部分按自己的需要看，不是所有工具都得接，也不是所有账号都得签到。
6.1 Qoder CN：配置写入了，IDE 原生聊天是另一个入口
网关有回复以后，我也想把它放进平时写代码的 Qoder CN IDE。先在终端查看，再给 qoder-cn 选 WorkBuddy AI 来源的 DeepSeek：
sh
magpie qoder-cn
magpie qoder-cn workbuddy-ai/deepseek-v4.1-flash-sg执行者仍是 Magpie，修改的是 ~/.qoder-cn/settings.json 中这个 Agent 的接入配置。文件里确实出现了 providers.magpie，baseUrl 指向 http://127.0.0.1:3425/v1，模型也指向对应的池内条目。
但 IDE 模型选择器里没有因此出现 Magpie。我去设置里看，"添加模型"的提供商下拉只有 7 家预设：阿里云百炼、千问 AI 平台、智谱、Kimi、MiniMax、DeepSeek、小米 MiMo，没有找到能填本地网关 baseUrl 的地方。
当时检查的扩展路径里，也没找到 IDE 原生聊天读取这份本地自定义供应商配置的逻辑。所以这里能确认的是配置已经写入、Magpie 能给 qoder-cn 列出模型；Qoder CN IDE 原生聊天接入尚未确认。MiniMax Code 和 WorkBuddy 的成功，不能替它作证。
这条路没有继续改 IDE。先把能直接用的入口用起来，没必要为了统一入口，又维护一份自己改过的 IDE。
6.2 给支持的来源账号签到
我惦记的赛博鸡蛋里，签到积分算一份。Magpie 可以替支持签到的来源账号执行领取，但"程序支持"与"我的账号已经自动领到"得分开。记录里手动运行过：
sh
magpie accounts checkin这是让 Magpie 为支持的来源账号触发签到，不是选模型，也不是发送问答。输出里 WorkBuddy、Qoder、Qoder CN 都显示当天已签到，各有 +100 · already。
already 是已经领过了，不是再跑一次命令又加 100。这些是历史签到结果，不能拿来证明后面每一天都自动领到了。积分的有效期、支持哪些模型、按什么倍率扣，还得看各自账号的规则。
按这次安装的功能和插件，自动领取也要分来源：
| 来源 | Magpie 支持到哪一步 |
|---|---|
| WorkBuddy | 当前插件有签到接口，需要有效的账号登录态；API Key 登录不能据此签到 |
| WorkBuddy AI | 当前插件没有提供签到处理，不能套用 WorkBuddy 的自动签到结论 |
| Qoder / Qoder CN | 插件支持领取每日活动积分，可能依赖原厂设备辅助程序；当天是否有活动、能否领取，以返回结果为准 |
| MiniMax Code | Magpie 已有每日签到功能，需要能识别有效的 MiniMax Code 账号，并开启相应签到选项 |
| ZCode | 插件支持尝试领取活动套餐；需要验证码时，仍要回原客户端手动完成 |
MiniMax Code 这里容易混：它作为工作工具使用 ZCode 模型，与它自己的账号签到，是两件事。Magpie 的功能记录已经列有 MiniMax Code 每日签到，但这次只读检查到本机 minimaxCheckin 为 false，也没有核对到 MiniMax 自动领取成功的记录，所以不能写成"已经在自动领"。
按 Magpie 的签到机制说明，需要对相应来源开启签到、保持账号有效，并让 Magpie 在运行时执行；睡眠、退出或网络失败时，不能保证每天固定时刻到账。最终看账号卡片里的领取结果和上游余额，不是开关亮了就算领到了。本次没有开启或修改这些签到选项。
6.3 ZCode 的限时赠送：领到了，调用时还得看哪份额度有效
当时 ZCode 客户端左侧的「ZCODE GLOBAL BUILD」卡片显示，每日可领 3 亿 GLM-5.3-Flash tokens，当晚 23:00 生效、次日 09:00 过期。我在 Mac 客户端手动领取，看到了"领取成功"的弹窗。
不过，领到了和调用时扣到了，是两件事。
这次 ZCode 的网关调用先在下午做了三条短请求，随后又在 MiniMax Code、WorkBuddy 的实际界面里发消息。前一组短请求调用前后，还分别查了同一登录身份的赠送套餐余额，以及 magpie quota zcode --json：
| 检查项 | 调用前 | 调用后 |
|---|---|---|
| 赠送套餐余额接口 | HTTP 200、业务码 0；plans: []、balances: [] |
同样为空 |
| GLM Coding Lite 的 5 小时用量 | 0 / 5000 |
1 / 5000 |
| GLM Coding Lite 的周用量 | 2094 / 5000 |
2094 / 5000 |
当时已经不在截图里的活动有效时间内，接口没有返回可用的赠送套餐或余额，目录里也没有活动对应的 -Trial 条目；Coding Plan 的 5 小时用量则有增长。因此这次确认的是 ZCode 来源调用成功，并观察到了 Coding Plan 用量增长，没有验证到活动赠送额度的消耗。不能把下午的界面回复补写成"赠送额度用上了"。
表里的套餐单位也不能直接当 tokens，统计可能延迟，不能按三条请求倒推恰好扣了几个单位。至于之前领的那份有没有曾经用过，现有历史明细仍不足以确认。
按本机安装的 ZCode 社区插件说明，有效的赠送套餐会提供对应的 <模型>-Trial 条目。主动选它会限定使用赠送额度，被拒时不会回退 Coding Plan；普通模型则可能按"免费优先"设置尝试赠送额度，失败后再回退订阅。所以真要核对赠送消耗，得在活动有效、账号确有余额时，对照一次请求前后的赠送桶明细，不能只看请求成功。
插件还声明支持通过签到处理领取 gift plan，但我的领取成功记录来自客户端手动操作，自动领取是否连续正常没有验证过。恢复来源插件也不是领取的前置步骤，前面关过、开回来的那次操作，只是筛选走偏后的恢复。
6.4 把积分用到实际工作里，也要算 App 的上下文开销
入口接好以后，我准备先用 WorkBuddy 的签到积分做一些原本就要做的小事：整理一段笔记、解释一条脚本、检查操作步骤有没有漏。不是为了赶免费额度，临时给自己找一堆任务。
查 DeepSeek 版本时还顺手确认了一点：两份 Qoder 官方说明中的那次 DeepSeek-Flash 免费活动截止于 2026 年 10 月 31 日 24:00，CN 页面已标"已结束"。这篇记录是 11 月 13 日，不能把旧活动当成当天仍然免费的依据。模型叫什么、现在能不能调用、今天按什么规则扣分，还是得分别看。
比如整理笔记，可以留在 MiniMax Code，选择 workbuddy/glm-5.3-flash 这样的明确来源，再给它一段原始命令和上下文，让它解释参数、调整顺序，我逐项核对。这里不能换成名字相近的 workbuddy-ai/glm-5.3-flash，那是另一个来源，不能拿来消耗 WorkBuddy 这边的签到积分。
开始前先看积分余额、有效期和模型扣分规则；做完再对照 Magpie 的来源、模型、时间，以及上游用量变化。上游先扣赠送积分还是付费余额，按实际规则和明细确认。这个工作例子还没有完成扣分核对，是接下来的用法，不是已经省下多少积分的成绩。
实际界面测试还提醒了我：一句短消息，在 App 里未必只是一条模型请求。 MiniMax Code 和 WorkBuddy 各发了一条验证消息，但对应时段的网关日志是这样的：
| 工具 | ZCode 请求数 | 合计输入 tokens | 合计输出 tokens |
|---|---|---|---|
| WorkBuddy | 2 | 31,281 | 90 |
| MiniMax Code | 3 | 40,729 | 147 |
这些是网关日志里的用量，不等于上游最终计费量。App 可能附带系统提示、工具定义，或者发起会话命名等辅助请求；这次没有逐项拆分，不能替每条请求编用途。但终端里只带十几个输入 tokens 的短请求，确实不能拿来估算 App 实际工作的消耗。
所以我更关心，一份额度最后能做掉什么，做出来要返工多少。修复杂 bug 时，项目理解、工具调用和修复验证都得看。额度是送的，改错代码可不划算。
6.5 日常只留 ZCode、MiniMax Code，其他 App 能不能卸
我平时更习惯用 ZCode，MiniMax Code 作为另一个工作入口。这样可以少开几个窗口，但 Magpie 本身还得保留并运行，不然两个工具就接不到它聚合的来源。
至于其他 App，得看 Magpie 用的是独立登录态，还是每次从原 App 读凭据。按这台机器当前的接入方式：
| App | 当前依赖与取舍 |
|---|---|
| WorkBuddy / WorkBuddy AI | 都是 Magpie 独立保存的 OAuth 登录态，不是每次读取桌面端登录文件。模型调用通常不需要保留或运行它们的桌面 App，可以作为优先精简的候选；但卸载后的重新登录、续期和调用还没有实际复验 |
| Qoder / Qoder CN 桌面端 | 当前登录态也保存在 Magpie。普通调用不需要一直开着桌面端，但签到会使用原厂 runtime-info 设备辅助程序；本机两个 CLI 目录里都已有该程序，能作为插件查找的候选，不过卸载桌面端后的实际签到还没有复验 |
| ZCode | 当前来源标记为读取 ZCode App 登录态，且活动套餐可能需要在客户端过验证码。既然它本来就是主力入口，这次继续保留 |
| MiniMax Code | 继续作为工作入口保留。它自己的登录、签到与通过网关选其他来源的模型分别看 |
这里说的精简是先考虑 App 本体，不是连用户数据一起清空。~/.config/magpie 里有来源和登录信息，~/.qoder、~/.qoder-cn 里还有 CLI 辅助程序，其他目录也可能存着会话、附件和作品。不能用"卸载并清理全部残留"把这些一起带走；也不要把"退出 App"当成"退出账号"。
所以，工作界面只留这两个有条件可行，但现在不能保证删掉其他 App 完全没有影响。调用是否依赖原 App，和签到是否依赖原厂辅助程序，是两项检查。真要卸载，先留回装条件和数据副本，再分批移除 App 本体，核对调用、登录续期和领取。本文还没有完成卸载后的这组验证，本次也没有实际删除任何 App。
6.6 需要撤回时，恢复工具的原生模型配置
以 qoder-cn 为例，如果不再让 Magpie 托管它的模型配置，可以让 Magpie 执行：
sh
magpie qoder-cn default修改对象是这个 Agent 的模型配置，不是卸载 Qoder CN IDE，也不是删除聊天记录。这条留作回退备忘，本次没有执行。
7 折腾完以后
目前比较实在的收获是，工作入口可以少切几个，手里的账号不必因为换了工具就放着不用。平时我还是更习惯用 ZCode，MiniMax Code 留作另一个入口，其他 App 能不能精简，再按前面的依赖分别看。
两个 Qoder 的目录已经对齐，名单内八个条目逐项调用都有回复；DeepSeek-Flash 的官方对应版本也确认是 V4.1-Flash-1017。不过，Qoder CN IDE 原生聊天没有因此接好，完整工作任务还没逐一试，ZCode 的活动赠送消耗也没有验证到。能选、能回一句话，离长期干活稳不稳，还有一段。
MiniMax Code 的签到也可以交给 Magpie。它支持替已登录的 MiniMax Code 账号做每日签到，需要开启对应的签到选项，并让 Magpie 保持运行。这样少了一件每天打开 App 点一下的事。不过我这台机器目前还没开启，也没有自动领取成功的记录，先记下这个功能，没有实验积分已经每天自动到账。签到领的是 MiniMax Code 自己账号里的权益，和我在它里面选择 ZCode 或其他来源的模型，是两回事。
还有封号风险这件事，得说清楚。能接通，不等于平台允许这样使用。Qoder 官方说明对未经授权的服务转接等用法有明确限制，涉嫌违规可能调整访问能力，确认违规后可能暂停或终止服务。所以风险不只是网上公众号的一句提醒，也不能因为是个人自用、这次请求成功，就写成肯定安全。其他来源是否允许这种接入，还得分别看各家的规则。
我这篇记录的是自己这次怎么折腾、哪些地方实际通了，不是平台授权说明，也没有办法保证账号以后不受限制。自己折腾就得自己承担结果。免费的很香，但把账号和正经要做的事搭进去，那就不划算了。