プロバイダーカタログ

ZeroClawに付属するすべてのモデルプロバイダーファミリー。各項目について、設定の形式、認証とエンドポイントの動作に関する注意事項、[providers.models.<type>.<alias>]配下で使用するスロットキーを記載します。

ユニバーサルフィールド（api_key、uri、model、…）と解決順序については Configuration を参照してください。

以下の例では、エイリアスの片方が運用者の選択によるものであることを強調するために、エイリアスとして home を使用しています。work、personal、cn、prod など、適切な名前を自由に選んでください。エージェントからは model_provider = "<type>.<alias>" で参照します。

ネイティブ

Anthropic / Claude: スロット `anthropic`

Claude Max 向けに、Console API キーと claude setup-token で生成されたトークンをサポートします。両方の認証情報形式は、正規の anthropic スロットの api_key フィールドに保存されます。Quickstart ではこれらを api_key と setup_token の選択肢として提示します。ストリーミング、ツール呼び出し、ビジョン、推論のすべてがサポートされています。カスタムエンドポイント（Anthropic 互換プロキシ、例えば Z.AI の Anthropic API）もこのスロットに設定します。uri を設定してオーバーライドしてください。

OpenAI: スロット `openai`

GPT-4o、GPT-5、oシリーズの推論モデル。推論をストリーミングする場合、推論は TextDelta でラップされた StreamChunk のオプションの reasoning フィールドに含まれます。Streaming を参照してください。

OpenAI Codex: `requires_openai_auth = true` を指定した `openai` スロット

OpenAI Codex のサブスクリプション認証は openai スロットに置かれます。POST /v1/responses 経由でルーティングするには wire_api = "responses" を設定し、エントリ上の api_key フィールドの代わりに Codex サブスクリプションログイン（Codex CLI 独自の ~/.codex/auth.json から取得）を使用するには requires_openai_auth = true を設定します。サブスクリプションパスは OPENAI_API_KEY を読み取りません。この変数は従量課金の openai API キーモードにのみ適用されます。認証情報モデルについてはプロバイダー設定 → OAuth およびサブスクリプション認証を参照してください。

Ollama: スロット `ollama`

Ollama のネイティブな /api/chat によるローカル推論。format によるスキーマベースの構造化出力。API キー不要。

Bedrock: スロット `bedrock`

Gemini: スロット `gemini`

GoogleのGemini API。ビジョンと事前実行されたグラウンド検索をサポートしています（PreExecutedToolCall イベントについてはストリーミングを参照してください）。

Gemini CLI: スロット `gemini_cli`

gemini CLI へシェルアウトします。CLI の既存の認証を使用します。

Grok Build CLI: スロット `grok_cli`

ドキュメントに記載された grok agent stdio ACP サーフェスを通じて Grok Build CLI をシェルから呼び出し、デフォルトでは CLI のログインキャッシュを使用します。grok login を実行するか、以下に示す明示的な API キーブリッジを使用してください。型付きエイリアス api_key は使用されず、エイリアスが明示的にオプトインしない限り、環境にある XAI_API_KEY も継承されないため、Grok CLI が認証の主体であり続けます。これは唯一のトランスポートであり、改行区切りの JSON-RPC で initialize → authenticate → session/new → session/prompt の順に実行します。小さいプロンプトも大きいプロンプトも stdin 経由で送信され、argv やプロンプトファイルに現れることはありません。

文書化された ACP 統合とデフォルト引数プロファイルは、以前のベースライン 0.2.111 とともに、Grok Build CLI 0.2.118（ACP advertise/live プローブ）に対して検証されています。外部 CLI のアップグレードは互換性の変更として扱い、デプロイする前に grok agent stdio を再検証してください。

ACP のビジョン / 画像入力（現在の Grok Build の動作）

Grok Build CLI（0.2.118で確認済み）は、ACP の initialize で引き続き promptCapabilities.image = false を通知します。これはどちらの側でも環境変数による上書きではありません。ZeroClaw が Grok の通知を書き換えることは決してありません。ZeroClaw で制御できる唯一のものは、エイリアス単位で共有される設定フィールド vision です。

