【脱・浪費】ClaudeやCursorでLLMのコストを4割削減！賢いモデルルーティングツール「Weave Router」が登場

Claude CodeやCursor、Codexといったコーディングエージェントに組み込むだけで、AIモデルへのリクエストを賢く振り分ける「モデルルーター」を開発しました。ローカル環境での動作デモはこちらです：https://www.youtube.com/watch?v=isKhAyivtfM 。私たちは普段、ほとんどのコードをAIで書いていますが、開発コストの増大が悩みの種でした。特にOpus 4.7のリリース時はトークン体系の変更でコストが急騰。「すべてに最強モデルを使う必要はないが、肝心なところで知能を落としたくない」というジレンマを解決するため、今回のルーターを自作しました。Weave RouterはAnthropicやOpenAIのAPIエンドポイントとして振る舞い、各リクエストを解析して最適なモデルへ自動的にルーティングします。DeepSeek v4、GLM 5.2、Kimi K2.6などの軽量・高速なモデルと、Opus 4.8やGPT 5.5といったフロンティアモデルを、タスクの難易度に応じて使い分けます。判定ロジックには、数万件のエージェントトレースを学習させた強化学習モデルを採用しており、タスクを成功させた場合に報酬を与えることで最適化しています。例えば、複雑な変更計画にはOpus 4.8を、コードベースの検索にはDeepSeek V4 Flashを、実装フェーズには高速なGLM 5.2を割り当てるといった具合です。実際に1ヶ月間社内で運用した結果、品質や速度を損なうことなくトークンコストを40%削減できました。本ルーターはElastic License 2.0でソースコードを公開しており、セルフホストも可能です。ホスト版の利用をご希望の方は weaverouter.com からどうぞ。気になる点があれば何でも聞いてください！

こうしたルーターで私が腑に落ちないのは、キャッシュミスが確実に増えるってこと（5分TTLだし）。一つ言えるのは、キャッシュの活用は死活問題だってことだよ。開発コストの面で、このルーターを使うと実際どういう計算になるわけ？

いやー、正直これを使おうという気にはなれないな。というのも、自分が使うプロンプトって使用するモデルに合わせて既に調整してるから。自分の言い回しとかに合わせて適切にルーティングしてくれるのか、いまいち信用できないよ。

私は評価用の本番データとホールドアウトデータを使って、固定したモデルバージョンにプロンプトを自動チューニングしてるよ。これの用途って、一度きりの対話型プロンプト向けってこと？現状は全部 Opus 4.8 MAX で回してるし、ダウングレードもできるだろうけど、対話用だと最初のプロンプトがマルチターンのセッション全体で目指すゴールを反映してるとは限らないんだよね。オンザフライのルーティングが、クラスごとにモデルやバージョンを固定して、評価や自動チューニングで最適化していくやり方に勝てる理由がどうしてもわからない……。

Claude Code みたいにエージェント的なコーディングをする場合、プロキシ層でこれをやるのはかなり難しいよ。これらはツール使用の長い連鎖セッションで、プロンプトキャッシュに大きく依存してるからね。途中でモデルを切り替えるのはコストがかさむ。最適なモデルを決めるにはもっと多くのコンテキストが必要そうだし（例えばログの要約なら安いモデルでいいけど、マルチスレッドのデバッグなら Opus/Mythos/GPT 5.6 が欲しいだろうし）。エージェントシステムの場合、どのモデルを使うかの判断は、モデルに作業を指示するプロセスそのものに組み込まれているべきだと思う。

個人的には、これといって大きなメリットがあるようには思えない。キャッシュとリクエストごとの最適なルーティングって相性が悪いから。会話で使うモデルの種類が増えるほど、キャッシュミスを受け入れなきゃいけなくなる。「別のモデルに切り替える閾値が高くなる」っていうOPのコメントを信じるなら、結局は実質2つのモデルに絞られることになるわけだ。プランナーとエグゼキューターの2モデル構成なら、既にその用途には十分だし。2つ未満なら単なる単一モデルのキャッシュ保持会話で、わざわざ別の層を挟む必要はない。3つ以上なら、多くのゲインを打ち消すほどの大きなキャッシュペナルティを払うことになるだろうね。

APIコストが問題になってきている今、モデルルーティングを解決しようとする試みが増えるのは嬉しいよ。いくつかフィードバックを：1. 他のコメントでも指摘されてるけど、キャッシュの問題を再確認してほしい。現状の仕組みはキャッシュ周りの最適化が強力で、プロキシモデルを挟むとそれが台無しになる。2. コーディングエージェントは既にモデルを使い分けてるよ。コード探索にはmini/flash系、計画にはヘビーモデル、ワークフロー設計にはウルトラ系、実装には中〜高位モデル……といった具合にね。探索中なのか計画中なのか、実装中なのかレビュー中なのか、どのモデルクラスを選ぶべきか、そしていつ失敗するかも把握してる。プロキシを挟むと、この制御ループとフィードバックを壊すことになる。DeepSeek v4で試して失敗したから次はOpusを試そう、といった判断ができなくなる。3. 強化学習でどうやって改善し、ルーターの陳腐化を防ぐつもり？自分たちの内部プロンプトと数千のサンプルしかアクセス権がないだろ。特定の組織のコードベースでRLしたところで、未知のプロンプトなんて山ほどあるし、ユーザーのフィードバックデータも手に入らない。他社がトレースを共有してくれるはずもないし、改善するためのデータソースはどう確保するのか。毎週のようにリリースされる新しいモデルへの追従はどうするのか。4. TerminalbenchやDeepswe benchの結果を公開してほしい。既存のエージェントやモデルセットと比べた性能/コスト/時間のチャートを見せてくれれば、コスト削減分からパーセンテージをチャージするというシンプルな価値提案ができるはず。

Cursorは既に似たようなことをやってるね。Opus 4.8を選択していても、Composer 2.5を使ってサブエージェントを動かしたりする。個人的にはAutoを使うと効果的で割引も効くから好きだけど、仕事ではYOLOの精神でOpusを全開で使ってる。こういうソリューションは、いずれ企業が強制的に導入するものになると思うよ。個人の開発者がモデルの価格をいちいち選別する理由なんてないからね。MCP経由で「アナリティクスの概要を全出しして」なんてリクエストを投げて30分放置するような、非エンジニアユーザーにとっても重要だと思う。

興味深いね！ちょっと気になったんだけど、vLLM Semantic Routerと比較するとどうなんだろう？例えば、似たようなアルゴリズムを提供してるのかな？vllm-sr/autoやfusion、flow、remomみたいな機能はある？routeworks.github.ioのリーダーボードで見る分には良さそうだけど。

これを設定する余裕があった頃なら面白がっただろうな。今はGitHub Copilotのサブスクを維持するだけで手一杯で、毎月のWebサイトの最小限の更新すらカツカツ。お試しや趣味のプログラミングプロジェクトなんてやってる暇もない。月数百ドルもこういうプロダクトに突っ込めるわけがないから、利用を制限して、もっといいローカルモデルを探して、ツールが本当に時間を節約してくれるのかを見極めるのに必死だよ。生きていくのも大変な時代だね……。

実装の計画フェーズで大きなタスクをサブタスクに分解して、タスク定義の一部としてスコープに基づいた理想的なモデルを記録しておく方法と、これって何が決定的に違うの？