プロバイダー

プロバイダーは名前 → 設定のマップです。新しい上流は [providers.<name>] テーブルをもう 1 つ書くだけ — コード変更は不要です。アダプターの種類は次のとおりです。

• kind = "anthropic" — 上流が Anthropic Messages API を話します。shunt はリクエストをパススルーし、オプションで別の API キーを注入します。
• kind = "responses" — 上流が OpenAI Responses API を話します。shunt は Anthropic Messages ⇄ Responses を、ストリーミングを含めて変換します。
• kind = "cursor" — ネイティブな Cursor アダプター。shunt は Cursor の ConnectRPC/protobuf AgentService を Anthropic Messages API へブリッジし、ストリーミング・推論(ストリーミング応答時)・ネイティブなツール呼び出し・インライン画像を含みます。組み込みの cursor プロバイダーが使用します。
• kind = "gemini" — ネイティブな Google Code Assist generateContent アダプター。
• kind = "antigravity" — HTTP 経由で Google Antigravity バックエンドに接続します。
• kind = "antigravity_cli" — 非推奨。ローカルの Antigravity agy CLI を呼び出します。

組み込みプロバイダー

各名前から、そのプロバイダーの完全なセットアップを説明する専用ページへ移動できます。shunt add upstream <name> は、任意の組み込みプロバイダーについて手順を追ったブループリントを出力します。コーディングエージェントへパイプすれば（shunt add upstream codex --print | claude）、エージェントに設定を組み込ませることができます。CLI リファレンスも参照してください。

gemini プロバイダーのツール宣言には、antigravity プロバイダーと同じスキーマ調整が適用されます。両方の転送が 1 つの Gemini アダプターを共有するため、Antigravity プロバイダーページのアダプターが伝えるもので説明する タプルの畳み込みと型のない要素のフォールバックは gemini ルートにも適用されます。

antigravity プロバイダー（Google Antigravity）

antigravity プロバイダーは、HTTP 経由で Google Antigravity バックエンドに到達します。shunt login antigravity で認証してください — Antigravity 自身の OAuth クライアントを使う Google の authorization-code フローで、Gemini CLI のログインでは決して付与されない 2 つのスコープ（cclog、experimentsandconfigs）を要求します。そのため、両者の認証情報はどちらの方向にも流用できません。 ログイン時に Code Assist プロジェクトも解決し、初めてのアカウントは onboardUser でプロビジョニングするため、リクエストの 手前でディスカバリーが走ることはありません。

ローカルのエイリアスを、正確な Antigravity のモデルスラッグへマッピングします:

[[models]]
id = "claude-gemini-3.6-flash-via-antigravity"
display_name = "[AGY ] Gemini-3.6-Flash"

[[routes]]
model = "claude-gemini-3.6-flash-via-antigravity"
provider = "antigravity"
upstream_model = "gemini-3.6-flash-medium"

Antigravity は Gemini モデルを effort が id に含まれる形で公開しており、サフィックスのないスラッグは 提供しません。形は 2 つあります — -low / -medium / -high のサフィックスか、effort をリクエスト フィールドとして受け取る単一の -tiered id です。どちらの形がアカウントに配られるかは時期によって 変わるため、shunt はアカウント自身のカタログを読み、実際に公開されている id を選びます。サフィックスの ない gemini-* の id は effort かリクエストから、いずれもなければ medium として解決され、 アカウントがもう公開していないサフィックスはそのまま送らずに解決し直されます。どの書き方でも動きます。

ログインとスコープ、プロジェクトディスカバリー、モデルスラッグ、thinking、アダプターが伝えるものを含む完全なセットアップに ついては、専用の Antigravity プロバイダーページを参照してください。

非推奨の antigravity_cli 転送