レイヤー	`0.2.118` での動作
ACP のアドバタイズ	`promptCapabilities.image = false`
デフォルトの `grok_cli`	`vision` が未設定の場合 → ZeroClaw はエイリアスを非ビジョンとして扱い、画像マーカーはテキストのままになります
`vision = true`	ZeroClaw はエイリアス上でビジョン対応を報告し、ACP `{type: image, data, mimeType}` ブロックを送信する（Grok の advertise は変更しない）
モデル認識	ライブプローブ: `session/prompt` は画像ブロックを受け付ける（プロトコルエラーなし）が、エージェントは画像を受信していないかのように応答した

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
# オプションの実験のみ: image=false を告知している場合でも ACP 画像ブロックを送信します。
# Grok Build 0.2.118 が画像を確実に認識または説明できるようになるわけではありません。
# vision = true

本番の grok_cli エイリアスでは vision を未設定のままにしてください。実際の画像理解を必要とするチャネル添付ファイルは、デプロイ済みの CLI が image = true を宣言し、かつライブスモークテストでモデルが画像コンテンツを使用することが確認されるまで、grok_cli にルーティングしないでください。その条件が満たされたら、一時的な vision = true オプトインを削除し、ZeroClaw がローカルオーバーライド（GrokCliModelProvider::acp_prompt_content）ではなく宣言ビットに従うべきかを再検討してください。

Ubuntu 24.04: `bwrap` がユーザー名前空間を必要とする場合も Grok サンドボックスを維持する

Grok Build 0.2.112 以降をデプロイする場合は、対象ホストで ACP の初期化を確認してください。kernel.apparmor_restrict_unprivileged_userns=1 が設定された Ubuntu 24.04 ホストでは、Grok は ACP の初期化前に bwrap: setting up uid map: Permission denied で終了することがあります。これはホストのサンドボックス設定の失敗であり、ACP、stdout、または認証の失敗ではありません。

ZeroClaw のデフォルトの --sandbox strict（または明示的な workspace プロファイル）を維持し、実際の Grok 実行ファイルにのみユーザー名前空間を作成する権限を付与します。これはホスト管理者による変更であり、グローバルなユーザー名前空間の制限を維持し、Grok のサンドボックスを無効にするものではありません。

readlink -f "$(command -v grok)"

プレースホルダーをその絶対パスに置き換えて、/etc/apparmor.d/grok-build-userns を作成します：

abi <abi/4.0>,

include <tunables/global>

profile grok-build-userns /absolute/path/to/grok flags=(unconfined) {
  userns,
}

次にそれを読み込み、プロファイルがアクティブであることを確認します:

sudo apparmor_parser -r /etc/apparmor.d/grok-build-userns
sudo aa-status | grep grok-build-userns

flags=(unconfined) は Ubuntu の実行ファイル単位の AppArmor 例外メカニズムです。指定した Grok バイナリには userns を許可しますが、AppArmor のファイルルールは追加しません。Grok 自身が要求するサンドボックスは有効なままで、ホスト全体のユーザー名前空間制限も有効なままです。Grok に AppArmor のファイル制限も必要な場合は、完全に制限された組織固有のプロファイルを使用してください。自己更新によってダウンロードされた実行ファイルのパスが変わる可能性があるため、Grok を更新するたびにパスを解決し、このプロファイルを再読み込みしてください。

このエラーを回避するだけの目的で --sandbox off を使用しないでください。これにより Grok のサンドボックスが無効になります。システム全体で kernel.apparmor_restrict_unprivileged_userns を無効にしないでください。xAI は通常の Linux サンドボックスに Landlock を使用することを説明しており、bubblewrap はカスタムの読み取り拒否プロファイルにのみ使用することを説明しています。カスタムの空でない deny リストを使用していない状態でこの問題が発生した場合は、バージョン、正確なエラー、サンドボックスプロファイル、および秘密情報を含まないホスト/AppArmor の診断情報を xAI に報告してください。

max_acp_stdout_bytes は、1 回のリクエスト中に Grok ACP 子プロセスから読み取る stdout 全体（プロトコルフレームおよびネイティブツールの更新を含む）に上限を設定します。デフォルトは 4 MiB です。レビュー済みのツール対応ワークロードで、より大きな上限値が必要な場合は、エイリアスごとに設定してください。

