エンドポイント概要：入口と出口

cc-router はお使いのツールと LLM プロバイダの間に入ります。

入口：ツールが cc-router にどう接続するか。cc-router は 3 種類のプロトコルのエンドポイントを公開しており、ツールが話すプロトコルに合わせて接続先を選びます。
出口：cc-router がプロバイダにどう接続するか。各サブスクリプションはプロバイダが対応するプロトコルで設定され、cc-router が正しい形式のリクエストを送信します。

両者は互いに縛られず、自由に組み合わせられます。たとえば Codex が OpenAI Responses の入口から入り、最終的に DeepSeek の Anthropic エンドポイントが応答する、といった構成が可能です。

 Claude Code    OpenCode    OpenClaw   pi ...   Codex ...      Open WebUI / Cherry Studio ...
      |             |           |         |         |                         |
      -------------------------------------         |                         |
                        |                           |                         |
                    Anthropic                    OpenAI                    OpenAI
                  Messages API                Responses API         Chat Completions API
                 (/v1/messages)              (/v1/responses)       (/v1/chat/completions)
                        |                           |                         |
                        -------------------------------------------------------
                                                  |  入口 · 仮想モデル
                                                  |
                                              cc-router
                                      (ローカル 127.0.0.1:23456)
                                                  |
                                                  |  出口 · 実モデル
           -----------------------------------------------------------------------------
           |            |            |            |            |            |          |
       DeepSeek        GLM         Kimi       Anthropic     OpenAI       Gemini     ......
          API        Coding       Coding      Messages    Responses &      API
                      Plan         Plan          API      Completions

内部では統一：すべてまず Anthropic Messages になる

cc-router の内部にはディスパッチ pipeline が 1 本だけあり、Anthropic Messages プロトコルで動作します。

リクエストがいずれかの入口から入ります。Anthropic 以外の入口では、まず Anthropic Messages に翻訳されます。
pipeline が model を仮想モデル（model-fable / model-opus / model-sonnet / model-haiku）に解決し、そのスロットにバインドされたサブスクリプション一覧とディスパッチモード（順次 / ラウンドロビン / セッション固定）に従ってサブスクリプションを 1 つ選びます。
選ばれたサブスクリプションの出口プロトコルでリクエストを送信します。Anthropic 以外の出口では、さらに対応するプロトコルへ翻訳されます。
レスポンスは来た経路を逆にたどって翻訳され、クライアントが使った入口のプロトコル形式で返されます。

そのため 3 つの入口はサブスクリプション、仮想モデル、利用上限、セッション固定をすべて共有し、レート制限、失敗時の自動リトライやサブスクリプション切替もすべての入口で有効です。リクエストログ詳細の「受信エンドポイント」で、各リクエストがどの入口から入ったかを確認できます。

入口：ツールから cc-router への接続

入口（クリックで詳細リファレンス）	代表的なクライアント	Base URL	プロトコル翻訳
Anthropic Messages `POST /v1/messages`	Claude Code、Claude Desktop、OpenCode、OpenClaw、pi、Kimi Code CLI	`http://127.0.0.1:23456`	なし（そのまま透過）
OpenAI Responses `POST /v1/responses`	Codex CLI、Codex Desktop	`http://127.0.0.1:23456/v1`	Responses ⇄ Messages
OpenAI Chat Completions `POST /v1/chat/completions`	Open WebUI、Cherry Studio、Cline、LobeChat	`http://127.0.0.1:23456/v1`	Chat ⇄ Messages

3 つの入口のほかに、共通エンドポイントが 2 つあります。

エンドポイント	用途	認証
`GET /v1/models`	仮想モデル一覧。フィールドは Anthropic と OpenAI の両 SDK に対応	不要
`GET /health`	死活監視。プレーンテキストの `ok` を返す	不要

詳しくは GET /v1/models を参照してください。

3 つの入口の違い早見表

	`/v1/messages`	`/v1/responses`	`/v1/chat/completions`
