ハクソク

世界を動かす技術を、日本語で。

Show HN: Claude、Codex、Cursorにおけるスマートモデルルーティング

2026年6月27日原文(github.com)

概要

Weave Router は、Anthropic、OpenAI、Geminiなど複数のAIモデルを一つのエンドポイントで自動選択・利用できるルーター。 コーディングエージェント （Claude Code、Codex、Cursor等）に最適化されており、コストと品質を両立。 RLモデル で最適なモデル選択を自動化し、最大40%のトークンコスト削減を実現。 セルフホスト も可能で、セキュリティや拡張性も確保。 導入・切替が簡単 で、主要なAPI互換性やダッシュボードも標準装備。

Weave Routerとは

  • 複数AIプロバイダー （Anthropic, OpenAI, Gemini, DeepSeek, GLM, Kimi, Llama, Mistral等）を一つの プロキシエンドポイント で利用可能
  • 最適なモデル選択 をリクエスト単位で自動実行、Avengers-Pro 1由来のクラスタースコアラーを活用
  • API互換性 ：Anthropic Messages、OpenAI Chat Completions、Gemini generateContent等に対応
  • OSSモデル対応 ：OpenRouter経由で各種OSS LLMも利用可能
  • セキュリティ ：プロバイダーキーはローカル保存＆暗号化、BYOK（Bring Your Own Key）方式
  • 可観測性 ：OTLPトレースをWeaveダッシュボードやHoneycomb、Datadog、Grafana等で可視化可能

導入・セットアップ方法

  • 最速導入 ：npx @workweave/router コマンド一発でホスト版Weave Routerに接続
    • Claude Code、Codex、opencodeへの対応をインストーラーが自動案内
  • カスタマイズオプション ：
    • --claude / --codex / --opencode：特定ツール専用
    • --scope project：プロジェクト単位で設定
    • --local：ローカルセルフホスト
    • --base-url：独自エンドポイント指定
    • バージョン固定も可能（例: npx @workweave/router@0.1.0）
  • セルフホスト手順 ：
    • .env.localにプロバイダーキー（例: OPENROUTER_API_KEY）をセット
    • make full-setup でPostgres＋Router＋Dashboard起動
    • ローカルダッシュボードやAPIエンドポイント利用可能

各コーディングエージェントとの連携

  • Claude Code ：make install-ccでローカルRouterに自動接続
  • Codex (OpenAI CLI) ：npx @workweave/router --codexで設定ファイル自動パッチ
    • OPENAI_API_KEYは既存フロー維持、RouterキーはX-Weave-Router-Keyヘッダーで送信
  • opencode ：npx @workweave/router --opencodeで設定ファイル自動統合
    • Anthropic Messages API互換でopencodeがそのまま利用可能
  • Cursor （ベータ）：Settings→Models→Override OpenAI Base URLでRouter利用、APIキー入力

切替・管理方法

  • on/off切替 ：npx @workweave/router off/on --claude等で直接切替、configは維持
  • 状態確認 ：statusコマンドや/routeエンドポイントでルーティング状況チェック
  • キー管理 ：
    • sk-...：プロバイダーキー（.env.localに保存）
    • rk_...：Routerキー（Bearerトークンで送信）

主要APIエンドポイント

  • POST /v1/messages：Anthropic Messages互換
  • POST /v1/chat/completions：OpenAI Chat Completions互換
  • POST /v1beta/models/:action：Gemini generateContent互換
  • POST /v1/route：ルーティング決定のみ返却
  • GET /v1/models、/health、/validate等：各種情報取得・ヘルスチェック

ルーティングアルゴリズムとコスト削減

  • RLモデル （強化学習）で数万件のエージェントトレースを学習
    • タスク内容に応じて最適なモデル（高速・安価なDeepSeek V4やGLM 5.2、必要時のみOpus 4.8やGPT 5.5等）を自動選択
  • 実績 ：社内利用で40%のトークンコスト削減、品質・速度への影響なし

ライセンス・拡張性

  • Elastic License 2.0 による ソース公開、セルフホスト可能
  • ホスト版サービス （weaverouter.com）も利用可能
  • ドキュメント ：環境変数、BYOK暗号化、OTel設定、エンドポイント追加方法等を網羅

まとめ・導入メリット

  • 一つのエンドポイント で最適なAIモデルを自動選択
  • 開発コスト・運用コスト削減 と 品質維持 を両立
  • 主要なコーディングエージェントと簡単連携
  • セルフホスト・拡張性・可観測性 も充実
  • Weave Router は、AIコーディングエージェントの運用を効率化したい開発組織に最適

Hackerたちの意見

このルーターのことがよくわからないのは、キャッシュミスが増える（TTLが5分）ってことなんだよね。で、俺が学んだことの一つは、キャッシュを使うのがめっちゃ重要だってこと。これって、開発する時にどうやって$$$に繋がるの？

└