[providers.models.grok_cli.default]
model = "grok-4.5"
working_directory = "/srv/zeroclaw/grok-workspace"
env_passthrough = ["XAI_API_KEY"]
# オプション: デフォルトは 4 MiB、許容範囲は 1-64 MiB。
max_acp_stdout_bytes = 8388608

ZeroClaw を起動する前に、XAI_API_KEY をデーモンの環境にエクスポートします。ACP クライアントは、その名前が env_passthrough に列挙され、かつ 子プロセスの起動時 にプロセス環境に空でない値が存在する場合にのみ xai.api_key を選択します（長期間存続するプロバイダーハンドルにスナップショットとして取り込まれるわけではありません）。それ以外の場合は CLI のログインキャッシュにフォールバックします。型付きエイリアス api_key は引き続き拒否されます。これは、2 つ目の Config シークレットフィールドではなく、意図的なプロセス環境ブリッジです。値はプロバイダー TOML に書き込まれません。将来、型付きの Config ブリッジによって、運用者向けインターフェースを変更せずに設定時に同じ名前を読み込める可能性があります。

既存の絶対パスである working_directory が必要です。これは正規化され、子プロセスの cwd と ACP セッション境界の両方に使用されるため、プロバイダーがデーモンの cwd にフォールバックすることはありません。オプションの binary_path で PATH にないバイナリを選択できます。エイリアスの timeout_secs により、プロトコルの読み取りと書き込みに上限を設定します（デフォルトは 600 秒）。

子プロセス環境は spawn 前にクリアされます。組み込みの許可リストにあるプロセスランタイム、ロケール、プロキシ、CA の変数は引き続き利用できますが、その他の名前は、そのプロバイダーエイリアスが env_passthrough に一覧表示していない限りブロックされます。このフィールドは、明示的な XAI_API_KEY 認証ブリッジと、明示的に有効化された Grok ツール（クラウド CLI の認証情報など）が必要とする環境変数のためのものです。値は spawn 時に ZeroClaw プロセス環境から読み取られ、プロバイダー設定には保存されません。デフォルトのリストは空です。記載する内容は必要最小限にしてください。記載されたすべてのシークレットは、Grok およびそのエイリアスで有効化されたすべてのツールに公開されるためです。その他のプロバイダー所有の XAI_* 名と、すべての GROK_* 名は拒否されます。Grok が検出したユーザー設定およびプロジェクト設定と、エイリアスの extra_args が、Grok ツールポリシーを決定します。

デフォルトの argv には --no-auto-update、--no-plan、--sandbox strict、--permission-mode dontAsk、--tools "" が追加されます。デフォルトでは、ACP クライアントは権限リクエストを拒否して終了します。リクエストに reject_once オプションが指定されている場合、クライアントはエージェントのターン全体をキャンセルする代わりに、それを選択します。それ以外の場合は、リクエストをキャンセルします。要求されたツールは引き続き拒否されますが、Grok はその拒否を処理して最終回答を生成するか、ポリシーで許可されている操作で再試行できます。

--always-approve、--dangerously-skip-permissions、--yolo、または --permission-mode=bypassPermissions を明示的に設定したエイリアスは、ヘッドレス ACP の応答ポリシーを変更します。クライアントはリクエストの allow_once オプションを選択します。allow_always に置き換えることは決してなく、要求された allow_once オプションが存在しない場合はキャンセルします。この承認は現在の権限リクエストにのみ適用されます。Grok の権限ルールと有効な OS サンドボックスによって、操作が拒否または制限される場合があります。

[providers.models.grok_cli.ops]
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--permission-mode=bypassPermissions",
]

これらのバイパスフラグは、Grok がそのエイリアスでリクエストから利用可能なすべてのツールを、人間による承認の往復なしに実行するための認可として扱ってください。その他の権限モード（acceptEdits を含む）では、ACP の自動承認は有効になりません。Grok は ACP クライアントに問い合わせる前に、CLI の --allow / --deny ルールと、検出されたユーザー/プロジェクトの権限設定を評価します。これらの設定元は信頼されたオペレーターのポリシーです。一致する allow ルールによってツールを事前承認できるため、ACP クライアントに権限要求が届かない場合があり、プロジェクトの MCP サーバー、プラグイン、フックによって機能が追加される場合もあります。チャネルエージェントには、専用のレビュー済み working_directory を使用してください。

