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

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

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

3 種類の対話プロトコルは入口と出口が互いに縛られず、自由に組み合わせられます。たとえば Codex が OpenAI Responses の入口から入り、最終的に DeepSeek の Anthropic エンドポイントが応答する、といった構成が可能です。Jev 意思決定モデルは独立した経路で、入口・出口ともに System One を使い、そのまま透過します。

 Claude Code  OpenCode   pi ...      Codex ...           Open WebUI ...    自作コード / エージェント
      |           |         |            |                      |                      |
      -----------------------            |                      |                      |
                 |                       |                      |                      |
             Anthropic                OpenAI                 OpenAI                   Jev
           Messages API            Responses API      Chat Completions API        System One
          (/v1/messages)          (/v1/responses)    (/v1/chat/completions)     (/v1/systemone)
                 |                       |                      |                      |
                 -----------------------------------------------------------------------
                                                    |  入口 · 仮想モデル
                                                    |
                                                cc-router
                                       (ローカル 127.0.0.1:23456)
                                                    |
                                                    |  出口 · 実モデル
              ------------------------------------------------------------------------------
              |          |          |          |          |          |          |          |
          DeepSeek      GLM       Kimi     Anthropic   OpenAI     Gemini       Jev      ......
             API      Coding     Coding    Messages  Responses &    API    System One
                       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 つの対話入口はサブスクリプション、仮想モデル、利用上限、セッション固定をすべて共有し、レート制限、失敗時の自動リトライやサブスクリプション切替もすべての対話入口で有効です。リクエストログ詳細の「受信エンドポイント」で、各リクエストがどの入口から入ったかを確認できます。

Jev はこの pipeline を通りません：/v1/systemone はプロトコル翻訳を行わず、model-jev にバインドされた System One サブスクリプションの間だけでディスパッチし、リクエストとレスポンスをそのまま透過します。ディスパッチモード、失敗時の切替、クールダウン、利用上限は同様に有効です。詳しくは Jev /v1/systemone を参照してください。

入口：ツールから 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
Jev System One `POST /v1/systemone`	自作のコード、エージェントフレームワーク、または HTTP リクエストを送れる任意のプログラム	`http://127.0.0.1:23456/v1/systemone`（フルパス）	なし（そのまま透過）

最初の 3 つは対話入口で、4 つ目は Jev 意思決定モデル（仮想モデル model-jev）専用のため、Claude Code のような対話ツールでは使えません。4 つの入口のほかに、共通エンドポイントが 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 プロトコルしか話せない場合にだけ使います。Jev はリクエスト、レスポンス、エラーの形式がいずれも対話入口と異なります。Jev /v1/systemone を参照してください。

共通仕様

待受とポート

設定項目	既定値	説明
リッスンアドレス	`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`
`model-jev`	`model-jev` そのもののみ（`/v1/systemone` 入口でのみ使用可能。対話入口が受け取ると 400 を返す）

上記のどの書き方にも 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 からプロバイダへの接続

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

出口の種類	上流プロトコル	内蔵プリセット（抜粋）	カスタムエンドポイント	プロトコル翻訳
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、Requesty、xAI、Ollama など	任意の Anthropic Messages 互換エンドポイント	なし（そのまま透過）
OpenAI 互換	`/v1/responses`、`/v1/chat/completions`	OpenAI 公式 API、Cloudflare Workers AI	one-api / new-api 系の中継サービス、Groq、Together、ローカルの vLLM / llama.cpp など	Messages → OpenAI
Gemini 互換	`generateContent`、`/v1beta/interactions`	Google AI Studio、Gemini Interactions API	任意の Gemini 互換エンドポイント	Messages → Gemini
Jev System One	`/v1/systemone`	TypeSafe、Cloudflare Clef、OpenRouter、Ollama 0.35+	該当なし	なし（そのまま透過）
サブスクリプションアカウント（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 を自動で付与します。
Jev System One：model-jev 専用で、/v1/systemone 入口のリクエストしか受け付けません。この種類のサブスクリプションには任意設定の Jev モデルスロットが 1 つだけあり、作成後はプロトコルが固定され、対話用エンドポイントと入れ替えることはできません。
サブスクリプションアカウント（OAuth）：API Key を使わず、OAuth のデバイスコードでログインします。グレーゾーンであり、アカウント停止のリスクがあるためメインでの利用は推奨しません。予備としての利用にとどめてください。

入口 × 出口の組み合わせ

3 つの対話入口はどの対話系の出口とも組み合わせられます。違いは途中で何回プロトコル翻訳を経るかです（Jev は /v1/systemone 入口 → System One 出口の組み合わせしかなく、ここには含まれません）。

入口 ↓ / 出口 →	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 プロトコルにそろえるのがおすすめです。