9routerとは｜Claude Code・Cursorを1つに束ねるAIルーターを類似OSSと比較

「Claude Code がまた使用上限に達した」「Codex と Cursor を別々のサブスクで契約しているが、どのプロバイダーが今使えるのか分からない」「git diff や grep の出力でコンテキストが膨らみ、月のクォータが月末まで持たない」――AI コーディングツールを日常的に使うエンジニアにとって、こうした悩みは年々大きくなっています。

特に 2026 年に入ってからは iFlow・Qwen・Gemini CLI など一部の無料枠が縮小・終了し、複数プロバイダーを使い分けるニーズが高まっています。一方で「Claude Code は Anthropic」「Codex は OpenAI」「Cursor は独自エンドポイント」と接続先がバラバラで、CLI ごとに設定を変えるだけでも手間がかかります。

こうした「CLI と LLM プロバイダーの組み合わせ爆発」を、ローカルで動くゲートウェイ 1 つに集約しようとする OSS が 9router です。スター数は 10,436、Fork 数は 1,603 と、2026 年 1 月の公開からわずか数カ月で急速に注目を集めています（出典: GitHub repository）。

本記事は、9router の README・公式ドキュメント・関連プロジェクトを横断的に調査した内容を整理した、ドキュメントベースの紹介記事です。動作検証や実行結果は含まず、「自プロジェクトで採用すべきか」を判断するために必要な情報を、類似 OSS との比較を交えて解説します。

具体的には、9router の機能・仕組み・対応範囲を整理したうえで、検索意図が部分的に重なる free-claude-code や、原実装である CLIProxyAPI との違いを掘り下げます。最後に、9router が向くユーザー像と採用前に確認すべき観点をまとめます。

9routerとは何か

9router は、AI コーディングツール（Claude Code / Cursor / Codex / Cline / GitHub Copilot / Antigravity など）と、40 以上の LLM プロバイダーの間に立つ、ローカル動作の AI ルーター（プロキシゲートウェイ）です。ライセンスは MIT、実装は JavaScript（Node.js 20+ / Next.js 16）で、npm・Docker Hub・GHCR から配布されています。詳細は 9router の GitHub リポジトリ を参照してください。

公式の説明文では Unlimited FREE AI coding. Connect Claude Code, Codex, Cursor, Cline, Copilot, Antigravity to FREE Claude/GPT/Gemini via 40+ providers. Auto-fallback, RTK -40% tokens, never hit limits. と表現されています（出典: GitHub repository description）。要するに「複数の AI コーディング CLI を、複数の LLM プロバイダーに束ねて流す」ためのツールです。

9routerが解決する5つのペイン

README の「Why 9Router?」セクションを読み解くと、9router が想定する課題は次の 5 つに整理できます（出典: GitHub README）。

1. サブスクリプションのクォータが余ったまま月末を迎える、または逆に月の途中で枯渇する
2. レート制限にぶつかると、その CLI 自体が一時的に使えなくなる
3. tool_result（git diff・grep・ls などの出力）でプロンプト予算の 30〜50% が消費される
4. API キーで直接モデルを呼ぶと月数百ドル規模のコストになり得る
5. プロバイダーを切り替えるたびに、CLI 側の設定や認証を手作業で変えなければならない

9router はこれらを「ローカルで動くゲートウェイ」「自動フォールバック」「リクエスト前のトークン圧縮」という 3 つの仕掛けでまとめて解決しにいくアプローチを取っています。

ローカルで動くOpenAI互換エンドポイント

9router は起動すると、ローカルマシン上で http://localhost:20128/v1 という OpenAI 互換のエンドポイントを公開します。

各 CLI ツールは「OpenAI 互換 API を呼ぶ」設定を入れるだけで、実際の振り分け（どのプロバイダーに、どのモデルで送るか）は 9router 側が判断します。クォータ切れやエラーが発生すれば、9router が後段で別プロバイダーに自動フォールバックします。CLI から見れば「常に同じエンドポイントを叩いているだけ」という構造です（出典: README "How It Works"）。

リポジトリの基本情報と健全性

OSS を採用する際は、機能だけでなく「メンテナンスが続いているか」「エコシステムが形成されているか」も重要です。9router の基本指標を README とリポジトリメタ情報から整理します。

GitHub上の主要指標

公開から約 4 カ月でスター 1 万超・Fork 1,600 超に達し、執筆時点でも同日にコミットが入っていることから、メンテナンスは非常にアクティブです。ライセンスは MIT で、商用利用・改変・再配布の自由度も高い構成です。

詳細仕様は 公式 README に網羅されています。