許可ルールがツールを事前承認しない場合でも、Grok は session/request_permission を引き続き送信し、ZeroClaw のデフォルトの一度拒否ポリシーによってツール呼び出しはフェイルクローズします。実際には、これはデフォルトの --sandbox strict 下でのシェル/execute ツールに影響します。現在の Grok Build では、CLI の --allow=Bash(...) ルールでも ACP ホストへのエスカレーションが発生する可能性があるため、ツールを有効にしたシェルエイリアスでは、明示的なバイパスフラグ（--always-approve / --permission-mode=bypassPermissions）を設定するか、ホストの承認なしで Grok が事前承認できるサンドボックスプロファイル（たとえば --sandbox=workspace）と許可ルールを組み合わせる必要があります。対応する --allow を付けた --tools=Read,Grep のような読み取り専用ツールの許可は、より限定的なオプトインとして残ります。

オペレーターは、エイリアス extra_args を使用してツールを付与したり、サンドボックス/権限ポリシーを緩和したりすることもできます。どちらのインターフェースも、サブプロセスの境界を広げるための明示的なオプトインです。Transport、prompt、model、session、cwd、update のフラグは引き続きプロバイダーが管理し、extra_args では拒否されます。位置引数と短い引数も拒否されます。既知の値を取るオプションは ["--flag", "value"] または --flag=value のいずれかを受け付けます。未知のオプション形式ではインライン形式が必要です。これにより、末尾の ACP コマンドを消費できないようにします。

Grok は、プラン、ツール呼び出し、または権限リクエストの前に agent_message_chunk として進行状況を出力することがあります。プロバイダーは、それらの ACP 境界で直前のメッセージセグメントを破棄し、最新の回答セグメントのみを返すため、プランニングやツール収集に関するナレーションはチャネルの返信として配信されません。明示的な --no-plan により、デフォルトのワンショットチャネルエイリアスが Grok のプランモードに入ることも防がれます。ツール/MCP 構成は引き続きオペレーターが制御する機能です。

ACP の stdout フレーム、stdout の集約、アシスタントテキスト、および stderr の処理には、子プロセスの実行中に上限が設けられています。stderr は読み出されますが、その内容が保存、ログに記録、または返却されることはありません。公開されるプロバイダーエラーは一定であり、子プロセスが制御するプロトコルの自由形式テキストをそのまま返しません。ワンショットリクエストのたびに（成功、タイムアウト、キャンセル、またはプロトコルエラーのいずれの場合も）、ZeroClaw は Unix では子プロセスの process group を、Windows では Job Object を終了させ、直接の子プロセスを回収します。これにより通常の子孫プロセスは対象になりますが、新しいセッションまたはプロセスグループを作成するプロセスは、Unix でのグループ強制終了を免れる可能性があります。Windows Job Object の対応は CI でコンパイル時にカバーされており、すべての Linux 開発ホストで完全に実行されるわけではありません。

推奨パターン: デフォルトチャネルのチャットボット

メッセージングエージェントには専用のプロバイダーエイリアス（たとえば agents.default）を使用してください。デフォルトエイリアスでは Grok 組み込みツールへのアクセス権は付与されません。Grok は通常のユーザー設定とプロジェクト設定を引き続き読み込むため、権限ルール、MCP サーバー、プラグイン、フックがチャネルの信頼境界に照らしてレビュー済みの専用ワークスペースを使用してください。オペレーターが承認したコーディング/運用エージェントには、別のエイリアスとワークスペースを使用してください。

返信意図の事前チェック（分類器）： ZeroClaw は、完全なエージェントループの前に短い REPLY / NO_REPLY[*] 分類を実行します。この事前チェックには、安定したチャット補完 APIを優先してください（たとえば HTTP/OAuth の xai スロットや、その他の CLI 以外のモデルエイリアス）。また、完全な回答用の model_provider にのみ grok_cli を使用してください。CLI エージェントのバックエンドは、単一のセンチネルトークンではなく計画の文章を出力することが多く、その文章がチャンネルメッセージ（“沈黙を保つ” / “Slack 返信なし”）として配信される可能性があります。空の classifier_provider は model_provider を再利用します。API モデルでは問題ありませんが、CLI チャンネルボットでは適していません。ACP チャンネルでは分類器を完全にスキップします。