最低バージョン	v3.0.0	v3.0.0	v5.0.0
推奨モデル名	`model-opus` など	`gpt-5.5` など	どちらでも可
思考の強さ	`thinking` / `output_config.effort` をそのまま透過	`reasoning.effort` → thinking 予算	`reasoning_effort` → thinking 予算
思考内容の返却	`thinking` ブロック（署名付き）	`reasoning` item（署名付き、送り返し可）	`reasoning_content` フィールド（送り返すと破棄）
画像入力	対応	非対応	対応（`data:` base64 と `http(s)` URL）
ツール呼び出し	対応	対応（`function` タイプ）	対応（`tools` / `tool_choice`。旧形式の `functions` は非対応）
ストリーム終了の目印	`message_stop`	`response.completed`（`[DONE]` なし）	`data: [DONE]`
ストリームの usage	`message_start` / `message_delta` 内	`response.completed` 内	末尾に usage 専用フレームを 1 つ
エラーボディ形式	Anthropic	OpenAI	OpenAI
セッション固定の識別子	`x-claude-code-session-id` → `metadata.user_id` → 最初のユーザーメッセージ	`prompt_cache_key` → `session_id` リクエストヘッダ	`user` → `x-session-id` リクエストヘッダ → 最初のユーザーメッセージ

どの入口を選ぶべき？ ツールが Anthropic Messages に対応していれば、それを優先してください。翻訳がゼロで、thinking、cache_control、画像、ツール呼び出しがすべてネイティブのセマンティクスで動作します。ほかの 2 つの入口は、ツールが OpenAI プロトコルしか話せない場合にだけ使います。

共通仕様

待受とポート

設定項目	既定値	説明
リッスンアドレス	`127.0.0.1`	設定 → プロキシサービス → リッスンアドレスを「LAN」に切り替えると `0.0.0.0` になる
HTTP ポート	`23456`	使用中の場合は自動で +1、最大 100 回まで試行
HTTPS ポート	`23457`	リッスンプロトコルで「HTTPS のみ」または「HTTP + HTTPS」を選ぶと有効。同じく自動で +1
リクエストボディ上限	32 MB	複数画像を base64 で含むリクエストは上限を超えて 413 になることがある。設定で引き上げ可能

ポート、プロトコル、リッスンアドレス、リクエストボディ上限の変更は、いずれも cc-router の再起動 後に有効になります。

認証

「トークン認証」は既定で有効です（設定 → 認証と CORS）。有効時は、すべての入口で x-api-key: <token> または Authorization: Bearer <token> からトークンを読み取り（x-api-key が優先）、設定ページのトークンと完全に一致する必要があります。
/v1/models、/health、すべての OPTIONS プリフライトは認証不要です。
認証失敗時の 401 レスポンスボディは入口に関係なく常に Anthropic 形式です。認証は入口の handler より前で行われるためです。
このトークンは cc-router へのアクセス専用で、上流プロバイダの API Key とは無関係です。上流の Key は、転送時に cc-router がサブスクリプションに応じて差し替えます。

HTTPS

HTTPS ポートは cc-router のローカル自己署名 CA が発行した証明書を使うため、クライアント側で先にこの CA を信頼させる必要があります。有効化が必要なのは HTTPS しか受け付けないクライアント（Claude Desktop など）だけです。設定方法は Claude Desktop 連携（macOS）と Windows 版を参照してください。

CORS

既定で有効です。Access-Control-Allow-Origin: *、GET / POST / OPTIONS を許可し、プリフライトにはそのまま 204 を返します。401 レスポンスにも CORS ヘッダが付くため、ブラウザからエラーボディを読み取れます。

仮想モデルとエイリアス

すべての入口で同じモデル名の解決ルールを使うため、別の入口向けのモデル名を混ぜて使っても構いません。

仮想モデル	使えるエイリアス
`model-fable`	`claude-fable`、`gpt-5.6`、`gpt--sol`
`model-opus`	`claude-opus`、`gpt-5.5`、`gpt--terra`
`model-sonnet`	`claude-sonnet`、`gpt-5.4`、`gpt--luna`
`model-haiku`	`claude-haiku`、`gpt--mini`