配布チャネルとデプロイ先

9router は単一の配布形態に縛られておらず、用途に応じてインストール先を選べます。

• npm パッケージ（9router）でグローバルインストール
• Docker Hub のオフィシャルイメージ（decolua/9router）
• GHCR（GitHub Container Registry）の同名イメージ
• Cloudflare Workers などへのデプロイにも対応（出典: README "Deploy Anywhere"）

ローカルで動かす・社内 VPS に置いてチームで共有する・サーバーレスに載せるなど、運用形態に合わせた選択肢があるのは、OSS としては実務向きです。

公式ドキュメントとコミュニティ

README は英語に加え、日本語・中国語・ベトナム語の翻訳が i18n/ ディレクトリ配下に整備されています。日本語版は 公式 i18n リポジトリの README（日本語版） から参照できます。

また、9router を発展させた TypeScript フォーク OmniRoute も別オーナーで開発されており、エコシステム自体が広がり始めている状況です。

仕組みとアーキテクチャ

9router の役割を一段抽象化すると「CLI から受け取った OpenAI 互換のリクエストを、最適なプロバイダーに変換・転送するルーター」です。内部は概ね次の階層に分かれています（出典: README "How It Works" / README "Tech Stack"）。

[CLIツール（Claude Code / Codex / Cursor / Cline 等）]
        ↓ http://localhost:20128/v1
[9Router（スマートルーター）]
  ├─ RTK Token Saver（tool_result 圧縮）
  ├─ Format translation（OpenAI ↔ Claude ↔ Gemini ↔ Cursor ↔ Kiro 他）
  ├─ Quota tracking（リアルタイムクォータ追跡）
  └─ Auto token refresh（OAuth トークン自動更新）
        ↓
  [Tier 1: SUBSCRIPTION] Claude Code / Codex / GitHub Copilot / Cursor
        ↓ quota exhausted
  [Tier 2: CHEAP] GLM ($0.6/1M) / MiniMax ($0.2/1M)
        ↓ budget limit
  [Tier 3: FREE] Kiro / OpenCode Free / Vertex（$300 credits）

出典: 9router README "How It Works"（図の構造を引用、表現は README に基づく）

リクエストフローと3-Tierフォールバック

CLI 側からのリクエストは、まず RTK Token Saver による前処理（後述）を受け、フォーマット変換層を通って、適切なプロバイダーに転送されます。

プロバイダーは大きく 3 階層に分かれており、上位層がクォータ切れ・エラーになった場合に下位層へ自動でフォールバックします。

• Tier 1（SUBSCRIPTION）: Claude Code / Codex / GitHub Copilot / Cursor などサブスク経由
• Tier 2（CHEAP）: GLM-5.1 / GLM-4.7（$0.6/1M）・MiniMax M2.7（$0.2/1M）など低コスト API
• Tier 3（FREE）: Kiro AI（無料・無制限）・OpenCode Free・Vertex AI（$300 クレジット）

この自動切り替えのおかげで、CLI 側のコードは変えずに「サブスクが空いている間はサブスクで、切れたら格安 API へ、それも厳しければ無料層へ」という流れが成立します。

技術スタックとデータ層

実装側のスタックは README に明記されており、Node.js 20+ をランタイムに Next.js 16 + React 19 + Tailwind CSS 4 で構築されています。データ層は SQLite（better-sqlite3 / node:sqlite / sql.js のフォールバック）で、ストリーミングは Server-Sent Events（SSE）を採用しています。認証は OAuth 2.0（PKCE）と JWT、API Keys の併用です（出典: README "Tech Stack"）。

Web ダッシュボードを内包しているため、9router を起動するだけでブラウザから設定・統計確認が行える点が、CLI のみのゲートウェイとは大きく異なります。

対応プロバイダーと対応AIコーディングツール

9router の強みは「対応プロバイダー数」と「対応 CLI ツール数」の幅広さです。採用判断では、自分が使っているツールと使いたいモデルが両方ともリストに入っているかを確認することが重要です。

対応AIコーディングCLI

README の "Supported CLI Tools" セクションには、執筆時点で次の 12 種類が掲載されています（出典: README "Supported CLI Tools"）。

• Claude Code
• OpenClaw
• Codex
• OpenCode
• Cursor
• Antigravity
• Cline
• Continue
• Droid
• Roo
• Copilot
• Kilo Code

Cursor のような IDE 寄りのツールから、Cline / Continue のようなエディタ拡張、Codex のような CLI、GitHub Copilot まで「同じエンドポイントの先で吸収する」設計です。

OAuthプロバイダー（サブスク経由）