# 完全な回答: ACP、厳格なサンドボックス、組み込みツールなし、レビュー済みの Grok 設定
[providers.models.grok_cli.default]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/default/workspace"

# REPLY / NO_REPLY の事前チェック - API（形式安定）。既存の xAI
# HTTP エイリアスがある場合はそれを再利用してください。これを grok_cli に向けないでください。
[providers.models.xai.default]
model = "grok-4.5"
# 通常の xAI プロバイダーと同じ uri / auth（OAuth セッションまたは api_key）

# Ops / コーディングエージェント: 明示的なポリシーとツールのオプトイン
[providers.models.grok_cli.ops]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
env_passthrough = ["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY"]
# 読み取り専用ツール: 対応する --allow により、ACP の承認なしで事前承認できます。
extra_args = ["--tools=Read,Grep", "--allow=Read", "--allow=Grep"]

# シェル対応の ops エイリアス: ACP の承認をバイパスするか、allow と
# Grok が事前承認するサンドボックスプロファイルを組み合わせます（workspace が一般的な選択です）。
[providers.models.grok_cli.ops_shell]
model = "grok-4.5"
binary_path = "/home/you/.grok/bin/grok"
working_directory = "/path/to/agents/ops/workspace"
extra_args = [
  "--tools=run_terminal_cmd",
  "--allow=Bash(printf *)",
  "--sandbox=workspace",
]

[agents.default]
model_provider = "grok_cli.default"
classifier_provider = "xai.default"
channels = ["slack.default"]   # 例

[agents.dependabot]
model_provider = "grok_cli.ops"

レイヤー	どこ	目的
返信の事前チェック	`classifier_provider` → API エイリアス（例: `xai.default`）	REPLY / `NO_REPLY[*]` のみ。CLI が思考テキストをメッセージ本文として扱うのを防ぎます
完全な回答	`model_provider` → `grok_cli.default`	Grok Build ACP; プロンプトは stdin からのみ
OS サンドボックス	デフォルトの `--sandbox strict`（または `extra_args` による上書き）	CWD + システムパスを読み取り、CWD + `~/.grok` + tmp に書き込みます。Linux では子プロセスのネットワークがブロックされます。組み込み機能は恒久的な認証情報境界ではありません。シークレットにはカスタム `deny` を使用してください
アプリの権限	空の組み込みツールセット + フェイルクローズドな ACP のデフォルト	明示的なバイパスフラグは `allow_once` を選択します。検出された Grok ルールによって、設定済みツールが事前承認されることもあります
チャネル配信	ZeroClaw `thread_replies` / チャネル設定	スレッド内の単一返信パス
オプションのゲート	Slack `mention_only` + `strict_mention_in_thread`	エージェントに到達する前に、言及されていないグループ／スレッドのトラフィックを破棄する（Slackを参照）；分類器とは独立して

チャネル向けエイリアスはデフォルトのままにし、専用のレビュー済みワークスペースを割り当てます。Grok によって検出された権限ルール、MCP サーバー、プラグイン、フック、および extra_args 内の権限／サンドボックス／ツールフラグは、信頼されたオペレーターのポリシーであり、サブプロセスの境界を拡大する可能性があります。

Grok CLI OS サンドボックス（ZeroClaw からの使用方法）

これは Grok Build のプロセスサンドボックス（grok サブプロセスに対する Landlock / Seatbelt / seccomp）です。これは [risk_profiles.*.sandbox_*] における ZeroClaw のツールサンドボックスではありません。これはネイティブツール呼び出し後に ZeroClaw ツールをラップします。オペレーターがプロバイダーエイリアスを Grok ツールで使用するよう設定した場合、その処理で有効な隔離を提供するのは Grok の --sandbox です。ZeroClaw のリスクプロファイルサンドボックスについては、Sandboxing も参照してください。