antigravity-cli の経路は、リクエストごとに agy CLI のサブプロセスを 1 つ、エージェントモードで実行します。agy は自身の ツール呼び出しを自分で解決するため、このアダプターは tool_use ブロックを返すことができず、ツール呼び出しを要求する リクエストは拒否されます。空でない tools 配列、または any/tool の tool_choice は、この制約を明示した 400 invalid_request_error で拒否されます。以前はこうしたリクエストが暗黙に捨てられ、stop_reason: "end_turn" の テキストのみの 200 が返っていました。これはエージェント型の呼び出し側が利用できないレスポンスであり、 tool_choice: {"type": "any"} に正面から違反しながら成功を報告するものでした。ツール呼び出しを必須にしない 2 つの形は 例外です。tools が指定されていても tool_choice: {"type": "none"} は例外であり、ツールなしの tool_choice: {"type": "auto"} も、多くのクライアントが毎リクエストにシリアライズする Anthropic SDK のデフォルトである ため例外です。空の tools: [] も同様にツール要求ではありません。ツールループを自分で回す必要があるクライアントは、 ツールを転送する antigravity または gemini プロバイダーを使用してください。

配信されなかった send_message のハンドオフは、完了したターンを失敗にしません。print モードは send_message を含む agy の対話用ツール一式を公開しますが、inbox は登録しません。サブエージェント風のプロンプト（「結果をメインエージェントに 報告せよ」）だけで、モデルは返答を main、team-lead、user に渡そうとし、その呼び出しは失敗して、agy は — 返答が すでにストリーミングされた後で — recipient "<name>" not found エラーとともに実行を ERROR にします。shunt は アシスタントのテキストがストリーミングされていればそのターンを通常どおり終了（end_turn、HTTP 200）し、何も ストリーミングされていなければ返答は配信されなかったメッセージの中にしか存在しなかったため、引き続き失敗として扱います。 それ以外の遅い失敗は今までどおり SSE error でターンを終えます。これは upstream のエラー文字列に依存する互換性の ための処理です。リポジトリの docs/notes/agy-print-mode-tool-surface.md を参照してください。

非対話実行では権限プロンプトに応答できないため、agy は --dangerously-skip-permissions 付きで、さらにデフォルトでは --sandbox 付きで実行されます。したがって このプロバイダーは shunt を実行しているユーザー権限での任意コード実行として 扱ってください。

これを制限する設定は 2 つあります。sandbox（デフォルト true）は --sandbox を渡すもので、実際にエージェントを封じ込めて いるのはこれです — 無効にすると、制限のないシェルアクセスが残ります。workspace_roots（デフォルトは空）は、エージェントが 開始できる場所だけを決めます。解決順序は SHUNT_AGY_WORKSPACE、次にリクエストのシステムプロンプト内の Working directory: 行、そしてゲートウェイ自身のディレクトリです。システムプロンプトはクライアントが制御するテキストなので、 そこで見つかったパスは、設定したルートのいずれかの内側に正規化される場合にのみ採用されます。ルートを 1 つも設定しなければ、 プロンプト由来のパスは無視されます。

[providers.antigravity-cli]
kind = "antigravity_cli"
base_url = "http://localhost"
auth = "none"
# リクエストの内容によってエージェントを向けられるリポジトリ。
workspace_roots = ["/Users/you/repos"]
# sandbox = false   # エージェントに制限のないターミナルアクセスが必要な場合のみ

workspace_roots は牢屋ではありません。sandbox = false の場合、許可されたルートで開始したエージェントであっても、 プロンプトの別の場所に書かれたパスを操作できます。

shunt は sandbox = false とループバック以外の bind の組み合わせでは起動を拒否し、起動時にバインドしたリスナーに対して リクエストごとにもこれを強制します。ホットリロードではリスナーを移動できないため、ループバックの bind を読み直しても、 公開リスナーが有効なままサンドボックスを無効化することはできません。サンドボックスは有効のままにするか、ループバックの バインドで再起動してください。信頼できないクライアントに対して、ループバック以外のバインドでこのプロバイダーを公開しない でください。