上記のどの書き方にも anthropic/ または openai/ プレフィックス（LiteLLM 形式）を付けられ、効果は同じです。
claude-opus* は前方一致です。claude-opus-4-7、claude-opus-4-7-20260101 はどちらも model-opus にヒットします。
gpt-*-sol は - で区切ったセグメント単位でティアを照合します。gpt-5.6-sol、gpt-6-sol-20261201 はどちらも model-fable にヒットし、gpt-5.4-mini は model-haiku にヒットします。
どのルールにも一致しないモデル名は fallback になり、model はそのまま fallback スロットのサブスクリプションへ透過されます。

出口：cc-router からプロバイダへの接続

出口は上流プロトコルによって 4 種類に分かれます。内蔵のプロバイダプリセットとカスタムエンドポイントは同じ経路を通り、違いは内蔵プリセットのほうがアドレス、認証方式、モデル一覧をあらかじめ入力済みという点だけです。内蔵プロバイダの完全な一覧は、アプリ内の「サブスクリプションを追加」ページを参照してください。

出口の種類	上流プロトコル	内蔵プリセット（抜粋）	カスタムエンドポイント	プロトコル翻訳
Anthropic Messages 互換	`/v1/messages`	Anthropic 公式、DeepSeek、智譜 GLM、Kimi、MiniMax、Xiaomi MiMo、Alibaba Cloud Bailian、Volcengine Ark、Tencent Cloud、Baidu Qianfan、StepFun、ModelScope、UCloud Compshare、Fireworks、OpenRouter、xAI、Ollama など	任意の Anthropic Messages 互換エンドポイント	なし（そのまま透過）
OpenAI 互換	`/v1/responses`、`/v1/chat/completions`	OpenAI 公式 API	one-api / new-api 系の中継サービス、Groq、Together、ローカルの vLLM / llama.cpp など	Messages → OpenAI
Gemini 互換	`generateContent`、`/v1beta/interactions`	Google AI Studio、Gemini Interactions API	任意の Gemini 互換エンドポイント	Messages → Gemini
サブスクリプションアカウント（OAuth）	各社独自プロトコル	Codex（ChatGPT Plus/Pro）、Kiro（AWS）	該当なし	Messages → 独自プロトコル

出口の種類ごとの挙動のポイント：

Anthropic Messages 互換：メインの経路です。プロトコル翻訳を行わず、thinking、output_config.effort、cache_control、画像、ツール呼び出しがすべてネイティブのセマンティクスで動作します。プロバイダがネイティブの Anthropic エンドポイントを提供している場合は、この種類を優先して設定してください。
OpenAI 互換：thinking と OpenAI の reasoning を双方向にマッピングし、複数ターンの推論コンテキストを自動で引き継ぎます。Chat Completions の上流が返す reasoning_content（DeepSeek R1 など）は thinking ブロックに変換されます。翻訳層で表現できない内容（cache_control など）は破棄されます。
Gemini 互換：thinking を双方向にマッピングし、ツール呼び出しの往復では thought signature を自動で付与します。
サブスクリプションアカウント（OAuth）：API Key を使わず、OAuth のデバイスコードでログインします。グレーゾーンであり、アカウント停止のリスクがあるためメインでの利用は推奨しません。予備としての利用にとどめてください。

入口 × 出口の組み合わせ

どの入口もどの出口と組み合わせられます。違いは途中で何回プロトコル翻訳を経るかです。

入口 ↓ / 出口 →	Anthropic 互換	OpenAI 互換 / Gemini 互換 / OAuth
`/v1/messages`	0 回。完全に透過し、忠実度が最も高い	1 回（出口での翻訳）
`/v1/responses`	1 回（入口での翻訳）	2 回
`/v1/chat/completions`	1 回（入口での翻訳）	2 回

翻訳回数が多いほど、プロトコル固有の機能が失われる可能性が高くなります（たとえば cache_control は全経路が Anthropic のときだけ有効です）。実際には 1～2 回の翻訳が日常的な会話やツール呼び出しに与える影響は小さいですが、prompt cache のヒット率や推論の細部を重視する場合は、入口と出口の両方を Anthropic プロトコルにそろえるのがおすすめです。