ZeroClaw は常に明示的なサンドボックスフラグを指定します。デフォルトは strict です。別のプロファイルを選択するには、そのプロバイダーエイリアスの extra_args に --sandbox=<profile> を設定します。周囲の Grok 設定や GROK_SANDBOX によって、プロバイダーが管理するデフォルトが暗黙的に緩和されることはありません。

プロジェクトの .grok/config.toml には、MCP / プラグイン / [permission] を記述できます。Grok はこのファイルを信頼されたオペレーターポリシーとして読み込みます。一致する allow ルールによって、ACP の権限要求なしでツールを許可できる場合があります。このファイルだけでは、アクティブなサンドボックスプロファイルは選択されません。プロファイルの名前とカスタムプロファイルの内容は、プロジェクトの <workspace>/.grok/sandbox.toml に記述できます。そのプロファイルを有効にするには、--sandbox=<name> を extra_args 経由で渡します。

組み込みプロファイル（Grok のサンドボックスドキュメントより）:

プロファイル	FS 読み取り	FS 書き込み	子プロセスネットワーク（Linux）	一般的な用途
`off`（デフォルト）	無制限	無制限	無制限	フルアクセス
`workspace`	どこでも	CWD + `~/.grok` + tmp	許可されています	日常のコーディング
`読み取り専用`	どこでも	`~/.grok` + tmp のみ	ブロック済み	広範な読み取りが許可されるケースを確認する
`strict`	CWD + システムパス	CWD + `~/.grok` + tmp	ブロック済み	デフォルトチャネルのチャットボット（推奨）
`devbox`	どこでも	ツリーの大部分	許可されています	使い捨て VM

子プロセスのネットワーク遮断は Linux 上の シェルの子プロセス にのみ適用されます。プロセス内の Grok ツール（LLM、組み込み Web 検索）には引き続きネットワークが必要です。メッセージングボットでは strict を優先し、デフォルトのファイルシステムへの書き込み可能範囲をエージェントのワークスペースと Grok ランタイムパスに絞ってください。組み込みプロファイルは恒久的な認証情報の境界ではありません。xAI のサンドボックスドキュメントでは、~/.ssh のようなパスが組み込みプロファイルによって保護される保証はないと警告しており、シークレット用にカーネルによって強制される deny リストを備えたカスタムプロファイルを推奨しています。エージェントがプロジェクトファイルを書き込まずにワークスペース外を読み取る必要がある場合にのみ、read-only を使用してください。

カスタムプロファイルの例（ワークスペースで定義し、ZeroClaw から選択）:

# <agent-workspace>/.grok/sandbox.toml
[profiles.channel-bot]
extends = "strict"
# オプションのカーネル拒否パス（空でない場合、Linux では bubblewrap が必要）:
# deny = ["**/.env", "**/*.pem"]

# ZeroClaw config.toml
[providers.models.grok_cli.default]
working_directory = "/path/to/agents/default/workspace"
extra_args = ["--sandbox=channel-bot"]

エージェントごとのサンドボックス: 異なる明示的な extra_args と専用の作業ディレクトリを持つ 個別のプロバイダーエイリアスを使用してください。チャンネルエイリアスは厳格な組み込みツールなしのデフォルト設定を維持し、各ワークスペースで検出された Grok 構成を確認して、各エージェントを対応する model_provider エイリアスに割り当ててください。

Azure OpenAI: スロット `azure`

resource、deployment、api_version はこの型付き設定に格納され、環境変数からは読み込まれません。

Copilot: スロット `copilot`

GitHub Copilot サブスクリプションをエージェント推論に使用します。認証には GitHub から取得した Copilot OAuth トークンを使用します。

Telnyx: スロット `telnyx`

音声指向のAIエンドポイント。リアルタイムのSIP通話には clawdtalk チャンネルと組み合わせて使用します。

KiloCLI: スロット `kilocli`

KiloCLI によるローカル推論。

Kilo AI Gateway: スロット `kilo`

[providers.models.kilo.home]
model   = "anthropic/claude-sonnet-4-6"
api_key = "..."
# endpoint = "gateway"  # デフォルト → https://api.kilo.ai/api/gateway