その通り！だから、キャッシュを意識したルーターを作ったんだよ！一つのモデルを使い始めると、別のモデルに切り替えるための閾値が高くなるんだ。キャッシュミスの追加コストが、コスト削減や品質向上に見合う必要があるからね。これが他のルーターが見落としている重要な点なんだ。ステートレスだから、コーディングエージェントのケースでは、キャッシュミスのせいで余計にお金がかかっちゃうんだよね。

└

アーティファクトベースのワークフローがこの問題を解決すると思うし、その方向に進むのがもっと効果的だと思う。Opusが良いプランを作るからClaude Codeを使ってるけど、そのプランをM3に渡して99.9%のキャッシュヒットで長時間セッションをこなしてる。素晴らしいよ。Piはその後、Opusがコードやコンテキストをレビューできるようにサマリーファイルを作る。でも、彼らに自分のことを書き留めてもらう必要があるから、圧縮や明確なセッションが良い文書から機能するんだ。そして、単にClaude Codeを使っているなら、/advisorが必要だよ。もっとクリーンなコンテキストを持つサブエージェントが何かを処理するために生まれるんだ。キャッシュされてるわけじゃないけど、運用コストはかなり安い。キャッシュミスを許容できない限り、モデル間を自動でルーティングするワークフローには近づかない方がいい。それがGLM 5.xが高くつく理由でもあるし、良いキャッシングが得られないんだ。

うーん、こういうのを使うかどうかはちょっと疑問だな。だって、俺のプロンプトの出し方は使ってるモデルによって変わるから。自分の言い回しや何かに基づいて、正しいモデルにルーティングされるとは思えないんだよね。

└

そうそう、これがカーソルで「自動」モードを避ける理由だったんだよね。

└

それ、めっちゃ面白い指摘だね。正直言うと、ここでのもっと重要な変数は特定のモデルよりも使ってるハーネスだと思う。例えば、ClaudeハーネスでのGPT 5.5は、CodexよりもClaudeに近い動きをするんだよね。これを定量化するのは難しいけど、ここ1ヶ月使ってみて感じたことだよ。

└

うーん、こういうのを使うかどうかはちょっと疑問だな。だって、使うモデルによってプロンプトの出し方が変わるから。もしかしたら、君にはあんまり合わないかもね。普通の人がプロンプトを出すときの方がうまくいくかもしれない。

プロダクションデータを評価データとして使って、ロックされたモデルバージョンにプロンプトを自動調整してるんだ。一回限りのインタラクティブなプロンプトには使えるかも？今のところ、全部Opus 4.8 MAXで試してるけど、ダウントーンできると思う。ただ、インタラクティブなセッションでは、最初のプロンプトが全体の目標を反映してるわけじゃないんだよね。なんでその場でのルーティングが、テストや調整、各クラスのコールに対してモデルとバージョンをロックするのに勝るのかを考えてるところなんだ。評価や自動調整を使って、よく使うプロンプトのクラスに対して、もっと可能性のあるモデルを探るためにね。

└

「あなたのサブスクリプションティアとローカルハードウェアに基づいて、あなたの最高の頭脳が快適に処理できるモデルのリストとプロセス定義があります。」これって、評価や自動調整をサードパーティに移すような感じがするけど、そんなシステムをゼロから作って、それを常に関連性を持たせるための時間も予算も気力もないよ。オンザフライのルーティング情報を提供するものは役立ちそうだけど、実際の意思決定は文脈に依存しすぎてると思う。

エージェント的なコーディング、例えばClaude Codeみたいなのだと、プロキシレベルでやるのは結構難しいんだよね。これらはツール使用の長いチェーンセッションで、プロンプトキャッシングに大きく依存してる。途中で変更するのはコストがかかるし、最適なモデルを決めるにはもっと多くのコンテキストが必要なんだ（例えば、ログを要約するのには安いモデルを使うかもしれないけど、マルチスレッドロジックをデバッグするにはOpus/Mythos/GPT 5.6が欲しいよね）。エージェントシステムでは、モデルに関する決定がモデルをオーケストレーションする決定に埋め込まれているかもしれない。

└

そうそう、キャッシュの意識はめっちゃ重要だよね。ここでも別のスレッドで言ったことがあるよ：（https://news.ycombinator.com/item?id=48689448）直感的に、関連情報があればモデルがどのモデルにルーティングするかを学べるのは理にかなってると思うし、実際にうちの経験ではかなりうまくいってるよ。

これって、実際にはあんまり意味のあるメリットがないと思うな。キャッシングと単一リクエストの最適ルーティングは相反するからね。会話の中でモデルの種類が増えれば増えるほど、キャッシュミスが増えることを受け入れなきゃいけない。OPが他のところで言ってた「別のモデルに切り替える閾値が高くなる」っていうのは、要するにワークフローを最大で2つのモデルに減らすってことだよ。2モデルの構成、つまり1つのプランナーと1つのエグゼキューターがあれば、十分なケースだと思う。2モデル未満なら、単純なシングルモデルのキャッシュを保つ会話で、別のレイヤーは必要ないんじゃないかな。2モデル以上になると、大きなキャッシュペナルティを支払うことになって、ほとんどの利点が消えちゃうよ。

Hacker Newsで議論の続きを見る