3 つめの設定である profile_dir は、エントリーごとに専用の HOME を与えます。agy は認証情報を含む状態ツリー全体を HOME 経由で解決するため、未設定のままではすべてのエントリーがゲートウェイホストの単一の ambient な ~/.gemini プロファイルを共有し、結局ひとつの Google アカウントしか使えません。エントリーごとにディレクトリを指定すれば、それぞれが 自分のアカウントにサインインし、複数を同時にプールできます。ディレクトリは必要に応じて作成され絶対パスに正規化されます。 先頭の ~ は展開されます。各ディレクトリには一度ずつ agy のサインインが必要です。この設定を使うエントリーに限り、子 プロセスの GOOGLE_* / GEMINI_* 環境変数が取り除かれるため、ホスト側の設定がどのアカウント — そして誰の請求 — が リクエストを処理するかを黙って変えてしまうことはありません。未設定（既定）なら従来どおりの動作です。順序付き [[upstreams]] エントリーでも同じ設定を利用できます。

これらを一切必要としない、上記のネイティブな antigravity HTTP プロバイダーの使用を推奨します。この節は要約です — モデル / effort マトリクスを含む完全なドキュメントは、英語版ガイドの The deprecated antigravity-cli transport にあります。

codex プロバイダー（ChatGPT サブスクリプション）

Codex CLI で一度ログインすれば、shunt が ~/.codex/auth.json を読み込み、自動リフレッシュします。

codex login

ファイルが存在しないか期限切れの場合、shunt は authentication_error を返し、codex login を実行するよう伝えます。

認証ファイルの扱い、モデル選択、エフォート、コンテキストサイズを含む完全なセットアップについては、専用の ChatGPT / Codex ガイドを参照してください。

cursor プロバイダー（Cursor サブスクリプション）

組み込みの cursor プロバイダーは、Cursor 自身の ConnectRPC/protobuf AgentService を通じて、あなたの Cursor サブスクリプションに接続します。kind = "cursor" のネイティブアダプターが、ストリーミング、推論、ネイティブなツール呼び出し、インライン画像を含め、Anthropic Messages との間で変換します。

shunt login cursor で一度ログインした後、cursor:default、cursor-plan:default、cursor-ask:default などの cursor:* モデル id をルーティングします。プロバイダーはデフォルトでシードされているため、設定テーブルは不要です。

ログイン、エージェントモード、ワイヤーモデル id、アダプターの機能、オーバーライドを含む完全なセットアップについては、専用の Cursor プロバイダーページを参照してください。

xai / grok プロバイダー（Grok）

2 つの組み込みプロバイダーが xAI の Grok モデルにアクセスします。認証情報で分かれます。grok は OAuth 経由であなたの SuperGrok / X Premium+ サブスクリプションを消費し（shunt login xai、トークン単位の課金なし）、一方 xai は従量制の開発者 API に対して XAI_API_KEY を使います。サブスクリプションの bearer と API キーは互換ではありません — それぞれ自身のプロバイダーに対してのみ機能します。

ログイン、両方のプロバイダーブロック、モデルスラッグ、オプトインのエフォートダイヤル、entitlement の落とし穴を含む完全なセットアップについては、専用の xAI / Grok ガイドを参照してください。

複数の SuperGrok アカウントをプールするには、各アカウントを shunt login xai --name <name> でログインします。詳細は xAI / Grok ガイドを参照してください。

Anthropic 互換バックエンドを追加する

「Claude Code を X で使う」系のサードパーティゲートウェイのほとんどは Anthropic Messages 互換です。auth = "api_key" を伴う kind = "anthropic" で、違いは base_url とキーの環境変数だけです。すぐ使えるベース URL（各プロバイダーから、完全なセットアップを説明する専用ページへ移動できます）:

この表にないプロバイダーについては、shunt add upstream <docs-url> が、そのプロバイダー自身のドキュメントをもとにコーディングエージェントへ組み込み手順を案内するリサーチ用ブループリントを出力します（shunt add upstream https://docs.example.com --print | claude）。

上記の行はすべて auth = "api_key" を使いますが、1 行だけ例外があります。Kimi Code は、その 1 行上にある従量課金制の Moonshot API とは別の、サブスクリプション課金の Kimi サービスです — ホストが異なり、API キーの代わりに OAuth を使います。専用の組み込みプリセット kimi-code（kind = "anthropic"、base_url = "https://api.kimi.com/coding"、auth = "kimi_oauth"）が用意されているため、順序付きの [[upstreams]] 形式で provider = "kimi-code" を指定するだけでよく、手動の [providers.*] テーブルは不要です。あとはログイン済みのアカウントがあれば使えます:

shunt login kimi --name <account-name>   # RFC 8628 デバイスフロー -> ~/.shunt/accounts/kimi/<account-name>.json

# shunt.toml — Kimi Code サブスクリプションへルーティングする
[[upstreams]]
name = "kimi-code"
provider = "kimi-code"
auth = { mode = "kimi_oauth", account = "<account-name>" }

# [[upstreams]] を宣言すると組み込みのプロバイダー集合が置き換わるため、末尾に
# anthropic のパススルーを残しておくこと — これがないと、デフォルトの
# server.default_provider を `shunt check` が拒否する。これは `shunt init` が
# 追加するのと同じエントリ。
[[upstreams]]
name = "anthropic"
provider = "anthropic"

[[routes]]
model = "<model-id-your-subscription-exposes>"
provider = "kimi-code"

kimi_oauth は claude_oauth / chatgpt_oauth と同様にプール対応です — account の代わりに accounts = [...] を使うと、保存済みの複数の Kimi アカウントへ負荷を分散できます。詳しい手順は Kimi → Kimi Code（OAuth サブスクリプション） を参照してください。

例えば、Kimi（Moonshot）のモデルを shunt 経由でルーティングするには:

[providers.kimi]
kind = "anthropic"
base_url = "https://api.moonshot.ai/anthropic"
auth = "api_key"
api_key_env = "MOONSHOT_API_KEY"

[[routes]]
model = "kimi-k3[1m]"
provider = "kimi"

[[routes]]
model = "kimi-k2.7-code"
provider = "kimi"

そして export MOONSHOT_API_KEY=… し、Claude Code を shunt へ向け、kimi-k3[1m] を選択します（ANTHROPIC_CUSTOM_MODEL_OPTION または ANTHROPIC_MODEL 経由）。shunt check を実行して検証してください — ルート内の未知のプロバイダー、api_key_env の欠落、不正な base_url を報告します。

すべてのプロバイダーキー（kind、auth、api_key_header、count_tokens、…）は Configuration Reference に記載されています。

サブエージェントプラグイン

pleaseai/shunt マーケットプレイスは、各プロバイダーのモデルに固定された既製の Claude Code サブエージェントを出荷しています — モデルごとに 1 つのエージェントです。プラグインをインストールし、モデルを @ メンションするか CLAUDE_CODE_SUBAGENT_MODEL を設定します。各エージェントの model: フロントマターはそのサブエージェントだけを迂回させ、メインセッションは Claude のまま残ります。

/plugin marketplace add pleaseai/shunt
/plugin install shunt-xai@shunt

各プラグインは依然として shunt.toml でそのプロバイダーをルーティングし（上記のセクションを参照）、対応する認証情報をエクスポートする必要があります — プラグイン自身の README に正確なルートと環境変数が記載されています。grok モデルはどちらの xAI プロバイダーでも提供できます: xai（API キー、トークン単位で課金）または grok（shunt login xai 経由の SuperGrok / X Premium+ サブスクリプション。ティアでゲートされます — 403 の場合は xai にフォールバック）。