Kilo AI Gateway 経由の Cloud API。複数のモデルティア（free、balanced、pro）に対応した Bearer トークン認証を使用します。/models エンドポイントは公開されており（PUBLIC_MODEL_LISTING）、認証情報なしでモデル一覧を取得できます。ライブでクエリされるため、これがコストレートエディターに料金情報を提供するソースとなります。共有の models.dev カタログ（kilo キー）は、ライブエンドポイントに接続できない場合のフォールバックにすぎず、料金情報は含まれていません。

命名の移行: kilo は現在、このゲートウェイプロバイダーを指します。KiloCLI サブプロセスプロバイダーは kilocli スロット（同義語 kilo-cli）を保持します。以前 kilo という短縮名で CLI プロバイダーを構成していた場合は、kilocli に切り替えてください。

ZeroRouter: スロット `zerorouter`

[providers.models.zerorouter.gateway]
model   = "anthropic/claude-sonnet-5"
api_key = "..."   # ZeroRouter のキー（プレフィックスは `zcr_`）；または環境変数から注入
# uri = "http://localhost:8080/v1"  # セルフホストまたはローカルのルーター。ホスト型のデフォルトを使用する場合は省略

OpenAI互換のLLMゲートウェイ。Bearerトークン認証。ZeroRouterは現在ベータ版です。スロットはデフォルトで公開ホスト型デプロイメント https://zerorouter.ai/v1 を使用するため、設定なしでモデルの検出が機能します。ZeroRouterはセルフホストも可能（AGPL）です。ローカルの http://localhost:8080/v1 またはその他の場所にある独自のルーターに接続するには、uri を明示的に設定します。あるルーターで発行されたキーは別のルーターでは認証されないため、api_key は uri が指すデプロイメントから取得する必要があります。

このスロットが対応する chat-completions ワイヤーに加えて、ZeroRouter は OpenAI Responses API のインバウンド（POST /v1/responses）も提供するため、wire_api = "responses" を設定した Codex CLI の model_provider など、Responses ワイヤー対応のクライアントは、同じデプロイメントとキーを直接指定できます。

/v1/models エンドポイントは公開されています（PUBLIC_MODEL_LISTING）。そのため、モデル一覧とプロンプト／補完の料金は、認証情報なしでルーター自体からリアルタイムに取得されます。ライブで照会されるため、料金をコストレートエディターに反映するソースはこれになります（このファミリーには models.dev や OpenRouter へのフォールバックはありません）。推論にはキーが必要です。api_key を直接設定するか、他のプロバイダーキーと同様に環境変数から注入してください（api_key の解決順序については設定を参照してください）。

組み込みログインなし。 このプリセットは、標準の型付き api_key パス経由でのみプロバイダーを設定します。デバイスフローによるログイン、OAuth、またはプロバイダー固有の認証情報ストレージは追加しません。推論を実行するには、api_key（またはその環境変数による注入）を設定してください。

すべてのスロット

プロバイダーレジストリと設定スキーマから生成された、すべての正規スロット、それぞれのデフォルトエンドポイント、ローカルで実行されるかどうか、および設定フィールドの完全なセットです。スロットをクリックするとフィールドが展開され、フィールドをクリックすると設定方法を確認できます。固定エントリには正規のデフォルトが表示されます。operator required は、エイリアスに Azure リソースとデプロイ、または custom の uri などのエンドポイント入力が必要であることを意味します。dynamic / resolved at runtime のエンドポイントは、認証情報、リージョン、検出、または実行時の状態に依存する場合があり、必ずしも uri を必要としません。CLI 対応プロバイダーはローカルコマンドを使用します。

共有フィールド

すべてのプロバイダースロットはこれらのフィールドを受け付けます。スロット固有の追加項目については、以下の各プロバイダーごとに記載しています。

api_key 🔑 secret · default —

この model_provider のシークレット API トークン。model_provider のダッシュボード（OpenAI platform、Anthropic console、OpenRouter keys ページなど）から取得します。可能な場合は OS キーリング経由で保存され、config.toml に直接コミットしないでください。

任意のサーフェスに設定する場合:

Keyboard shortcuts

ZeroClaw Docs