サブスクで契約済みのアカウントを OAuth で接続するタイプです。

• Claude Code
• Antigravity
• Codex
• GitHub Copilot
• Cursor

すでにサブスクを契約している人は、9router を経由させることで「同じサブスクをよりリッチに使い倒す」運用ができます。

無料プロバイダー

README には「2026 年に iFlow / Qwen / Gemini CLI の無料枠は終了したため、これらは非推奨」と明記されています（出典: README "Supported Providers"）。無料枠は時期によって増減するため、最新の README を確認する必要があります。

APIキープロバイダー（40+の主要例）

API キーを使うタイプは執筆時点で 40 以上が用意されています。主要なものは次のとおりです。

• OpenRouter / GLM / Kimi / MiniMax
• OpenAI / Anthropic / Gemini / DeepSeek
• Groq / xAI / Mistral / Perplexity
• Together AI / Fireworks / Cerebras / Cohere
• NVIDIA / SiliconFlow / Nebius / Chutes / Hyperbolic
• その他、OpenAI 互換・Anthropic 互換のカスタムエンドポイント

OpenAI 互換のカスタムエンドポイントが追加できるため、社内プライベート LLM や Ollama 経由のローカルモデルを混ぜることも視野に入ります。

9routerの独自機能

9router の「同種 OSS の中で何が違うか」を理解するうえで、独自機能の把握は欠かせません。後ほどの類似 OSS 比較セクションでも、この章で説明する機能を軸に住み分けを論じます（出典: README "Key Features"）。

RTK Token Saver（入力 -20〜40%削減）

RTK Token Saver は、LLM に送る前に tool_result を可逆圧縮する仕組みです。tool_result とは AI コーディングツールが LLM に渡す「外部コマンドの出力」のことで、典型的には git diff・grep・find・ls・tree・ログダンプなどが含まれます。

これらの出力はプロンプト予算の 30〜50% を占めることが珍しくありません。RTK はこれをロスレス圧縮することで、入力トークンを 20〜40% 削減します。

README で挙げられている特徴は次のとおりです。

• 対応フィルタ: git-diff / git-status / grep / find / ls / tree / dedup-log / smart-truncate / read-numbered / search-list
• 各 tool_result の先頭 1KB を覗いて、自動で適切なフィルタを選択
• フィルタが失敗・例外・出力が逆に大きくなる場合は、安全側に倒してオリジナルを保持
• フォーマット変換の前段で動くため、OpenAI / Claude / Gemini / Cursor / Kiro / OpenAI Responses など、すべてのプロバイダーに対して同じように働く
• デフォルトで有効。Dashboard の Endpoint settings からトグル可能

README には「47K tokens → 28K tokens（40% 削減・同じコンテキスト・同じ回答）」という例が挙げられています（出典: README "RTK Token Saver"）。RTK 自体は別プロジェクトとして rtk-ai/rtk（Rust 製）が存在し、9router はその JavaScript ポートを内蔵しているという位置づけです。

Caveman Mode（出力 -65%削減）

Caveman Mode は、いわゆる「caveman-speak」プロンプトを注入することで、LLM が冗長な前置きや繰り返しを抑えた簡潔な回答を返すよう促す機能です。技術的な内容は保持しつつ、出力トークンを最大 65% 削減すると README は説明しています。

元実装は別プロジェクトの JuliusBrussee/caveman で、9router はこの仕組みを取り込んで内蔵しています。

Smart 3-Tier Auto-Fallbackと「Combo」

3-Tier フォールバックは前述のとおりですが、9router はこれを「Combo」という名前で複数組み合わせて運用できます。

Combo: "my-coding-stack"
  1. cc/claude-opus-4-6        （your subscription）
  2. glm/glm-4.7               （cheap backup, $0.6/1M）
  3. if/kimi-k2-thinking       （free fallback）

→ Auto switches when quota runs out or errors occur

出典: 9router README "Smart 3-Tier Fallback"（コード例を引用）

Combo は名前付きで無制限に作成でき、CLI ごと・用途ごとに別の Combo を割り当てる運用も可能です。さらにマルチアカウント対応（同一プロバイダー内でラウンドロビン／優先度ルーティング）も備えています。

Format TranslationとQuota Tracking

フォーマット変換層は、OpenAI / Claude / Gemini / Cursor / Kiro / Vertex / Antigravity / Ollama / OpenAI Responses の間を相互変換します。CLI が OpenAI フォーマットでリクエストを投げても、9router が裏で「Claude にはネイティブの Messages API で」「Gemini には GenerateContent で」と変換してくれます。

