Claude Code 插件用低价模型分担修复

让最贵的模型包办读仓库、改代码、跑测试，可能花了不少没必要的钱。Token Beggar 0.3.0 的做法是：先判断任务大小，大任务交给便宜模型执行，再由当前聊天模型审查和收尾。作者在一组 Python 修复任务上测得，单任务成本约降 29%，测试解决率基本持平。

这组结果值得看，但不能直接套到所有 AI 编程场景。它只覆盖一个聊天模型和特定任务，而且测试打平之外，代码评审还出现了负面信号。

省钱靠的是分工，贵模型仍要负责验收

Token Beggar 是 Claude Code 插件，使用现有 Claude Code，不需要额外 API 或账号。它还在开发中。

它先给任务估大小。小任务留在当前聊天里；大任务，例如修复一个陌生仓库里的 bug，则交给一个便宜的工作模型。后者负责复现问题、探索代码、修改并运行测试。

聊天模型随后读取完整 diff，再跑一遍测试；发现遗漏，就把任务退回去继续处理。设计、根因判断和最终答复仍由用户选定的模型负责。聊天模型及其 effort 是上限，插件不会往上升级。

它省的是执行过程的钱，同时保留较贵模型的审查环节。

这个分工成立的前提是：便宜模型能完成足够多的探索和修改，且返工成本没有吃掉节省。最终模型仍需读 diff、重跑测试，因此工作并没有全部转移出去。

29% 的降幅，到底测了什么

作者只比较两种配置：聊天模型独立工作，以及启用 0.3.0 随附配置。聊天模型固定为 Opus 5.5，high effort；成本按聊天和所有工作模型的公开标价计算，包含缓存计费。

任务来自 12 个开源 Python 项目的 18 个已合并 PR，包括 Django、Sphinx、pylint、sympy、click 等。每次从修复前的 commit 开始，只提供 issue 文本，用维护者后来添加、模型看不到的测试评分。每题跑 3 次，每种配置共 54 次。

结果是单任务成本约降 29%。标题里的 1.42x，指原成本约为新成本的 1.42 倍。18 个任务中有 17 个更便宜，剩下一个贵了约 10%。

解决率是 69% 对 70%，作者认为差异落在波动范围内。耗时为 168 秒对 187 秒，也被视为基本持平，作者没有宣称提速。

为什么早先只有 1.24x？旧实验混合了 21 个大多较小的任务，路由方式也不同。小任务当时只省到 1.11x；作者认为低于约 1.15x 时，难以区分收益和运行波动，所以新版把小任务留在聊天里。

因此，不能把 1.42x 当成日常所有请求的统一折扣。0.3.0 没有重测小任务。

安装容易，但先看收益适用范围

插件要求 Claude Code 和 Python 3.10 或更新版本，只依赖 Python 标准库。下面两条命令分别添加市场并安装插件：

/plugin marketplace add Arthur031221/Token-Beggar
/plugin install token-beggar@token-beggar

注意第二行的 token-beggar@token-beggar，这是原文给出的完整安装标识。之后重启 agent，或运行 /reload-plugins；用 token-beggar doctor 检查 hooks 是否执行。设置 TOKEN_BEGGAR=off 可在某个 shell 中关闭，也可以卸载。

作者称插件在本机运行，只写入自己的文件夹，不向外发送用户信息；唯一的网络调用是每周下载一次厂商公开模型页面，以更新价格。这些是作者对插件行为的说明，本文没有独立核验。

另有两个边界：使用最便宜的 Haiku 时，插件不做任何事；页脚的节省估算来自已测比例，并非对当前任务的实际测算。

我的判断

我认可先判断任务，再决定执行模型的方向。陌生仓库里的探索、复现和测试有明确产出，适合尝试委派；小文件修改收益有限，继续留在聊天里也合理。

但测试解决率打平，还不足以证明代码质量相同。 作者用一个小模型做盲评，0.3.0 的 diff 得分低于独立工作：在 0 到 2 的量表上，是 0.94 对 1.33。这个评审与测试结果只有弱相关，不能单凭它判定代码更差，也不能忽略这个信号。

此外，大任务只测了 Opus 5.5、high effort 和 Python 项目。Sonnet、Haiku、Fable 在大任务上的表现没有测，前端和 Node 项目也没有对应证据。

相比直接全程使用便宜模型，这套流程增加了最终审查；相比全程使用贵模型，它给出了特定样本上的成本收益。但原文没有提供前一种方案的对照数据，无法证明这是最优分工。小任务的路由阈值也仍是作者基于旧实验作出的经验选择。

能拿来做什么

• 如果你用 Claude Code 处理陌生仓库里的 bug，可以挑有稳定复现和测试的任务试用，同时记录总成本、返工次数和最终 diff 质量。
• 前端或 Node 团队可以借鉴「工作模型执行、聊天模型验收」的流程，但应先用自己的历史 issue 验证，不能直接沿用 Python 实验的 29% 降幅。
• 对单文件小改动，先维持现有流程；评估大任务时，则把测试通过率和人工审查分开记录，别用页脚估算代替实际账单。