workweave/router

複数のLLMプロバイダの前に置くプロキシです。Anthropic・OpenAI・Gemini のエンドポイントの差し替え先として動くので、呼び出し側のコードは基本そのままで、向き先だけを変える形になります。

肝は選び方です。サーバー内で動く小さな埋め込みモデル（ONNX）がプロンプトをその場で読み、Avengers-Pro という論文（arXiv:2508.12631）から起こした「クラスタスコアラー」が投げ先を決めます。README は50ミリ秒以下で振り分けると書いています。ルールを人が書くのではなく、プロンプトの中身から判断させる方向です。

置き場所は2通りあります。手元で動かす（8080番）か、Weave の管理するクラウドを使うか。手元で動かす場合、ルーター・スコアラー・Postgres・各プロバイダのキーはすべて自分の側に留まり、プロンプトはプロバイダへ直接送られます。

使うモデルが増えて、振り分けの判断がコードに散らばってきたとき

「この処理は安いモデル、この処理は賢いモデル」という分岐は、最初は if 文ひとつで済みます。増えてくると、条件があちこちに散って手が入れづらくなります。その判断を一箇所に外に出す、という選択肢になります。

キーとログを自分の側に置いたまま、複数プロバイダを試したいとき

手元で動かす構成なら、鍵もデータベースも外に出ません。プロバイダを乗り換えるときの比較を、自分の環境の中でやれます。

ライセンスが Elastic License v2 です。ここがいちばん重要です。 これはオープンソースライセンスではありません。同等の管理サービスとして第三者に提供することが制限されます。社内で使うぶんには問題になりにくいですが、これを組み込んだサービスを売る計画があるなら、条文を読んでから決める必要があります。ライセンス欄が空欄（NOASSERTION）に見えるのも、定型のオープンソースライセンスとして扱われないためです。

README の数字には根拠が付いていません。 「コストを40〜70%削減」と掲げていますが、その裏付けになる測定条件や結果は書かれていません。あわせて注意したいのは、Robinhood や PostHog の名前が挙がっているのは、このルーターではなく開発元 Weave の別製品についての記述だという点です。導入実績として読むと見誤ります。Cursor との連携は初期ベータで性能が最適でない場合がある、と自ら断っています。

まだ若いプロジェクトです。 公開から4か月、貢献者10人。振り分けの判断が変われば出力も変わる性質のものなので、バージョンを固定して使うかどうかは先に決めておいたほうがいいです。