加えて Real-Time Quota Tracking として、プロバイダーごとのトークン消費の可視化・リセットカウントダウン（5 時間 / 日次 / 週次）・有料 Tier のコスト見積・月次支出レポートを Web ダッシュボードから確認できます。RTK の効果や、どのプロバイダーがいつ枯渇しそうかを見ながら Combo を編集する、という運用が想定されています。

ここで紹介した RTK の仕組みは 日本語版 README（公式翻訳） でも要点が解説されています。英語のオリジナル README と読み比べると理解が深まります。

セットアップ手順の概要

ここではセットアップ手順を、README の引用ベースで紹介します。実際のインストールや動作確認は本記事の範囲外であり、最新の手順や前提条件は公式の README を必ず参照してください。

npmでのグローバルインストール（最速3ステップ）

README には次のような最短手順が掲載されています。

# 1. グローバルインストール
npm install -g 9router
9router

# 2. Dashboard（http://localhost:20128）でプロバイダー接続
#    Providers → Connect Kiro AI（無料・サインアップ不要）→ Done

# 3. CLI ツールでエンドポイントを設定
#    Endpoint: http://localhost:20128/v1
#    API Key: [Dashboard からコピー]
#    Model: kr/claude-sonnet-4.5

出典: 9router README "Quick Start"（コード例を引用）

npm 配布版は npm パッケージ 9router として公開されています。

Dockerでの起動

Docker でホストする場合は、README に掲載されている次の例が起点になります。

docker run -d \
  --name 9router \
  -p 20128:20128 \
  -v "$HOME/.9router:/app/data" \
  -e DATA_DIR=/app/data \
  decolua/9router:latest

出典: 9router README "Docker"（コード例を引用、改変なし）

Docker イメージは Docker Hub の decolua/9router からも取得できます。永続化用にホスト側の ~/.9router をマウントしておくと、設定・データベース・OAuth トークンが再起動後も保持されます。

CLI別の接続設定例

README の "Setup Guide" には、主要 CLI 別の接続例が掲載されています。エッセンスをまとめると次のとおりです（出典: README "Setup Guide"）。

• Claude Code: ~/.claude/config.json の anthropic_api_base に http://localhost:20128/v1 を設定
• Codex CLI: 環境変数 OPENAI_BASE_URL="http://localhost:20128" と OPENAI_API_KEY="..." を設定
• Cursor IDE: Settings → Models → OpenAI API Base URL に http://localhost:20128/v1 を設定
• Cline / Continue / RooCode: Provider を「OpenAI Compatible」にし、Base URL に http://localhost:20128/v1 を設定

CLI 側から見るとどれも「OpenAI 互換のエンドポイントを向き先にする」というだけの設定で、その後ろにある複雑な振り分けは 9router が引き受ける構造です。

類似OSSとの比較

9router の採用判断で最も重要なのが「同じような OSS の中でどう位置づけるか」です。ここでは特に検索意図が重なりやすい 3 種類を取り上げ、機能軸で差分を整理します。

free-claude-codeとの違い

free-claude-code（alishahryar1/free-claude-code）は、Claude Code を別プロバイダーで「無料化」する用途に特化した Python 製のドロップインプロキシです。Anthropic Messages API 互換のエンドポイントを立て、Claude Code から見ると Anthropic 公式と区別なく動作する設計になっています。

free-claude-code は「Claude Code 単体ユーザーが、設定を変えずにバックエンドだけ別プロバイダーに差し替えたい」という需要に対して最短距離のツールです。一方の 9router は、複数 CLI を横断して使い、Web UI から運用したいユーザーに最適化されています。「Claude Code 単体で十分」「Python エコシステムを好む」のであれば free-claude-code、「Codex も Cursor も Cline も並行運用している」のであれば 9router、という棲み分けが基本になります。free-claude-code 側の設計思想や採用判断軸については Claude Codeを無料化するfree-claude-codeが選ばれる理由と仕組み で詳しく解説しています。

CLIProxyAPIとの違い

CLIProxyAPI（router-for-me/CLIProxyAPI）は、9router が JavaScript ポート元として README に明記している原実装で、Go 製のゲートウェイです。

両者は思想的に近い OSS で、「ローカルゲートウェイで複数 CLI を束ねる」という目的は共通しています。違いは「成熟度・実装言語・UI の有無」と「対応 CLI／プロバイダーの広さとトークン節約機能の有無」です。Go バイナリ 1 つで動かしたい・サーバーで常駐させたいなら CLIProxyAPI、Web ダッシュボードでクォータや Combo を見ながら運用したいなら 9router、という選び方になります。

OmniRoute / RTK / Snipの位置づけ

