Weave Router（GitHub: workweave/router）是一个“LLM 请求路由层”工具，本质是一个放在大模型 API 前面的代理（proxy），用来自动决定每个请求该用哪个模型。
机器管家替你做主：该让哪个AI写代码更省钱
Weave团队用AI写代码，结果Opus 4.7一改分词器，账单直接飞起。他们意识到不能所有活儿都让最强大脑干，但又不想关键时刻掉链子，于是造了个路由器。
这东西插在Claude Code、Codex、Cursor这些编程助手前面，自动把请求发给最合适的模型。
自己用了大概一个月，省了百分之四十的token开销，质量速度还没啥区别。路由器的路子是用强化学习，在成千上万个代理轨迹上练出来的，谁完成任务就奖励谁。现在源代码用Elastic License 2.0授权，你可以自己托管，也可以直接用他们网站的服务。
路由器替你把关哪个AI干活
这个叫Weave Router的家伙，本质上就是个大模型API门口的智能门卫。它假装自己是Anthropic或者OpenAI的接口，专门伺候那些编程代理。每个推理请求进来，它都要瞅一眼，然后动脑子决定该派哪个模型上阵，还得负责翻译不同模型之间的暗号。这么一来，简单活儿就能让DeepSeek v4、GLM 5.2、Kimi K2.6这些又快又便宜的家伙去干，碰到硬骨头再请Opus 4.8、GPT 5.5这种顶尖高手出马，连那个神出鬼没的Fable回来也算上。
你看那些coding agent干活，就像派了一堆小弟去翻代码库找线索，这种跑腿活儿根本不用杀鸡用牛刀。路由器心里门儿清，知道哪些任务耗脑子，哪些就是个体力活。比如你要规划一个牵一发动全身的大改动，它大概会把活儿派给Opus 4.8这种战略大师。要是小弟们去代码库里东翻西找搜集上下文，就让他们用DeepSeek V4 Flash这种跑得快又不贵的。等计划整好了开始动手实现，大概率就交给GLM 5.2这种执行效率高的去干。这不就像工地上的包工头，砌墙的活儿让瓦工干，绑钢筋的活儿让钢筋工干，谁也别闲着，谁也别累着。
这帮人自己先用上了，一个月下来省了四成token开销。关键是质量没掉链子，速度也没拖后腿。你想啊，他们公司本身就是搞工程效率量化分析的，要真把活儿干砸了，那不是砸自己招牌嘛。所以他们敢拍胸脯说，代码出的bug没多，返工率没涨，速度还往上走了走。
路由器脑子怎么长的
这路由器可不是傻乎乎地看提问长短来分活儿。它肚子里装了个轻量级ONNX模型做embedding，能把每个请求映射到不同的任务簇里头去。简单补全、中等推理、高难度烧脑题，它分得门儿清。但真正厉害的地方在于，它不是只盯着质量看，而是搞多目标优化。成本、延迟、输出啰嗦程度、质量够不够用，这些它都得掂量。最终挑那个能让质量达标，同时又最便宜跑得最快的模型。
训练这家伙用的是强化学习，喂了成千上万条真实代理干活儿的记录。路由器每选一个模型去干活，干成了就有奖励，干砸了就没糖吃。这么一来二去，它就慢慢摸清了什么活儿该找什么人。这小子的判断可不是瞎蒙，它会看整个提示词和之前的对话上下文，用embedding把问题归类，再根据历史经验判断哪个模型对付这类问题最拿手。最逗的是，它还会汲取教训。要是某个小模型在某种任务上老翻车，路由器就会记黑账，下次尽量不让它碰这活儿。
当然，这玩意儿也不是算无遗策，万一选错了人也没关系。它兜里还揣着备胎方案，发现小模型卡住了，会立刻叫个大模型来救场。就像你让实习生去干个活儿，他干到一半不会了，马上就有老师傅接手，不至于把整个项目拖黄了。
专治各种换模型烧钱
以前大家用AI写代码，最简单的办法就是逮着一个最牛X的模型用到地老天荒。这么做省心是省心，但钱包真心扛不住。尤其现在这些模型公司三天两头改算法，就像Opus 4.7那次改了分词器，同样的代码愣是多算出一堆token来，账单直接膨胀。很多公司一算账，发现搞AI编程的成本都快赶上雇几个初级程序员了。
Weave这帮人琢磨出一个道理，很多活儿根本就不值得动用最强大脑。比如让AI帮你改个变量名，格式化一下代码，或者补全个括号，这种事儿杀鸡用牛刀，纯粹是烧钱玩儿。但你又不能一刀切全用便宜模型，万一碰到真需要推理能力的时候，便宜模型给你瞎编一通，回头debug的时间成本可能比省下的token还贵。所以他们要的不是选最好的模型，而是选性价比最高的模型。
这路由器装上去之后，它会在每个请求上动脑筋，判断这活儿到底值不值得请大腕儿。结果就是，你花在AI上的钱变少了，但活儿干得还是一样利索。这帮人说省了四成开销，搁谁谁不心动。很多大公司没有补贴价，都是按API原价付费，AI用多了那个账单看得人心惊肉跳。一个路由器能把钱省下来，又不耽误进度，这不就是老板们最爱听的故事嘛。
缓存这件事被玩明白了
这路由器有个特别鸡贼的设计，就是它懂什么叫缓存。用过AI编程的都知道，API调用的缓存是个省钱的大杀器。你连续跟同一个模型聊天，前面说过的话都被缓存了，后面的请求只需要花很少的钱就能续上。但一旦你换了模型，缓存就废了，所有上下文得重新传一遍，那可都是白花花的银子。
很多搞模型路由的人压根儿没想过这事，他们只看到眼前的请求该归谁，不管之前跟谁唠过磕。这么干看起来每次可能省了点，但算上重建缓存的成本，搞不好还更贵了。Weave这个路由器就聪明在这儿，它是有状态的，会记住当前会话在用哪个模型。一旦确定了一个模型，它就不会随便换人，除非换模型的收益明显大于丢失缓存的损失。
这帮人说，在实际使用中，一个典型的代理主循环大概就用到一到三个模型，具体看情况。但那些子代理就灵活多了，因为每个子代理都有自己全新的上下文窗口，互相不干扰，所以路由起来自由度更大。所以路由器做决策的时候，会把换模型的代价算进去，第一次选模型特别关键，但如果用户的提问突然转了方向，该换还得换。
自托管还是抱大腿随你挑
这路由器有两种玩法，一种是自己搭，一种是直接用他们的云服务。自己搭的话，一行命令就搞定了，用那个npm包跑个本地服务就行。这么做的好处是所有数据都不出你的机器，隐私安全绝对放心。你用自己的API key，想接哪个模型接哪个，完全自己说了算。对于那些对数据安全有洁癖的公司，或者想在自己VPC里折腾的团队，这条路很合适。
另一种就是直接用他们托管的版本，连安装部署都省了。他们帮你打理OpenAI、Anthropic、Gemini、OpenRouter这些接口，统一计费，还给你个仪表盘看各种指标。很多客户选这条路，反正本来就信得过这帮人，交出去的敏感数据也不差这一桩。不管选哪种，你都可以在Claude Code、Codex、Cursor、opencode这些工具里把base URL一改，路由器就开始干活了。
最重要的是，这玩意儿用起来不会把你锁死在一个模型上。你可以继续用你最顺手的那几个模型，路由器只是在背后默默帮你优化成本。哪天你觉得它选得不对，随时可以手动干预，或者干脆不用。这种你随时可以踹开的感觉，反而让人敢放心用。
这事儿到底值不值得折腾
肯定有人说，我习惯了手动切模型，或者我就认准一个模型用到底，干嘛要多加这一层。这话没毛病，对于那些单一模型就能搞定的小项目，或者对延迟要求特别变态的实时场景，加个路由器确实有点画蛇添足。但对于那些天天跟AI编程助手泡在一起，一跑就是几十轮对话的重度用户来说，这玩意儿就像发现新大陆。
那些公司里的工程领导现在最头疼的就是AI账单。Uber的COO都出来公开吐槽过token花得太猛了。这帮人搞了个路由器，让每块钱都花在刀刃上，能不香吗。还有人担心，你路由器再聪明，能有人聪明吗。我手动切模型的时候，会根据模型特点调整提示词，路由器能懂这个吗。这个问题问到点子上了，这帮人的回答也挺逗，说影响路由效果的主要是工具链本身，而不是具体哪个模型。同样一个GPT 5.5，在Claude Code里表现得更像Claude，在Codex里又像Codex了，这东西不好量化，但用了一个月感觉确实如此。
还有人说，你这么换来换去，把缓存都搞没了，省的钱还不够填坑的。但这路由器本身就是冲着解决这问题来的，它知道什么时候该换，什么时候不该换。别人踩过的坑它都绕着走了，所以人家才敢说省了四成。未来的趋势肯定是大模型公司自己也会做类似的东西，但他们没有动机把流量往别的模型引啊。Anthropic怎么可能鼓励你把Claude Code的流量导给DeepSeek，那不是砸自己饭碗嘛。所以这事还得第三方来干。
总结
Weave Router让AI编程助手学会看人下菜碟，用强化学习给每个请求挑最合适的模型，连缓存损耗都算进去了，省了四成token还不耽误活儿。