Weave Router：让 Claude Code 自动切模型，省 40% token
Weave Router：一个 endpoint 让 Claude Code 自动切换 Opus 和 DeepSeek，省 40% token
用 Claude Code 写代码的，先收藏，这篇能帮你省钱。
一个很现实的问题：Opus 4.7 发布后，tokenizer 一改，账单直接起飞。但你心里清楚，不是每个请求都需要 Opus 的智商——子 agent 探索代码库用 DeepSeek V4 Flash 就够了，只有规划复杂改动那种才真正需要 Opus 4.8。
问题是你没法手动在每次请求前判断「这个该用哪个模型」。Weave Router 解决的就是这个。它是 Weave 公司开源的一个模型路由代理（workweave/router，Go 写的，262 stars），插在 Claude Code / Codex / Cursor 和模型提供商之间，每个请求自动选最优模型。官方数据：省 40-70% token，质量无感知差异。
关键不是「能切模型」（手动谁都会），而是它怎么决定切哪个。这点后面细说，跟市面上那些 prompt 决策的路由器不是一回事。
本文提纲
- 它到底怎么工作的
- 路由决策：embedder，不是 prompt
- 一行安装接入三大工具
- 一个真实的路由长什么样
- 跟手动切模型比，省在哪
- 自托管还是托管，怎么选
- 几个要注意的点
它到底怎么工作的
Weave Router 本质是个代理服务器。你把 Claude Code、Codex 或 Cursor 的 API endpoint 指向它（比如 localhost:8080），它就夹在中间干活：
graph LR
A[Claude Code / Codex / Cursor] -->|request| B[Weave Router]
B --> C{Route Decision < 50ms}
C -->|complex plan| D[Opus 4.8]
C -->|explore subagent| E[DeepSeek V4 Flash]
C -->|implement code| F[GLM 5.2]
C -->|simple query| G[Kimi K2.6]
D --> H[Translate + Forward]
E --> H
F --> H
G --> H
H --> I[Provider APIs]
style A fill:#FF6B6B,color:#000000
style B fill:#4ECDC4,color:#000000
style C fill:#FFEAA7,color:#000000
style H fill:#96CEB4,color:#000000它对外假装自己是 Anthropic、OpenAI、Gemini 三家的 API（各自的原生协议都支持：Anthropic Messages、OpenAI Chat Completions、Gemini native）。你发来的请求，它先看一眼，决定路由到哪个模型，然后把请求翻译成那个模型的协议格式转发出去，响应再翻译回来。streaming、tool use、vision 这些都透传，对客户端完全透明。
对你来说，Claude Code 还是那个 Claude Code，配置里只是把 base URL 换了一下。但背后每一次推理，可能在不同的模型之间跳。
路由决策：embedder，不是 prompt
这是 Weave Router 最值得说的地方，也是它和那些「写个 prompt 让大模型决定路由」的玩具项目本质区别。
市面上很多 router 的决策方式是：拿一个 LLM 看一眼请求，prompt 它「这个该用哪个模型」。问题是这个决策本身就要消耗 token 和延迟，而且 LLM 决策不稳定。
Weave Router 不这么干。它用的是一个本地运行的轻量 embedder（on-box，跑在你自己机器上），决策逻辑基于一篇论文叫 Avengers-Pro。工作方式大致是：
- 把进来的请求 embed 成向量
- 跟一个预先训练好的「cluster scorer」比对——这个 scorer 是 Weave 在数万条真实 agent traces 上用 RL 训练出来的
- 匹配到最合适的模型集群
整个决策在 50ms 以内完成，不经过任何 LLM，不产生额外 token 消耗。RL 训练时的奖励信号是：选中的模型成功完成了任务就给正反馈。所以 scorer 学到的是「哪类请求在哪个模型上实际成功率高、成本低」，不是「哪类请求看起来该用哪个模型」。
这个设计有几个好处。第一快，50ms 你感知不到。第二省，决策本身零 token。第三可解释，向量匹配是确定性过程，比 LLM 的「我觉得」可靠。
一行安装接入三大工具
接入方式简单到离谱。不需要 clone、不需要 Docker、不需要 Postgres：
npx @workweave/router这行命令会问你用哪个工具（Claude Code / Codex / opencode），选好后自动帮你改对应的配置文件——Claude Code 改 settings、Codex 改 ~/.codex/config.toml、opencode 改 opencode.json。你只需要提供 provider key，其他全自动。
如果不想用交互式选择，直接带参数：
npx @workweave/router --claude # 直接配置 Claude Code
npx @workweave/router --codex # 直接配置 Codex
npx @workweave/router --scope project # 只对当前 repo 生效，配置 commit 进项目Cursor 是 early beta（README 自己标注性能可能不是最佳），需要在 Settings → Models 里 Override OpenAI Base URL 指向 http://localhost:8080/v1，手动填 rk_... 路由 key。
这里有个设计细节值得注意：Codex 的配置改动是非破坏性的。它只增删自己管理的 [model_providers.weave] 块，你 Codex 里其他配置原封不动。--uninstall 也只移除这个块。这点对开发者很友好——不用担心装了个工具把自己的配置搞乱。
而且装完之后可以随时开关切换，不用反复改配置：
npx @workweave/router off --claude # 路由关闭，直连原 provider
npx @workweave/router on --claude # 路由开启
npx @workweave/router status # 看当前状态Claude Code 甚至有 /router-off、/router-on 斜杠命令，在对话里直接切。
一个真实的路由长什么样
Weave 在 HN launch 帖里给了一个具体例子，能直观看出路由逻辑：
| 请求类型 | 路由到的模型 | 为什么 |
|---|---|---|
| 规划复杂改动 | Opus 4.8 | 需要强推理，规划错了后面全白干 |
| 子 agent 探索代码库 | DeepSeek V4 Flash | 只是收集上下文，不需要强推理，快且便宜 |
| 执行已定好的方案 | GLM 5.2 | 方案明确，执行靠速度和成本 |
| 简单查询 | Kimi K2.6 | 杀鸡不用牛刀 |
这个分层很关键：不是所有任务都用最强模型才好。规划阶段用 Opus 保证方向对，执行阶段用便宜模型保证快和省。如果你全程 Opus，既贵又未必快；全程 DeepSeek，省钱但复杂规划可能翻车。Weave Router 的价值就是让你每个环节都用对模型，而不是全局二选一。
跟手动切模型比，省在哪
有人会说：我自己在 Claude Code 里 /model 切不就行了？
能切，但切不动几个问题。第一，你得知道什么时候切。写代码写到一半，你判断不了当前这个请求是「需要 Opus 的规划」还是「DeepSeek 就够」——这是路由器擅长而你手动判断成本高的事。第二，一个 agent loop 里请求是混合的。Claude Code 一次任务可能发几十个请求，规划、探索、执行交织在一起，你不可能逐个手动切。第三，手动切容易忘切回去，要么一直贵，要么该用强模型时还在用便宜的导致质量下降。
Weave Router 是 per-request 粒度的，每个请求独立决策。同一个任务里，规划那个请求走 Opus，紧接着探索代码库的子请求就走 DeepSeek，你全程不用管。40% 的节省就是这么来的——把那些「用了 Opus 但其实不需要」的请求路由到了便宜模型。
成本数据可以感受一下量级：Opus 4.8 的输入价格是 DeepSeek V4 Flash 的几十倍。如果一个 agent loop 有 20 个请求，其中只有 3 个真需要 Opus，其余 17 个路由到 DeepSeek，省下的就是实打实的钱。
自托管还是托管，怎么选
Weave Router 提供两种用法：
托管版（推荐先试）：npx @workweave/router 默认连 Weave 的 hosted router，你的 provider key 加密存在本地，请求经 Weave 的路由服务分发。零运维，适合个人开发者快速验证。
自托管版：自己跑整个 stack（router + dashboard + Postgres），适合不想把请求经过第三方、或者要在内网用的团队：
echo "OPENROUTER_API_KEY=sk-or-v1-..." >> .env.local
make full-setup # 起 Postgres + router:8080 + dashboard，自动生成 rk_ key自托管有个亮点：dashboard 在 localhost:8080/ui/，能看到每次路由决策去了哪个模型、为什么。对调试和优化路由策略很有用。
两种模式都支持 BYOK（Bring Your Own Key）——provider key 始终在你自己手里，加密存储。这点对安全敏感的团队很重要，你的 OpenAI / Anthropic / DeepSeek key 不会上传到 Weave。
可观测性也做得完整，原生 OTLP trace 输出，能接 Honeycomb、Datadog、Grafana。路由决策过程不是黑盒，每次都能追到。
几个要注意的点
许可证是 ELv2（Elastic License 2），不是 MIT/Apache。ELv2 允许你自由使用、修改、自托管，但禁止把它作为托管服务提供给第三方。个人用和公司内部用没问题，但你想拿它做个 SaaS 卖给别人，不行。商业集成前看清楚这条。
Cursor 是 early beta。README 自己写了「performance may not be the best」。Cursor 的集成方式是手动改 Base URL，不如 Claude Code / Codex 那种自动配置顺滑。Cursor 用户建议先在 Claude Code 上体验，等 Cursor 集成稳定。
托管版请求经过 Weave。虽然 key 加密存储、协议透明，但你的请求内容确实会过 Weave 的路由服务。如果这点介意，用自托管版，全程不出你的机器。Weave 本身是做工程智能平台的公司（客户有 Robinhood、PostHog），可信度还行，但安全合规严格的团队建议自托管。
路由质量取决于你启用的模型池。router 只能在你配置的 provider 里选。如果你只配了 OpenAI 一个，它没得选。要发挥效果，至少配 2-3 个价差大的模型（比如 Opus + DeepSeek + GLM），让它有路由空间。OpenRouter 是推荐的 baseline provider，一个 key 接一堆 OSS 模型。
Weave Router 抓住的是一个真实且越来越普遍的痛点：AI 编程成本在涨，但没人想为了省钱牺牲关键任务的质量。它的解法不是让你在「贵但强」和「便宜但弱」之间二选一，而是让每一类请求各得其所。如果你日常用 Claude Code 或 Codex 且对账单敏感，值得花十分钟装上试试——hosted 版零成本验证，数据说话。
参考文档与链接
- GitHub: workweave/router — 262 stars，Go，ELv2 许可证，模型路由代理
- Hacker News Launch 帖 — 135 points，作者 adchurch 讲述动机（Opus 4.7 token 成本飙升）与 RL 训练细节
- Weave Router 官方介绍 — 路由机制、三大 API 支持、可观测性
- Avengers-Pro 论文 (arxiv 2508.12631) — 路由决策算法的理论基础
- 30 秒快速开始 —
npx @workweave/router一行安装接入 - 工具集成文档 — Claude Code / Codex / opencode / Cursor 配置方式
- Weave 官网 — 母公司，工程智能平台，客户含 Robinhood、PostHog、Reducto
- OpenRouter — 推荐的 baseline provider，一个 key 接 DeepSeek/Kimi/GLM/Qwen 等 OSS 模型
用 Claude Code 的，账单超多少了？装上这个试试能省多少，评论区报个数。觉得有用点个赞让更多人看到。
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