最後に、9router の README で関連プロジェクトとして言及される 3 つの OSS にも触れておきます。

• OmniRoute（diegosouzapw/OmniRoute）: 9router の TypeScript フォーク。160+ providers、4-tier フォールバック、マルチモーダル API、サーキットブレーカーなどを追加している。README で「Forks」として紹介されている派生プロジェクト。
• RTK（rtk-ai/rtk）: 9router が内蔵する圧縮パイプラインの元実装（Rust 製）。トークン削減のみが目的で、ゲートウェイやフォールバック機能は持たない。9router の中身を理解したいなら参照価値がある。
• Snip（edouard-claude/snip）: Claude Code / Cursor / Copilot / Gemini CLI / Windsurf / Cline / Codex などに対応する圧縮プロキシ。トークン削減 60〜90% を謳うが、ゲートウェイやフォールバックは持たない。圧縮だけを別系統で組み合わせたい場合の選択肢になる。

これらは「9router の代替」というより、「9router を補完する関係」または「9router 自身を発展させた派生」という位置づけです。

どんなユーザーに向くか・採用判断の軸

ここまでの内容を踏まえ、9router を採用すべきユーザー像と、向かないケース、採用前に確認すべき観点を整理します。

9routerが特に向くユーザー

• Claude Code / Codex / Cursor / Cline / GitHub Copilot などを複数並行運用している
• 無料枠（Kiro AI / OpenCode Free / Vertex AI）を最大限活用したい
• Web ダッシュボードでクォータ・コスト・Combo を管理したい
• Node.js / npm / Docker のエコシステムが手に馴染んでいる
• RTK によるトークン圧縮で、サブスクのクォータ寿命を延ばしたい

9routerが向かないケース

逆に、次のようなケースでは別の OSS を検討した方が合うことがあります。

• 単一 CLI・単一プロバイダーで完結している。たとえば「Claude Code しか使わない」「無料化したいのは Claude Code だけ」 → よりシンプルな free-claude-code が候補になる
• Go 製の CLI・サーバーをワンバイナリで運用したい → 原実装の CLIProxyAPI が候補になる
• Node.js を運用環境に持ち込みたくない、または Web ダッシュボードを必要としない → 同上

採用前に確認すべき5つの観点

最後に、9router を導入する前にチェックしておきたい観点を 5 つに整理します。

1. 自分が使っている CLI ツールが README の "Supported CLI Tools" に含まれているか
2. 使いたいプロバイダー（特に有料 API・サブスク）が "Supported Providers" に含まれているか
3. ローカル運用とサーバー運用のどちらを想定しているか（ローカルなら npm、共有なら Docker / VPS / Cloudflare Workers）
4. RTK / Caveman によるトークン節約が、自分のユースケースで意味のある効果になるか（tool_result を多用するワークフローかどうか）
5. メンテナンスが継続している間に乗るか、ある程度安定するまで様子を見るか

特に 5 番目については、執筆時点でスター数 10,436・Fork 数 1,603・最終 push 2026 年 5 月 15 日と、十分にアクティブな OSS です。一方で、9router 自体が比較的若いプロジェクトでもあるため、API・設定形式の破壊的変更が起きる可能性は念頭に置いておくと安全です。

まとめ

9router は、「複数の AI コーディングツール × 複数の LLM プロバイダー」という今どきの開発環境を、ローカル動作のゲートウェイ 1 つに束ねるための OSS です。RTK Token Saver と Caveman Mode によるトークン節約、3-Tier 自動フォールバックと Combo によるクォータ管理、そして Web ダッシュボードによる可視化が、機能面の核になっています。

類似 OSS との関係を整理すると、Claude Code 単体ユーザーには free-claude-code、Go 製で CLI 中心の運用を好むなら CLIProxyAPI、そして「複数 CLI・多プロバイダー・Web UI・トークン節約」を一度に解決したいなら 9router、という棲み分けになります。OmniRoute・RTK・Snip は補完的な位置づけで、9router の理解や、特定機能の単体採用にも役立ちます。

次のアクションとしては、まず 9router の公式 README に目を通し、自分の CLI とプロバイダーが対応リストに入っているかを確認することをおすすめします。そのうえで、公式サイト 9router.com や日本語 README、CLIProxyAPI・free-claude-code の README と読み比べることで、自分のユースケースにフィットするゲートウェイを判断できるはずです。

本記事は 9router の公開ドキュメントを基にした紹介であり、動作検証や実行結果は含みません。最新の仕様・対応プロバイダー・無料枠の状況は、必ず公式リポジトリの最新版を確認してください。