プロバイダーの構成

プロバイダーは、opencodex に、モデルが存在する場所、モデルが通信するワイヤー アダプター、およびリクエストの認証方法を伝えます。

カスタムプロバイダーのコンテキスト

モデルのウィンドウが未報告・未設定の場合、Azure メタデータ、モデル ID による同梱ベンダー／集約メタデータ、有効な Context cap、128k の順で補完します。報告値と設定値は小さい方を使い、Context cap は引き続き上限となります。組み込みプロバイダーは変更しません。完全一致を優先し、大文字小文字やドット／ハイフンの別表記は曖昧でない場合だけ認めます。推定は Codex の圧縮予算や Claude を含むクライアントのカタログに反映されますが、ルーティングの実測能力とは区別します。同名モデルでも中継サービスの容量は保証されません。必要に応じて modelContextWindows または Context cap を設定してください。自動的な cap の有効化やモデルへの試験リクエストは行いません。OpenAI API の値は Codex サブスクリプションの上限ではありません。

この推定は既定で無効です。プロバイダーごとに inferContextWindow: true で有効にします。未設定の場合、ウィンドウがないモデルは有効な Context cap、次に 128k を使います。

GPT-6.1 Terra

GPT-6.1 Terra は GPT-5.6 Terra の後継として 2026年10月26日に公開されました。gpt-6.1-terra は gpt-5.6-terra と並行して利用でき、既定モデルやサブエージェントのモデル一覧は変更しません。GitHub Copilot では Responses を使用します。OpenRouter の ID は openai/gpt-6.1-terra で、コンテキストは 1,050,000、100万トークンあたり入力 $1.00、出力 $5.00 です。

ネイティブ Codex：既定コンテキスト 500,000、長文コンテキスト上限 872,000、既定 effort は low。段階は low、medium、high、xhigh、max、ultra です。ネイティブの ultra は通信時に max として送信します。ネイティブ行の高速モードは Fast のみです。

OpenAI API：コンテキスト 1,050,000、最大出力 128,000。入力はテキストと画像、出力はテキスト。知識カットオフは 2026-06-01 です。effort は none、low、medium（既定）、high、xhigh、max。エンドポイントは v1/responses と v1/chat/completions ですが、ツール呼び出しには Responses が必要です。

100万トークンあたり入力 $1.00、キャッシュ入力 $0.05、キャッシュ書き込み $1.25（30分）、出力 $5.00。入力が 272,000 トークンを超える場合、リクエスト全体の入力・キャッシュは 2×、出力は 1.5× となり、それぞれ $2.00 / $0.10 / $2.50 / $7.50 です。Fast モードは 2× です。

初回登録時のモデル選択

新しい非 OAuth 接続では、信頼できるモデル一覧の取得が完了するまでモデルの公開を保留します。Models タブの重複しないモデル行が20個以上なら、モデルのスイッチをすべて OFF にします。プロバイダー自体は ACTIVE のままです。実際の認証方式が OAuth または ChatGPT ログインなら既定値を維持します。

初回のプロバイダー登録にのみ適用され、更新、再ログイン、キー交換で既存の選択をリセットしません。初期設定後は Models または以下の CLI で必要なモデルを有効にできます。後から追加されるモデルのポリシーは変更しません。<model-id> を一覧の ID に置き換えてください。

ocx models live --provider openrouter
ocx models enable '<model-id>'
ocx models disable '<model-id>'
ocx models provider openrouter on

GUI で登録または OAuth ログインが完了すると、Models ページへ移動できる案内が表示されます。CLI はモデル管理コマンドを出力し、JSON にも次の操作を含めます。--no-wait は完了ではなくログイン待機を示します。ライブモデルのコマンドを使う前に ocx start でプロキシを起動してください。

プロバイダー関連のトップレベルフィールド

フィールド	タイプ	デフォルト	意味
providers	Record<string, OcxProviderConfig>	—	プロバイダー名からプロバイダー設定へのマップ。
openaiProviderTierVersion?	2	移行によって設定される	単一のオプション対応 OpenAI プロジェクションを完了としてマークします。
disabledModels?	string[]	—	Codex catalog と /v1/models から非表示にする model。直接の proxy 呼び出しはブロックしません。routed id は一覧から削除されます。account-qualified native id は該当する selector row だけを非表示にし、bare native GPT id は bare row とその model の全 account-selector row を非表示にします。Models ページに表示されるのは bare native 行と routed 行だけです。selector-qualified 行を 1 つだけ非表示にするには、この設定フィールドを直接編集してください。
omitDisabledNativeModels?	boolean	false	既定値は false です。config.json に "omitDisabledNativeModels": true を設定して ocx sync を実行すると、無効な native 行を catalog、cache、Codex 形式の HTTP モデル一覧から除外します。除外前に検証した継承テンプレートを保持するため routed 行のメタデータは変わりません。直接リクエストのルーティングも変わりません。
providerContextCaps?	Record<string, number>	{}	プロバイダーごとの有効なコンテキスト上限。通常のウィンドウは縮小されます。長いウィンドウに対応したネイティブモデルは、そのモデルが対応する上限まで拡張できます。
providerContextCapValues?	Record<string, number>	{}	プロバイダーごとに最後に選択した上限。無効にしても保持され、この値だけで上限が有効になることはありません。有効な値が保存済みの値より優先されます。
contextCapValue?	number	350000	初回の有効化で使う既定値。再び有効にすると、そのプロバイダーの選択値を復元します。setAll: true とともにグローバル値を変更すると、有効な上限だけを更新します。値を指定せずに setAll: true を送ると、設定済みの全プロバイダーの上限を現在のグローバル値で有効にします。
codexAccounts?	CodexAccount[]	[]	ChatGPT/Codex プール アカウントのメタデータは Codex Auth によって管理されます。秘密はcodex-accounts.jsonに別に住んでいます。
pausedCodexAccountIds?	string[]	[]	再開するまでプールの選択から除外されるアカウント (一時停止時のメイン __main__ アカウントを含む)。 手動の一時停止と再開は、同じアカウント・ワークスペースのメインログインとプール内の既存エントリにも反映されます。
codexAccountNamespaces?	Record<string, string>	—	任意の公開 model selector を保存済み Codex アカウント target に対応付ける任意の map。account-qualified picker row が有効な場合、target が存在する各 selector は Codex picker に個別の <selector>/<native-openai-model> row を追加し、各 row はそのアカウントだけを使用します。selector が 1 つでも有効な場合、bare native row は picker で非表示になりますが、明示的に無効化されない限り id は引き続き routing でき、raw /v1/models にも表示されます。
codexAccountPickerEnabled?	boolean	map が空なら off	有効な codexAccountNamespaces mapping から account-qualified Codex picker row を生成するかを制御します。true は mapping された行の表示を許可します。空でない map で省略した場合は後方互換性のため有効として扱われ、map が空なら off です。false は mapping を削除せず、明示的な <selector>/<native-openai-model> routing も無効にせずに、生成行を非表示にして picker の bare native 行を復元します。
activeCodexAccountId?	string	—	次のリクエスト用に手動で選択されたプール アカウント。選択するとスレッドのアフィニティがクリアされます。実行中のリクエストでは、取得された資格情報が保持されます。
codexAccountPriorities?	Record<string,number>	—	Codex pool のアカウント別選択順。アカウント ID → -100 から 100 の整数で、大きいほど先に使われ、未設定は 0 です。これは eligibility ではなく順序の境界です。選択は適格なアカウントを、まだ quota に余裕がある最上位 tier に絞り込み、その tier の中を accountPoolStrategy が選びます。tier が飛ばされるのは、そのメンバー全員が自身の 0 以外の実効しきい値（アカウント別上書き、未設定ならグローバル値）以上、cooldown 中、soft-avoid、一時停止、または再認証待ちのときだけで、usage 不明が tier を drain させることはありません。順序付けが不適格なアカウントを選択可能にすることはなく、すでにアカウントが結び付いた thread を再 bind することもありません。メインの __main__ も同じ条件で参加するため、Codex Desktop ログインを最後に使わせられます。エントリが 1 つもなければ挙動は従来どおりです。map が不正な場合は警告を出して順序付けを無効にします（config の修復処理は走りません）。ocx account priority と Codex Auth ページで管理します。
autoSwitchThreshold?	number	80	使用量ベースのプロアクティブ切り替えしきい値。quota は未紐付けタスクの次のリクエストを再評価できます。紐付け済みタスクは既定（pool.cacheAffinity）ではしきい値を超えても同じアカウントを維持し、アカウントが使い切られるか処理できなくなったときだけ離れ、その場合も実際に quota 余裕があり usage がより低いアカウントへだけ移ります。pool.cacheAffinity: false にするとしきい値で紐付け済みタスクも再評価します。fill-first は未紐付け割り当ての使い切り基準としてのみ使用し、通常の round-robin 選択は使用しません。既知の 5 時間、週次、30 日 quota window の最大スコアを使います。0 は使用量ベースの切り替えだけを無効にし、未紐付け割り当てや障害回復は無効にしません。
codexAccountAutoSwitchThresholds?	Record<string,number>	—	autoSwitchThreshold のアカウント別上書き（アカウント ID → 0〜100 の整数）。未設定はグローバル値を継承し、0 はそのアカウントからの使用量ベース切り替えだけを無効にします。メインの __main__ も指定できます。Codex Auth の各アカウントカードで管理します。 上書きを有効にすると、現在のグローバルしきい値が固定のアカウント別値としてコピーされます。0 を含む上書き値は、その後グローバル値が変更されても優先されます。無効にすると threshold: null を送信してエントリを削除し、現在のグローバルしきい値と今後の変更を継承する状態に戻ります。
accountPoolStrategy?	"quota" | "round-robin" | "fill-first" | "reset-first"	"quota"	新規/未紐付け Codex リクエストの割り当て戦略。live な (parent thread id, quota scope) affinity がなければ未紐付けで、プロキシ再起動や affinity リセット後は既存の表示タスクも未紐付けになり得ます。quota はアクティブアカウントがなければ既知 usage 最小の適格アカウントを選び、適格なアクティブアカウントが autoSwitchThreshold 未満なら維持します。しきい値到達後は未紐付けリクエストを移せます。紐付け済みタスクは既定ではアカウントが使い切られるか（既知 usage 100%）処理できなくなるまで維持され、離れるときは実際に quota 余裕があり usage がより低いアカウントへだけ移ります。フラグをオフにすると、しきい値で紐付け済みタスクの次のリクエストも実際に quota 余裕があり usage がより低い適格アカウントへ移せます。round-robin は未紐付けリクエストを均等分散し、fill-first は cooldown、使用不可、または drain threshold までアクティブアカウントへ割り当てます。 reset-first: 使用率のしきい値未満から、次の5時間枠または週次枠のリセットが最も近いアカウントを選びます。紐付け済みタスクは設定されたアフィニティ方針に従います。独立したモデル枠は使用率順です。 月次リセットはこの順序に使用しません。
pool.cacheAffinity?	boolean	true	紐付け済み Codex スレッド向けの cache-affinity 順序。pool.kernel とは独立で、既定はオンです。不正な値はオンとして読みます。live な紐付けが quota 余裕より優先され、quota は使用量が autoSwitchThreshold を超えたという理由だけではスレッドを移しません。一時停止、使用不可、または実際に使い切られたアカウント（既知 usage 100%）では離れますが、実際に quota 余裕があり usage がより低いアカウントへだけ移ります。false にするとしきい値での再紐付けに戻ります。affinity は固定ではなく並べ替えです。
accountPoolStickyLimit?	number	1	1 回の round-robin 選択で次へ進む前に保持する新規/未紐付けタスク割り当て数。カウンターは上流の成功後ではなくタスクの紐付け時に増えます。範囲 1–100。accountPoolStrategy が round-robin のときのみ。
upstreamFailoverThreshold?	number	3	今後の新しいセッションがフェイルオーバーする前に一時的なエラーが連続して発生する。 0 を無効に設定します。通常のResponses送信とネイティブcompact送信では、実証済みの接続前DNS/TCP到達不能障害はprovider-host単位で記録され、アカウントの健全性、アカウントのクールダウン、スレッド/セッションの親和性、アクティブアカウントの選択、Poolルーティングには影響せず、この閾値にもカウントされません。
codexFailureWindow?	boolean	true	60秒の失敗率。20件以上かつ25%以上でアカウントを劣化とし、新しいスレッドだけを避けます。10%以下が30秒続けば回復します。false では連続カウントだけを使います。
codexPinnedTransientPolicy?	"hold" | "detour-new-threads"	"hold"	手動ピンが劣化したとき、hold は警告を出して使い続け、detour-new-threads は新しいスレッドだけを別アカウントへ置きます。送信済みのターンは再送しません。
codexWsReuseAcrossTurns?	boolean	false	同一アカウントとスレッドで Codex WebSocket をターンをまたいで再利用します。既定はオフ。オンにすると忙しいソケットを最大750ms待ち、モデルやティアの変更では最大2本を残します。
upstreamHostCircuitThreshold?	number	0	ネイティブOpenAI forwardのResponses送信とcompact送信で、実証済みの接続前DNS/TCP障害に適用するオプトインのサーキットしきい値です。0で無効、1〜20ではその回数の終端論理リクエストが失敗するとprovider-originを30秒間遮断します。遮断中はアカウント選択やupstream送信の前にRetry-After付き503を返し、時間経過後はhalf-openリクエストを1件だけ許可します。タイムアウトとHTTP応答は数えず、HTTP応答が1件でもあれば回路を閉じます。 Codex Pool ルーティングでアカウントが固定されていない場合にのみ適用され、codexAccountMode: "direct" とアカウント修飾セレクターでは動作しません。
maxInboundBodyBytes?	number	0	受信する JSON 本文 1 件のデコード後のサイズを制限するバイト単位の設定です。省略または 0 でデフォルトの 256 MiB を維持し、設定値は 1〜512 MiB に制限されます。変更後は再起動が必要です。超過時はコード inbound_body_too_large のローカル HTTP 413 を返します。適用される上限が 256 MiB を超えると maxConcurrentInboundBodyBytes の共有ゲートも有効になり、リクエスト単位の上限だけを上げても共有予算は増えません。対象ルートと詳細は受信リクエスト本文の受け入れを参照してください。
maxConcurrentInboundBodyBytes?	number	536870912 (512 MiB)	バイト単位の任意のトップレベル共有受け入れ予算です。適用される maxInboundBodyBytes が 256 MiB を超える場合にのみ有効です。省略、0、無効な値は従来のデフォルト 512 MiB を使います。有効な正の整数は使用時に 512 MiB〜2 GiB (536870912〜2147483648) に制限されます。再起動が必要で、同一プロセス内のすべてのリスナーが 1 つの予算を共有します。受け入れの計上用であり、メモリの事前割り当て、RSS 上限、RAM に応じた自動調整ではありません。2 GiB には運用者の明示的な選択が必要です。設定例、キューとレスポンスのライフサイクルに伴う制約、デフォルトで解析前の完全な 512 MiB アップロードが 1 件だけになる理由は受信リクエスト本文の受け入れを参照してください。
modelCacheTtlMs?	number	300000	プロバイダーごとの /models キャッシュの鮮度ウィンドウ。
cacheRetention?	"none" | "short" | "long"	Anthropic ファーストパーティ: "long"、その他の Anthropic 互換エンドポイント: "short"	Anthropic プロンプト キャッシュ ポリシー: 無効、5 分間の一時的、または 1 時間の延長。未設定の場合、api.anthropic.com（API キーまたは OAuth アカウント プール）へのリクエストは 1 時間の TTL を使い、互換ゲートウェイやベンダーのエンドポイントは 5 分の TTL のままです。明示した値が常に優先されます。
tokenGuardian?	OcxTokenGuardianConfig	オフ	オプションのプロアクティブな OAuth 更新および Codex アカウントのウォームアップ ポリシー。

各戦略で使う実効しきい値は、アカウントの codexAccountAutoSwitchThresholds があればその値、なければグローバルの autoSwitchThreshold です。0 は使用量による先行切り替えだけを無効にし、起動時のバインド、ハードロック、クールダウン、モデル利用資格の確認、障害復旧は引き続き適用されます。

selector 名はユーザーが選ぶ公開 label であり、opencodex はアカウント role の意味を付与しません。 codexAccountNamespaces のキーは長さ 1〜64 文字、先頭と末尾は ASCII 英数字、内部には英数字、.、_、- を使用でき、予約済み JavaScript object 名は拒否されます。 値は有効な pool account id（内部 __main__ は不可）、または Codex Desktop アカウントを示す "@main" です。provider と予約済み openai / combo / policy との衝突は大文字小文字を区別せず検査され、 namespace 付き combo または routing-profile alias はその namespace prefix に selector を再利用できません。設定済み pool id や他の selector target も selector と再利用できません。raw account id と email は 非公開のままにし、selector を公開名として使ってください。明示的な選択の動作と優先順位は ルーティング構成を参照してください。

Codex Auth dashboard が管理する map には明示的な codexAccountPickerEnabled field があります。空の managed map を有効にすると privacy-safe selector が作られ、その後の account 追加は picker を非表示に している間も既存 label を変えずに map を拡張します。flag を省略した手書き map は自動拡張されません。 account を削除しても mapping は保持され、同じ id を再追加すると新しい selector ではなく既存 selector が戻ります。

予約済み OpenAI プロバイダー

openai および openai-apikey は固定予約 ID です。 openai.codexAccountMode はデフォルトでは "pool" で、メインアカウントと追加アカウント全体を選択します。 "direct" は、現在の呼び出し元/メイン ログインのみを使用します。 API は、設定された API キーまたはキー プールのみを使用します。ベア モデルまたは openai-apikey/<model> を使用します。クロスルート認証情報のフォールバックはありません。 API GPT-5.6 行は 1,050,000 コンテキスト / 最大 922,000 入力メタデータを伝送し、Pro 仮想 ID は reasoning.mode: "pro" を使用してベース ワイヤー モデルに書き換えられます。

openaiProviderTierVersion: 2 は、現在の単一プロバイダーの投影をマークします。出荷された v1 設定を移行する前に、opencodex は別のバックアップを置き換えずに config.json.pre-openai-tiers-v2.bak を作成し、既知の名前空間で選択された既知のレガシー ID を裸の ID に書き換えます。

プロバイダー名前空間のエイリアス

プロバイダーには、google-antigravity の agy のような組み込みの短縮名があります。設定済みのプロバイダー名または明示的なエイリアスが、大文字と小文字を区別せずにその短縮名を使用している場合、別のプロバイダーの組み込み短縮名はカタログ表示とエイリアスルーティングの両方で無効になります。たとえば、agy というプロバイダーを設定すると、Google のモデルは google-antigravity/<model> と表示され、agy/<model> は設定済みのプロバイダーを選択します。正規のプロバイダー名は引き続き大文字と小文字の完全一致が必要で、認識されない接頭辞には既存のモデルルーティングのフォールバックが適用されます。

プロバイダーエントリー (OcxProviderConfig)

フィールド	タイプ	意味
adapter	string	openai-chat、openai-responses、anthropic、google、kiro、cursor、ollama-native、azure-openai (または別名 azure) のいずれか。
baseUrl	string	アップストリーム API のベース URL。ほとんどの組み込み固定エンドポイントは不一致を無視します。衝突安全キー プリセットは、古い同じ名前のカスタム宛先を保持します。
requestPacing?	{ enabled, requestsPerMinute?, minIntervalMs?, maxConcurrentRequests?, models?, keySelection?, keys? }	上流の使用量、請求、レート制限表示とは別の、クライアント側の送信開始間隔調整です。maxConcurrentRequests は実行中リクエスト数を制限する正の整数で、プロバイダー規則またはモデル規則だけに設定できます。プロバイダー制限は全モデルに適用され、models は上流の正確なモデル ID に一致し、遅延を増やすか同時実行数を減らします。キュー待機は応答ヘッダーのタイムアウトを消費しません。HTTP と明示的なアダプターの fetchResponse/runTurn 送信を対象にします。同時実行数の上限がある場合、標準の Responses WebSocket ターンは応答本文の完了・エラー・キャンセル時に枠を解放できるよう HTTP/SSE を使います。 Cursor を含む runTurn アダプターでは、上限は物理送信数ではなく進行中のターン数を数えます。同じターンの RunSSE と BidiAppend は重なり得ますが、別のターンは待機します。後続送信にも開始間隔は適用されます。
requestPacing.keySelection?	"active", "round-robin"	通常リクエストのキー選択です。既定の active は保存済みキーと既存の障害時切替を維持します。round-robin は保存済み選択を変えず、利用可能なプールのキーを順に割り当てます。トークンや料金ではなく割当回数を分散します。
requestPacing.keys?	{ requestsPerMinute?, minIntervalMs?, maxConcurrentRequests? }	キー参照ごとの共通 RPM・開始間隔・同時実行上限です。全モデルで共有し、プロバイダーとモデルの上限も同時に適用します。同一参照は枠を共有しますが、同じ上流プロジェクトの別参照は独立クォータを意味しません。TPM と日次上限は管理しません。
responsesPath?	string	キー認証 openai-responses リクエストの相対リソース パス。 / で始まり、スキーム、クエリ、またはフラグメントが含まれていない必要があります。
chatCompletionsPath?	string	openai-chat リクエストの相対リソース パス。 responsesPath の対となる設定で、同じ形式ルールが適用されます。1つのアップストリームが Chat Completions と Responses を異なるプレフィックスで提供する場合に必要です。モデルごとの wire override はアダプターのみを変更し baseUrl は変更しないため、この設定がないと有効化された Chat リクエストが Responses ベースへ送信されます。同梱例は Z.AI です。
upstreamWebsocket?	boolean	openai-responses リクエストで使用するアップストリーム Responses WebSocket トランスポート（既定値は無効）。ファーストパーティの https://api.openai.com/v1 アップストリームでのみ有効です。カスタムプロバイダーのエンドポイントは常に制限付き HTTP/SSE を使用します。Bun はメッセージ全体を確保する前に受信 WebSocket メッセージのサイズ上限を適用できないためです。正規の ChatGPT openai プロバイダーでは、省略すると対象となるターンでアップストリーム WebSocket を使用し、false はストリーミングのターンを HTTP/SSE で送信し、true は拒否されます。false の間はネイティブのターン途中のステアリングとインジェクションを利用できません。このフィールドはクライアント側の websockets 設定とは独立しており、エンドポイントと認証情報のどちらも変更しません。HTTP のベース URL は SSE のままとなり、Responses 以外のパスと openai-chat リクエストは HTTP を使用します。
supportsServiceTier?	boolean	service_tier ケイパビリティの 3 状態です。true: fast モードが注入でき、呼び出し元の値も保持されます。false: フィールドは削除され、注入もされません (非対応と文書化されたアップストリームには送りません)。未設定: 未分類 — 呼び出し元の値はそのまま保持され、fast モードは注入しません。レジストリは正規 OpenAI (true)、DeepSeek、Volcengine Ark (false) を分類します。実際にティアをサポートするカスタム ゲートウェイにのみ明示的に設定してください。
preserveResponsesReasoningContent?	boolean	リプレイされる Responses reasoning アイテムの平文 reasoning コンテンツを消去せずに保持します (消去は ChatGPT バックエンドのルールです)。DeepSeek のように reasoning リプレイを受け入れるアップストリームで有効にしてください。プロキシ生成の ocxr1 エンベロープは常に削除されます。
disabled?	boolean	プロバイダーをディスク上に保持しますが、ルーティングおよびモデル/カタログのリストからは除外します。
apiKey?	string	API キー、またはリクエスト時に解決される ${ENV_VAR} / $ENV_VAR 参照。
apiKeyTransport?	"x-api-key" | "bearer"	Anthropic キーのヘッダー スタイル。デフォルトはネイティブ x-api-key です。キー認証 anthropic プロバイダーにのみ有効です。
apiKeyPool?	ApiKeyPoolEntry[]	マルチキープール。 apiKey はアクティブなエントリをミラーリングします。各項目には id、key、オプションの label、およびオプションの数値 addedAt があります。
defaultModel?	string	このプロバイダーが明示的なモデルなしで選択された場合に使用されるモデル。
models?	string[]	初期／フォールバックモデル一覧。liveModels: false で models が空でなければ、その後に retainModels を追加します。models が空または省略されている場合は、設定済みの defaultModel、retainModels の順に初期一覧を作り、重複 ID は最初の出現だけを残します。
liveModels?	boolean	開始/同期時にライブ カタログをフェッチします (デフォルトは true)。カスタムプロバイダーは ${baseUrl}/models を使用します。組み込みはレジストリ URL とフィルターを使用する場合があります。
selectedModels?	string[]	検出後のカタログ許可リスト。空でない場合は、それらの ID のみが公開されます。空または省略すると、検出されたすべてのモデルが公開されます。
modelDisplayNames?	Record<string, string>	このプロバイダーの正確なネイティブモデル ID をキーにした、永続的な表示専用ラベルです。大文字と小文字は区別されます。ラベルはプロバイダーカタログのメタデータより優先され、認証、アダプター、ルーティング、課金、上流リクエストには影響しません。例外として、直接の provider/model セレクターが既知の ID、エイリアス、retainModels のいずれにも一致しない場合（ライブ一覧がまだ取得されていない間など）、エンコード形が一致するキーをネイティブ ID として送信します。マップは検出上限と同じ 2,000 件までです。
contextWindow?	number	アップストリームのメタデータが無い場合に使うプロバイダー全体のコンテキスト値。メタデータがある場合は上限として働き、より小さいライブ値をそのまま残します。Models ダッシュボードでは providerContextCaps とは別に設定します。
modelContextWindows?	Record<string, number>	モデルごとのコンテキスト値および上限。contextWindow より優先され、ウィンドウが不明なら設定値を使い、より小さいライブメタデータがあればそちらが優先されます。
inferContextWindow?	boolean	カスタムプロバイダーのみ、既定は無効。true で欠けたウィンドウを同梱モデルメタデータから補完します。推定値であり、中継の容量を検証したものではありません。
modelInputModalities?	Record<string, string[]>	["text"] や ["text", "image"] などのモデルごとの入力ヒント。
modelMaxInputTokens?	Record<string, number>	カタログの自動圧縮ヒントに使用されるモデルごとの正の最大入力制限。
modelAutoCompactTokenLimits?	Record<string, number>	モデルごとの正の安全な整数によるソフト自動圧縮予算。実効値であるコンテキストまたは最大入力の 90% の上限を下げることだけができ、有効なコンテキストウィンドウを解決できない場合は出力されません。canonical openai では、キーは provider や account-selector の接頭辞を含まない、サポート対象の正確なネイティブモデル ID でなければなりません。provider PATCH はエントリをマージし、キーを null にするとそのキーを削除し、フィールド全体を null にするとマップを消去します。これらの null tombstone は PATCH 専用です。
defaultMaxOutputTokens?	number	クライアントが max_output_tokens を省略した場合の、プロバイダー全体の openai-chat フォールバック。
modelMaxOutputTokens?	Record<string, number>	モデルごとの openai-chat フォールバック バジェットがプラスになります。正確な/パターン一致はプロバイダーのデフォルトを上回ります。
modelCosts?	Record<string, ProviderCostOverlay>	モデルごとの表示価格（100万トークンあたりの米ドル）。そのプロバイダーの正確なアップストリーム モデル ID をキーにします（プロバイダー識別子やルーティングされた provider/model ラベルではありません）。値は input, output, cacheRead, cacheWrite の 4 フィールドです（例: { "deepseek-v4-flash": { "input": 0.14, "output": 0.28, "cacheRead": 0.0028, "cacheWrite": 0 } }）。組み込みカタログにないモデル ID も、任意の OpenAI 互換エンドポイントを対象とするカスタムプロバイダーや、ローカル・内部プロバイダーで有効です。ユーザー設定の価格は Logs の ~$ と Usage の見積もりで組み込みカタログより優先されます。過去のエントリも現在のオーバーレイで再計算されるため、価格を編集すると過去の合計が変わることがあります（フォールバック順: ユーザー設定 → jawcode カタログ → expected-price オーバーレイ → モデル別ベンダー価格）。ユーザーが明示的に全レートを 0 にした場合は、既知のゼロ料金として見積もります。自動料金に戻すにはそのモデルの設定を削除してください。カタログの全ゼロ料金は引き続きフォールバックします。各レートは 0 以上の有限数で、最大 1,000,000（100万トークンあたりの米ドル）です。範囲外の行は管理境界で拒否され、読み込み時に破棄されます。表示専用の見積もりであり、ルーティング・アカウント選択・クォータ・請求には影響しません。
headers?	Record<string, string>	追加の上流ヘッダー。認証、Cookie、API キー ヘッダー、埋め込まれた改行、および無効な名前は拒否されます。
openRouterRouting?	OpenRouterProviderRouting	デフォルトの OpenRouter order、only、および allowFallbacks 設定。 openai-chat を持つ正規 OpenRouter に対してのみ有効です。
modelOpenRouterRouting?	Record<string, OpenRouterProviderRouting>	プロバイダー全体の OpenRouter 設定を置き換える正確なモデル ID のオーバーライド。
vercelGatewayRouting?	VercelGatewayRouting	デフォルトの Vercel AI Gateway order、only、および sort ("cost" | "ttft" | "tps") 設定。openai-chat を使用する正規の Vercel AI Gateway に対してのみ有効です。
authMode?	"key" | "forward" | "oauth" | "local"	認証モード (デフォルトは key)。 OAuth/サブスクリプション認証情報は config.json の外部に保存されます。 local は、レジストリ エントリで許可されているプロバイダーに限定されます。
codexAccountMode?	"pool" | "direct"	正規の openai のみ。デフォルトはプールです。直接はプール状態をバイパスします。
refreshPolicy?	"proactive" | "lazy-only" | "disabled"	この OAuth プロバイダーの Token Guardian ポリシーをオーバーライドします。
reasoningEfforts?	string[]	プロバイダー全体の Codex 推論ラベルをアドバタイズして送信します。
modelReasoningEfforts?	Record<string, string[]>	モデルごとのラベル。空のリストは努力制御を非表示にします。
modelSupportsReasoningSummaries?	Record<string, boolean>	モデルを false に設定して、概要の広告を停止し、概要配信フィールドを削除します。
modelReasoningSummaryDelivery?	Record<string, "sequential" | "sequential_cutoff" | "concurrent" | "concurrent_cutoff">	モデルごとの応答配信列挙型。既存の配信フィールドを書き換えます。
modelAdapters?	Record<string, string>	混合配線ゲートウェイのモデルごとの openai-chat または openai-responses 配線オーバーライド。明示的なエントリはレジストリのデフォルトを破ります。DeepSeek のプリセットは deepseek-v4-flash のネイティブ Responses を選択でき、GitHub Copilot は モデル (gpt-5.3-codex, gpt-5.4, gpt-5.4-mini, gpt-5.5, gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-6.1-sol, gpt-6.1-terra, gpt-6-astra, grok-4.5, grok-4.6, mai-code-1.1-flash, mai-code-1-flash-picker) を Responses 専用デフォルトとして宣言します。これらのモデルはエージェント トラフィックで /chat/completions を拒否するためです。gpt-5.4-nano のようなビルトイン デフォルトのないモデルはここでオプトインできます。単線アップストリーム ピンと正規の ChatGPT 転送はオーバーライドを拒否します。
xAI Responses オプトイン（ダッシュボード）	スイッチ	xai のみで、grok-4.5 と grok-4.6 の modelAdapters エントリを原子的に設定または削除します。片方だけの場合は、次のスイッチ操作で両方が正規化されるまで混合状態を表示します。他のオーバーライドと tier 動作は変わりません。 Grok 4.7 は OAuth でレジストリの既定値により Responses を使用し、明示的な modelAdapters["grok-4.7"] = "openai-chat" で Chat に切り替えられます。
xaiResponsesXSearch?	boolean	デフォルトでは無効です。xAI Responses の宛先では、最終的なリクエスト正規化後もライブの web_search ツールが残っている場合にのみ、プロバイダーがホストする x_search 宣言を追加します。既存の宣言は重複させず、呼び出し元の tool_choice / allowed_tools セレクターの範囲を拡張することもありません。また、これは search.xSearch オプションを持つウェブ検索サイドカーとは別です。
modelPreferHostedTools?	Record<string,string[]>	hosted tool namespace を予約する非 forward Responses gateway 向けの完全一致モデル opt-in。現在は ["image_generation"] のみを受け付けます。一致したモデルは openai-responses wire を使い、その hosted tool をサポートする必要があります。競合するクライアント image_gen 宣言を除去し、呼び出し元の tool choice を維持するため selector も書き換えます。OpenAI API の仮想 -pro モデルでは、まず選択した公開 ID に一致させ、解決後のベース wire-model ID をフォールバックとして使用します。modelAdapters は公開 ID、次にベース ID の順に解決し、後者の結果が最終 wire を決めます。未設定のモデルは通常の alias 動作を維持します。
annotateEmptyToolOutputs?	boolean	存在するものの空であるツール結果を、モデルに届く前に短いマーカーへ置き換え、空白の結果が欠落した結果として解釈されないようにします。空文字列とテキストのみのパーツ配列に適用されます。画像、ファイル、暗号化されたパーツには一切手を加えません。組み込みレジストリでは DeepSeek のデフォルトが true で、それ以外は未設定です。プロバイダーを対象外にするには false を設定します。明示的な false は、後続の編集でこのフィールドが省略されても保持されます。PATCH /api/providers?name=<provider> は true、false、またはオーバーライドを消去してレジストリのデフォルト動作へ戻すための null を受け付けます。
reasoningEffortMap?	Record<string, string>	ラベルを推論するためのプロバイダー全体のワイヤ エイリアス。ラベルを "__omit__" にマッピングすると、アップストリームのリクエストから推論フィールドが完全に省略されます（例: ディープ モードに reasoning_effort の省略が必要な Ollama モデル向け）。
modelReasoningEffortMap?	Record<string, Record<string, string>>	推論ラベルのモデルごとのワイヤ エイリアス。ラベルを "__omit__" にマッピングすると、アップストリームのリクエストから推論フィールドが完全に省略されます。
reasoningWireFormat?	"gateway-object"	reasoning_effort ではなく reasoning: { enabled, effort } を受け取る OpenAI 互換ゲートウェイ用です。ClinePass プリセットが自動設定します。
noReasoningModels?	string[]	推論/思考パラメーターを拒否するモデル。
noTemperatureModels?	string[]	発信者指定のtemperatureを拒否するモデル。
noTopPModels?	string[]	発信者指定のtop_pを拒否するモデル。
noStopModels?	string[]	発信者指定のstopを拒否するモデル。openai-chatアダプター、Chatパススルー、Responsesパススルーはこれらのモデルに対してこのフィールドを送りません。組み込みのxaiプリセットは、xAIがこれを拒否すると文書化している推論モデル(grok-4.7, grok-4.6, grok-4.5, grok-4.3, grok-4.20-multi-agent-0309, grok-4.20-0309-reasoning, grok-build-0.1)をここに登録します。grok-4.20-0309-non-reasoning, grok-composer-2.5-fastは呼び出し元のstopをそのまま受け取ります。
noPenaltyModels?	string[]	存在/周波数ペナルティを拒否するモデル。 組み込みのxaiプリセットは、xAIがこれらを拒否すると文書化している推論モデル(grok-4.7, grok-4.6, grok-4.5, grok-4.3, grok-4.20-multi-agent-0309, grok-4.20-0309-reasoning, grok-build-0.1)をここに登録します。非推論モデルは呼び出し元のペナルティをそのまま受け取ります。
noStructuredOutputModels?	string[]	openai-chat エンドポイントが response_format を拒否する正確なモデル ID。要求モデルが項目と完全一致する場合だけフィールドを省略し、その他の openai-chat モデルでは structured-output 変換を維持します。
noJsonSchemaModels?	string[]	openai-chat エンドポイントが json_schema 形式は拒否しつつ json_object は受け入れる正確なモデル ID。この要求はフィールドを削除せず json_object に降格して送るため、JSON を求めた呼び出し側は散文ではなく JSON を受け取れます。両方の一覧に載るモデルでは noStructuredOutputModels が優先します。opencode go / opencode zen プリセットが DeepSeek 経路に既定で載せます。
foldDeveloperRoleToSystem?	boolean	openai-chat の宛先が developer ロールを受け付けるかを記録します。foldDeveloperRoleToSystem が未設定なら system、true なら system、false なら developer として送ります。未設定はこの宛先について何も記録されていないことを意味し、true は上流がロールを拒否する記録、false は受け付ける記録です。singleLeadingSystemMessage が有効でない場合、メッセージは会話内の位置を保ち、変わるのはロールだけです。ロールを拒否する宛先は 400 role 'developer' is not allowed を返してターンが始まらないため、未記録の既定は畳む側にしてあります。
parallelToolCalls?	boolean	並列ツール呼び出しを切り替えます。 OpenAI Chat はデフォルトでオンになっています。非チャット アダプターは明示的な true でのみアドバタイズします。
responsesItemIdRepair?	{ message?: string[]; reasoning?: string[]; repairMissingTerminalIds?: boolean; repairInvalidIds?: boolean }	正確なプレースホルダー ID、欠落している端末 ID、および（repairInvalidIds で）正規の msg_/rs_ 接頭辞を欠く message/reasoning ID に対するダウンストリーム SSE 修復はデフォルトで無効になっています。関数呼び出し ID は決して書き換えられません。組み込み DeepSeek は最後の 2 つをデフォルトで有効にします。
responsesSnapshotRepair?	boolean	デフォルトで無効のクライアント向け修復です。SSE と JSON の Responses ライフサイクルで欠落した status、output、ツールメタデータを補完し、raw 検査と永続化は変更しません。
promptCacheKey?	boolean	openai-chat のプロバイダー全体で prompt_cache_key の転送を有効にします。アダプターは受け取ったキーを転送し生成しませんが、Claude Messages 変換では metadata.user_id、またはメタデータがなければモデル・システム・ツールの組み合わせから導出します。プリセットが指定しない限り既定は無効です。Mistral はプロンプトキャッシュ契約に従い有効で、明示的な false で無効になります。上流が対応を明記する場合のみ有効にしてください。厳格なゲートウェイは未知のフィールドを HTTP 400 で拒否する場合があります。
retryOn429?	{ enabled?: boolean; attempts?: number; intervalMs?: number; maxIntervalMs?: number; respectRetryAfter?: boolean }	API キーのプロバイダーのみ（authMode: "key"）。未設定なら無効ですが、正規の OpenCode Go と Command Code、および正規の Mistral の openai-chat は例外で、再送 6 回、間隔 10 秒、上限 60 秒のポリシーを使います。オブジェクトを指定すると有効になり、enabled: false はこの既定ポリシーも無効にします。ストリーム開始前の HTTP 429 で Retry-After または固定間隔を待ち、キーの切り替え前に同じキーで同じリクエストを再送します。テキストターンの回復、Responses passthrough、画像・動画ブリッジ、web-search サイドカー、ターミナル継続が対象で、独自の runTurn は対象外です。attempts は最初の 429 後の同一キー再送回数（総送信数 = attempts + 1）で、リクエスト全体で共有します。使い切ると同一キーの再送だけが止まり、通常のキー切り替えか最終エラー処理に進みます。キー認証の passthrough では切り替えがなく、そのまま 429 を返します。正規の Mistral Chat で明示的な上流の待機時間が許容上限を超えると、同一キー再送を止めて元の Retry-After を返しますが、別のプールキーが処理できる場合があります。他のプロバイダーでは待機時間を上限で切り詰めます。Mistral は認証情報とモデルごとに期限を共有します。requestPacing.enabled: false または retryOn429.respectRetryAfter: false で無効になります。再試行時刻のない 429 で分単位の予算不足が検証されると、控えめな 60 秒の回復待機後、プローブを 1 回実行し、成功すれば通常のトラフィックを再開します。正常なトラフィックから次のトークン消費は予測しません。公表された許容量を使い、既知の月間枠の枯渇は除外し、正確なリセット時刻を保証せず、履歴の圧縮も起動しません。Codex 自体は 429 を再試行しません。オブジェクトの既定値：enabled: true、attempts: 3、intervalMs: 5000、maxIntervalMs: 60000（待機の上限、設定の最大値は 600000）、respectRetryAfter: true。
transientRetryOn5xx?	{ enabled?: boolean; attempts?: number }	キー認証の openai-chat および openai-responses プロバイダーのみ。authMode: "forward" のプロバイダー（ChatGPT アカウントプール）はこのオプションを読まず、既定の再試行段数を維持します。ストリーム開始前に上流から返される一時的なステータス（500、502、503、504、520、521、522）に対するオプトインの再試行です。設定がなければ無効で、オブジェクトを指定すると enabled: false でない限り有効になります。最初の Responses リクエスト、ターミナルガード継続、ネイティブの /v1/chat/completions、および 429／アカウント回復時の再取得が対象です。attempts は最初の送信を含め、1 回のリクエストで許可される上流への送信総数です（1～10、デフォルトは 3）。接続リセット回復と共有するリクエスト単位の単一予算であるため、3 を指定した場合、プロバイダーに到達する実リクエストは最大 3 回です。待機には 400 ms を基準とする固定式の指数バックオフを使用し、上限は 5 秒で、Retry-After に従います。レート制限を扱う retryOn429 とは別の機能であり、ストリーム開始後の失敗は再送されません。 各 Combo ターゲットでは、事前予約した初回送信もそのターゲットの設定総数に含まれます。attempts: 1 は 1 回だけ送信し、予約を返却して余裕を作ったり、共有上限を広げたりしません。送信前のローカル拒否やキャンセルでは未使用の予約を解放します。
retryOnReset?	{ enabled?: boolean; replacements?: number }	ネイティブ openai-responses プロバイダー（authMode: "forward" を含む）と、上流ヘッダー受信前の汎用 Responses 変換経路に適用されます。呼び出し側が何も観測しないまま失敗した送信を、オプトインで置き換えます。設定がなければ無効で、オブジェクトを指定すると enabled: false でない限り有効になります。レスポンスヘッダーが届く前に接続が切れた場合と、ヘッダー後に SSE 本文が制御イベントだけを運んだまま切れた場合の両方が対象です。canonical ChatGPT upstream WebSocket で create フレームの送信後、Responses イベントが届く前にソケットが閉じたかエラーになった場合も同じく対象で、その置き換えは HTTP で送信します。置き換えるのは自己完結したリクエストだけで、store: false、完全な input、previous_response_id / conversation / stream_id がないこと、クライアントが実行するツールのみ、が条件です。replacements は、すべてのレッグとすべてのコンボ子リクエストを合わせて 1 つの論理リクエストが行える置き換え送信の回数です（1..2、デフォルトは 1）。レッグ単位の再試行回数でも送信予算でもないため、置き換え送信もそのレッグがすでに持つ送信許容量に収まる必要があります。すでに出力やツール呼び出しを送ったリクエストは、この値に関わらず置き換えません。元の送信がすでに開始されていた場合は置き換えた推論も課金される可能性があるため、既定では無効です。 汎用変換経路では、初回送信と再構築後の送信のどちらも、同じ許可と送信予算でヘッダー受信前の接続リセットを置き換えます。アダプター独自のトランスポートと、上流ヘッダー受信後の変換ストリーム障害は対象外です。
autoToolChoiceOnlyModels?	string[]	tool_choice が auto または none のみを受け入れるモデル。強制的な選択は格下げされます。
preserveReasoningContentModels?	string[]	チャット履歴に以前のアシスタント reasoning_content が必要なモデル。ダッシュボードから保存しても、保存済みのリスト（[] を含む）は保持されます。PATCH /api/providers?name=<provider> は配列、または消去するための null を受け付けます。 アダプター、ベース URL、または認証モードを変えて別の宛先に移す保存では保持されません（下の節を参照）。
reasoningDetailsModels?	string[]	thinking を構造化された reasoning_details 配列で返すモデル（reasoning_split 使用の MiniMax M シリーズ）。ストリーム差分は累積スナップショットとして prefix-diff され、保持された reasoning は reasoning_content 文字列ではなく reasoning_details 配列としてリプレイされます。
requiresReasoningPlaceholderModels?	string[]	reasoning_content を欠いた tool_call 継続を上流が拒否するモデル（DeepSeek thinking モード）。リプレイキャッシュが外れた場合に最小プレースホルダーを注入。未設定時は preserveReasoningContentModels を引き継ぎ、[] で明示的に無効化。ダッシュボードから保存しても、保存済みのリスト（[] を含む）は保持されます。PATCH /api/providers?name=<provider> は配列、または消去するための null を受け付けます。 アダプター、ベース URL、または認証モードを変えて別の宛先に移す保存では保持されません（下の節を参照）。
thinkingToggleModels?	string[]	エフォート ラダーではなく thinking.enabled を使用してモデルをチャットします。
thinkingBudgetModels?	string[]	整数 thinking_budget を使用したチャット モデル。労力は予算の一部にマッピングされます。
noVisionModels?	string[]	ビジョン サイドカーを通じて送信されるテキストのみのモデル。マッチングでは、Ollama :size タグが許容されます。
escapeBuiltinToolNames?	boolean	Anthropic 互換ゲートウェイの組み込みツール名をエスケープし、返された呼び出しで復元します。
anthropicEofTolerance?	boolean	message_stop 前にストリームが終了しても、可視テキストまたは完全な JSON オブジェクトのツール入力が受信済みの場合に限り完了を許可します（Anthropic 互換ゲートウェイ向け）。デフォルトはオフ。
googleMode?	"ai-studio" | "vertex" | "cloud-code-assist"	Google トランスポート/認証モード。デフォルトはai-studioです。
googleToolSchemaPolicy?	"compatible" | "reject-lossy"	Google 専用です。省略時または compatible は互換スキーマと既存の非直接 400 修復を維持します。reject-lossy は初期損失または判定不能な上限付き比較を送信前に拒否し、制約を開く Vertex／Cloud Code Assist 修復を保留します。直接 AI Studio はこの修復を行いません。
project?	string	Vertex または Antigravity Cloud Code Assist プロジェクト ID。Vertex の API キーは、これが設定されているとプロジェクトエンドポイントを使い、未設定なら GOOGLE_CLOUD_PROJECT があっても express モードを使います。ADC は GOOGLE_CLOUD_PROJECT / GCLOUD_PROJECT にフォールバックします。"auto" を指定すると、Vertex の各 API キーが自身のプロジェクトを解決します（解決に成功した結果はキーごとにキャッシュし、解決に失敗したキーは後続のリクエストで再度プローブします）。1 つのキープールで複数プロジェクトを扱えます。ADC は "auto" を拒否します。
location?	string	Vertex のロケーション。API キーのプロジェクトエンドポイントは既定で global を使い、GOOGLE_CLOUD_LOCATION を無視します。ADC にはこの値か GOOGLE_CLOUD_LOCATION フォールバックが必要です。
mcpServers?	Record<string, CursorMcpServerConfig>	カーソルのみ: 標準入出力またはストリーミング可能な HTTP MCP サーバー。
desktopExecutor?	DesktopExecutorConfig	カーソルのみ: 外部コンピュータ使用および画面録画コマンド。
unsafeAllowNativeLocalExec?	boolean	カーソルのレガシー ブール値。新しいフィールドが設定されていない場合のみ、nativeLocalExec: "on" と同等です。
nativeLocalExec?	"off" | "codex-sandbox" | "on"	カーソルのローカル実行ポリシー。 off がデフォルトです。 codex-sandbox は現在、off と同様にフェールクローズされます。

LM Studio instruction compatibility: singleLeadingSystemMessage: true overrides chronological Chat instruction placement by merging text-only system/developer messages into one leading system message. The LM Studio preset enables it by default; set it to false to disable merging.

プロバイダーの登録・置換（POST /api/providers）では、メモリやファイルの設定を変更する前に responsesPath と chatCompletionsPath を検証します。PATCH /api/providers?name=<provider> はリクエスト本文を保存済みのプロバイダーにマージします。disabled 以外のフィールドを変更する更新（requestPacing のみの更新を除く）では、保存前にマージ後のプロバイダーのパスを同じ方法で検証し、保持されているパスが無効な場合は 400 を返して設定を変更しません。設定ファイルの読み込みにも同じ経路の規則が適用されます。

API キープロバイダーは、リテラルキーまたは環境参照を保持する場合があります。 OAuth プロバイダーは、ocx login によって設定された資格情報ストアを使用します。サブスクリプションに基づくクロード コードの起動動作は、claudeCode.authMode で構成されます。

プロバイダーの保存で保持されるもの

既存のプロバイダー名で POST /api/providers を送ると、保存済みの行はリクエストから組み立てた行で置き換えられます。ダッシュボードの追加・編集フォームはすべてのフィールドを送れないため、リクエストが省略した保存済みフィールドの一部は保存時に引き継がれます。そのうち次の 11 つは、特定のアップストリームの挙動を記録するものです：preserveReasoningContentModels, preserveResponsesReasoningContent, requiresReasoningPlaceholderModels, foldDeveloperRoleToSystem, singleLeadingSystemMessage, reasoningWireFormat, omitReasoningEffortWithToolsModels, promoteAdditionalTools, retryOn429, transientRetryOn5xx, retryOnReset。

保存	11 つの設定	保存済みの apiKeyPool
同じ宛先、フィールド省略	保存済みの値を保持（明示的な [] や false を含む）	保持
新しい宛先、フィールド省略	保持しない。新しい宛先のレジストリ既定値が適用されることがあります	保持しない
リクエストでフィールドを送信	リクエストの値	リクエストの値

宛先とは、アダプター、ベース URL（スキームとホストは大文字小文字を区別せず、末尾のスラッシュは無視）、そしてリクエストが指定した場合は認証モードです。別の宛先へ移すと、以前のアップストリームを表す 10 つの設定と、そのために発行されたキーのプールは引き継がれません。保存時に古い行の残りを新しい行へマージすることはありません。

PATCH /api/providers?name=<provider> は指定したフィールドだけを変更し、宛先に関係なくほかの保存済みフィールドはすべて保持します。10 つの設定をすべて受け付け、null で消去します。2 つの推論リストでは、空の配列は削除されず明示的なオプトアウトとして保存されます。

プロバイダーによるアウトバウンドの安全性診断

ダッシュボード接続テストとライブ モデル検出では、制限された GET 専用トランスポートが使用されます。送信プロキシを使用しない場合、opencodex はホスト名を一度解決し、その検証されたアドレスにのみ接続します。 HTTPS は元のホスト、SNI、および証明書の検証を保持します。プロバイダー設定では証明書チェックを無効にすることはできません。

これらの操作はサーバーで設定された送信 fetchを使用します。config.proxy で設定された、または SOCKS5 ALL_PROXY から継承したサーバーの SOCKS5 プロキシは、宛先が NO_PROXY に一致しない場合に OpenCodex の組み込みトンネルを使用します。HTTP_PROXY と HTTPS_PROXY は Bun のネイティブ HTTP(S) 処理を維持しますが、SOCKS 以外の ALL_PROXY はネイティブ HTTP fetch の経路にはなりません。URL とリテラル アドレスのチェックは引き続き実行されますが、選択されたプロキシが最終ルート、DNS 応答、ピアを決めるため、opencodex はそのピアを固定したり検証したりできません。これは明示的なセキュリティ制限です。

プライベート/ローカル宛先には allowPrivateNetwork: true が必要で、送信プロキシがアクティブな場合は、一致する NO_PROXY エントリが必要です。ループバックは自動的に追加されます。 CIDR エントリは解釈されないため、各 LAN ホストを明示的にリストします。マッチャーは、正確なホスト、ドメイン サフィックス、オプションのポート、括弧で囲まれた IPv6、および * をサポートします。たとえば、192.168.1.50 を明示的にリストします。メタデータとリンクローカル宛先はブロックされたままになります。診断リクエストはリダイレクトを拒否し、資格情報が剥奪されたターゲットを報告します。通常のプロバイダー要求のリダイレクト レビューは、この診断ガードとは独立したままになります。

Clash / Surge / Mihomo 利用者向けの fake-IP DNS 例外は 2 種類あり、いずれも DNS の応答にのみ適用されます。URL に書かれたリテラルアドレスは引き続き拒否されます。IANA ベンチマーク範囲 198.18.0.0/15（IPv4-mapped IPv6 表記を含む）は、そのホストにアウトバウンドプロキシが適用される場合に許可されます。Mihomo の既定 IPv6 fake-IP 範囲 fdfe:dcba:9876::/48 はより厳しい条件でのみ許可されます。URL スキームに一致するプロキシ変数（https: は HTTPS_PROXY、http: は HTTP_PROXY）または SOCKS5 の ALL_PROXY が設定されていること（SOCKS 以外の ALL_PROXY は対象外）、ホストが NO_PROXY に一致しないことが必要で、その場合リクエストはそのプロキシに明示的に固定されます。それ以外の ULA、隣接プレフィックス、実際のプライベート応答と混在した fake-IP 応答には引き続き allowPrivateNetwork: true が必要です。プロバイダー保存時の検証には IPv6 例外は適用されません。

Codexアカウントプール

pool アカウントの追加と quota 更新はダッシュボードの Codex Auth ページで処理してください。設定には secret で ないアカウント metadata だけを保存し、access/refresh token は強化された Codex アカウント credential store に別途 保管します。Pool routing は新規/未紐付け割り当て、使用量ベースのプロアクティブ切り替え、障害回復に分かれます。 紐付け済みタスクは通常 affinity を維持します。既定（pool.cacheAffinity）では、紐付け先アカウントが 使い切られるか処理できなくなるまで再紐付けを延期し、離れるときは実際に quota 余裕があり usage が より低いアカウントへだけ移ります。フラグをオフにすると、quota はしきい値超過後の次のリクエストで 再紐付けできます。 pause、cooldown、再認証、障害処理も独立して routing を消去または変更できます。未紐付けリクエストには プロキシ再起動や affinity リセット後の既存タスクも含まれます。出力前の 429/402 は使用量ベースの 切り替えがオフでも同じリクエストで適格な代替アカウントへ 1 回再試行できます。アカウント変更後も会話 コンテキストは保持・再生されますが、アカウント間の provider prompt cache 再利用は保証されません。 一時停止したアカウントと quota metadata は表示されたままですが、自動切り替え、再試行/failover 選択、cooldown 復旧プローブ、手動有効化の対象外です。 一時停止するとそのアカウントの thread affinity map も消去されます。処理中のリクエストは取得済み credential を維持しますが、以降のターンは再ルーティングされ、一時停止中のアカウントは再利用できません。 状態は再起動後も保持され、すべてのアカウントが一時停止中なら Pool ルーティングは別のアカウントを暗黙に選ばず失敗します。 上限到達を一括停止 は credential がある適格アカウントだけを先に更新し、関連する quota window が今回 100% と確認できたアカウントだけを停止します。credential がないアカウントや、quota が不明、または更新に失敗したアカウントは変更しません。 401/403 では、そのアカウントへのプロセスローカルな affinity を解除し、再認証を要求します。 429 では Retry-After を尊重してアカウントの cooldown を開始し、affinity を解除したうえで、 別の適格な Pool アカウントへリクエストを切り替えることがあります。これらの障害回復は autoSwitchThreshold: 0 でも有効であり、0 が無効にするのは使用量に基づく予防的な切り替えだけです。

割り当てとプロアクティブ切り替え戦略： quota（既定）はアクティブアカウントがない場合に最小 usage の適格アカウントを選び、適格なアクティブアカウントが autoSwitchThreshold 未満なら維持します。autoSwitchThreshold 超過後は未紐付けリクエストを移せます。既定では cache affinity が quota 余裕より優先され、紐付け済みタスクはアカウントが使い切られるか（既知 usage 100%）処理できなくなるまで維持され、離れるときは実際に quota 余裕があり usage がより低いアカウントへだけ移ります。usage が不明なアカウントは紐付け済みタスクの移動先にはならず、すべてのアカウントがしきい値を超えていればそのまま残ります。フラグをオフにすると紐付け済みタスクの次のリクエストもしきい値で再紐付けできますが、その場合も実際に quota 余裕があり usage がより低いアカウントへだけ移ります。round-robin は 未紐付けリクエストを均等分散し、しきい値は通常の rotation を変えません。accountPoolStickyLimit （既定 1、1–100）は成功応答ではなく割り当て/紐付け数を数えます。fill-first は未紐付けリクエストを cooldown、再認証、またはそのアカウントの実効 drain threshold（アカウント別上書き、未設定ならグローバル値）までアクティブアカウントへ割り当て、正常な紐付け済みタスクは affinity を維持します。これらの戦略は provider enforcement を回避しません。

anthropicAccountPool (実験的)

このオプトインは、auth.json に既に保存されている複数の Anthropic OAuth アカウントをプールします。デフォルトではオフになっており、実戦テストは行われていません。同じ組織内のアカウントがクォータを共有する場合があり、自動ローテーションによってプロバイダーの制限がトリガーされる場合があります。

キー	タイプ	デフォルト	説明
anthropicAccountPool.enabled?	boolean	false	スティッキー セッション アフィニティと使用量に基づく新規セッション選択を有効にします。429 フェイルオーバーはここでは制御しません: 使用可能なアカウントが 2 つ以上あれば他の複数資格情報プロバイダーと同様に有効になり、無効にはできません。
anthropicAccountPool.autoSwitchThreshold?	number	80	新しいセッションでは、アクティブなアカウントがこのしきい値に達すると、設定した期間で既知のキャッシュ使用量が最も低いアカウントを選択します。 0 はクォータ選択を無効にします。
anthropicAccountPool.strategy?	"quota" | "round-robin" | "fill-first"	"quota"	新しいセッション戦略。quota は quotaWindow で指定した期間（既定は 5 時間足）でアカウントを順位付けし、fill-first も同じ期間で使い切りのしきい値を判定します。
anthropicAccountPool.quotaWindow?	"five-hour" | "weekly" | "max-utilization"	"five-hour"	使用量ベースのアカウント選択で使う、プロバイダー報告のキャッシュ済み使用率です。five-hour は従来の動作を維持します。weekly は週次使用量を使い、他に対象アカウントが残る間だけ 5 時間使用量が上限に達したアカウントを除外し、残らない場合はそれらへフォールバックします。max-utilization は判明している値のうち最も高いものを使うため、週次使用量が未取得でも 5 時間使用量を利用できます。どちらも不明なら unknown の順位付けに従います。既知の使用量は unknown より先ですが、対象がすべて unknown でも対象順の先頭を選択します。記載した 5 時間使用量による同点判定後も完全に同点なら、対象順を維持します。正常な affinity セッションを先回りして再配置することはありません。新規セッションの割り当てと、対象となる 429 代替後のルーティング復旧では、quota はこの期間で対象候補を直接順位付けし、fill-first はこの期間のしきい値と上限到達ルールを使って安定順に進み、round-robin はこの設定を無視します。クールダウン、フェイルオーバー上限、再認証の適格性は別のローカル状態です。アカウント別の週次使用量は、ダッシュボードのプロバイダーページで取得した後にのみ利用できます。
anthropicAccountPool.stickyLimit?	number	1	成功した新しいセッションのバインドは 1 つのラウンドロビン選択で保持されます。範囲は 1 ～ 100。

共有の5時間・週次クォータが拒否された429だけがアカウントのクールダウンと切り替えを行います。一時的な速度制限はアフィニティを維持して送信受付だけを停止し、リクエストごとに短い同一アカウント再試行1回と別の対象アカウントへの切り替え1回までです。根拠ヘッダーのない429は同一アカウントで1回だけ再試行し、アカウントを冷却せず、Retry-Afterも生成しません。既定の単一アカウント動作は変わりません。Fable専用の拒否はSonnetを制限しません。手動選択とアフィニティもリクエストモデルの共有・ファミリークォータを確認します。パッシブなファミリー情報は30分または既知のリセットで期限切れとなり、1つの送信リクエストで再確認します。使用量しきい値はソフトな優先設定で、全候補消耗時のフォールバックを維持します。使用量・課金のハード上限ではありません。アフィニティはプロセスローカルであり、サイズ制限があります。トークン更新の失敗は既存の再認証ルールに従います。確認済みの契約・アカウント請求の 403 は出力前に別アカウントへ切り替え、Retry-After または既定の10分間のクールダウンを記録します。一般的な権限拒否では切り替えません。すべての対象となるアカウントが冷却されている場合、クライアントは、既知の場合、認証エラーではなく、Retry-After を含む 429 を受け取ります。

リクエストが使えるすべてのアカウントが使い切ったクォータ（共有の5時間・週間ウィンドウ、または要求モデルのファミリー週間ウィンドウ）で保留されている場合、その 429 はレート制限ではなく使用量上限です。Responses の本文は error.type と error.code に usage_limit_reached を持ち、保留中の全アカウントの上流リセット時刻が分かる場合は resets_at（最も早いリセットのエポック秒）を含みます。Codex は「exceeded retry limit」まで再試行せず、いつ再試行できるかを表示して停止します。最後のアカウントがクォータ切れで拒否し、代替が残っていない場合も同じ応答になります。保留中のアカウントのいずれかが一時的なスロットリング、モデルファミリーの再検証中、または権限による拒否である場合は、再試行可能な rate_limit_exceeded のままです。Combo ターゲットは次のターゲットへ進めるようレート制限の形を保ちます。ネイティブ /v1/messages は Anthropic の rate_limit_error 型を保ち、メッセージで使用量上限を示します。

新しい使用量の読み取り（ダッシュボードのプロバイダーページ、または ocx account list anthropic --quota --refresh）で、拒否された各ウィンドウが 100% 未満と分かれば、クォータのクールダウンは Retry-After 由来でもウィンドウのリセット由来でも早期に解除されます。プランのアップグレードや早期のウィンドウ再開がこれに当たります。拒否より前の読み取りでは解除されず、権限による 403 のクールダウンは期限まで待ちます。

実験的

Anthropic アカウント ポリシーのリスクを理解していない限り、これは無効のままにしてください。不明な場合は、ocx account use anthropic <id> を手動で切り替えることをお勧めします。

Anthropic · Pool 2 (anthropic2)

anthropic2（「Anthropic · Pool 2」）は、独自のアカウントプールを持つ 2 つ目の組み込み Anthropic OAuth プロバイダーです。anthropic と同じ Anthropic 実装（同じログインフロー、ワイヤ形式、ネイティブ Messages と Responses ブリッジ、モデルメタデータ）で動作し、分かれているのはアカウントとそれを囲むプールだけです。プールはモデルの接頭辞で選びます。anthropic/claude-sonnet-5 はプライマリプール、anthropic2/claude-sonnet-5 は Pool 2 を使います。

Pool 2 は追加するまで休止状態です。ocx login anthropic2 でログインするか、ダッシュボードのプロバイダーページで Anthropic · プール2 を追加します。最初のログインが成功すると、マーカー "anthropicOAuthInstance": "anthropic2" 付きの providers.anthropic2 が作成されます。Pool 2 が既定のプロバイダーになることはありません。接頭辞のない claude-* モデル名、既定モデル、Claude Code の呼び出し元転送は引き続き anthropic に解決されます。以前に自分で作成したマーカーのない anthropic2 エントリは独自の意味を保ちます。ログインは名前の衝突を拒否し、エントリも資格情報も書き換えません。

Pool 2 はプール設定を自身のプロバイダーエントリから読み取ります。キー、既定値、動作は上記のトップレベル anthropicAccountPool と同じで、プライマリプールからは何も継承しません。providers.anthropic.anthropicAccountPool や、他のプロバイダー上の同じフィールドは拒否されます。

{
  "anthropicAccountPool": { "enabled": true, "strategy": "quota" },
  "providers": {
    "anthropic2": {
      "adapter": "anthropic",
      "authMode": "oauth",
      "baseUrl": "https://api.anthropic.com",
      "anthropicOAuthInstance": "anthropic2",
      "anthropicAccountPool": { "enabled": true, "strategy": "round-robin" }
    }
  }
}

2 つのプールは opencodex 内で分離されています。

• 資格情報: Pool 2 のアカウントは、保護された資格情報ストアの独自キー anthropic2 に保存されます。トークンまたは検証済み Anthropic アカウントがもう一方のプールに既に保存されているログインは拒否されます。
• プール設定と実行時状態: 選択、セッションアフィニティ、クールダウン、一時停止、モデルルート、アカウント別しきい値は 1 つのプールに属します。ルートの fallback: true は同じプール内でのみ範囲を広げます。
• クォータと使用量: 使用量プローブ、クォータキャッシュ、使用量の帰属はプールごとに記録されるため、両方のプールに同じアカウント ID があっても記録は別々です。
• リセット付与: Pool 2 は、変更されないプライマリプールのジャーナルの隣に独自のジャーナル（anthropic2-reset-grant-ledger.json）を持ちます。
• 復旧: anthropic2/<model> への直接リクエストがプライマリプールにフォールバックすることはなく、Pool 2 のレート制限や拒否がプライマリプールのアカウントをクールダウンさせることもありません。両方のプールを指定した明示的なコンボは、宣言したターゲットを維持します。

この分離は opencodex 内のルーティング境界です。Anthropic によるアカウントの扱いや、上記のアカウントポリシーのリスクは変わりません。

Pool 2 のアカウントはブラウザー OAuth でのみ追加できます。anthropic と異なり、Pool 2 は Claude Code CLI のトークンをインポート、採用、書き戻しすることはありません。この違いは意図的です。Pool 2 は空の状態で始まり、使用可能な Pool 2 アカウントがない Pool 2 リクエストは、プライマリプールや Claude Code の資格情報を借りずに認証エラーで失敗します。

アカウントコマンドと管理 API はプールを名前で指定します: ocx account pool anthropic2 …、ocx account auto-switch anthropic2 …、ocx account routes anthropic2 …、ocx account anthropic-reset-grants --provider anthropic2。プール設定とリセット付与のエンドポイントは provider: "anthropic2" を受け付け、省略するとプライマリプールのままです。

ヘルパーのプール選択 (anthropicInstance)

Web 検索とビジョンのヘルパーは、グローバルの webSearchSidecar と visionSidecar、および Claude Code オーバーライドの claudeCode.webSearchSidecar と claudeCode.visionSidecar で、任意の anthropicInstance を受け付けます。ヘルパーのバックエンドが Anthropic のとき、ダッシュボードに アカウントプール の選択肢として表示されます。

値	動作
未設定（既定）	現在のリクエストのプールに従います。anthropic2/<model> リクエストは Pool 2、anthropic/<model> リクエストはプライマリプールを使います。他のプロバイダーからのリクエストは既存のヘルパー検出を使い、Pool 2 を選ぶことはありません。
"anthropic"	常にプライマリプールを使います。
"anthropic2"	常に Pool 2 を使います。

このフィールドは、ヘルパーのバックエンドが Anthropic に解決される場合にのみ適用されます。他のバックエンドと組み合わせると検証エラーになります。Web 検索の既定は OpenAI なので、"backend": "anthropic" も設定してください。anthropic/claude-sonnet-5 と "anthropicInstance": "anthropic2" のように、もう一方のプールで修飾されたヘルパーモデルも拒否されます。選んだプールに使用可能なアカウントがない場合、ヘルパーは何も送信せずに失敗し、もう一方のプールには切り替えません。その場合も本来のリクエストは、そのヘルパーなしでそのまま処理されます。未設定の選択は "anthropic" ではなく、値なしとして保存されます。

{
  "webSearchSidecar": { "backend": "anthropic", "anthropicInstance": "anthropic2" }
}

ダウングレード

Pool 2 のないバージョンは anthropic2 エントリを理解しません。古いバージョンをインストールする前に、プロキシを停止し、config.json と auth.json をバックアップしてから、config.json から providers.anthropic2 を削除してください。Pool 2 がプライマリプールの資格情報を移動したり書き換えたりすることはありません。Pool 2 が有効なままのインプレースダウングレードはサポートされていません。

管理されたレコードの形状

apiKeys[] エントリには、id、name、生成された key、および ISO createdAt 文字列が含まれます。 codexAccounts[] エントリには id、email、および isMain が必要で、オプションの plan、chatgptAccountId、およびプライバシー セーフな logLabel が必要です。これらのレコードは通常、ダッシュボードで管理されます。

tokenGuardian (OcxTokenGuardianConfig)

フィールド	タイプ	デフォルト	意味
enabled?	boolean	false	グローバル プロアクティブ リフレッシュ スイッチ。
tickSeconds?	number	21600	スイープ間隔 (6 時間、最小 60 秒)。
jitterSeconds?	number	300	スイープ前のランダムな遅延。
concurrency?	number	3	最大同時リフレッシュ数。
leadSeconds?	number	900	1 ティックを超える余分なリフレッシュ リード タイム。
failureBackoffBaseSeconds?	number	300	初期の過渡障害バックオフ。
failureBackoffMaxSeconds?	number	3600	バックオフの上限と永続的な障害による遅延。
codexWarmupEnabled?	boolean	false	合成 Codex プールアカウント検証をオプトインします。
codexWarmupMaxAgeSeconds?	number	691200	8 日後にアカウントを再認証します。
codexWarmupModel?	string	gpt-5.6-luna	オプションのウォームアップに使用されるネイティブ モデル。

固定プロバイダーエンドポイント

ルーティングは、アダプターの前にプロバイダー エンドポイントを解決します。ほとんどの組み込みでは、レジストリ エンドポイントが構成された baseUrl よりも優先されます。 4 つのエントリ タイプでは、構成された URL が保持されます。

• オーバーライドが有効なプロバイダー: ollama、vllm、lm-studio、litellm、qwen-cloud、および alibaba-token-plan-intl;
• azure-openai や cloudflare-ai-gateway など、ユーザーが入力したレジストリ テンプレート。
• 古い同じ名前のカスタム宛先を保持する固定 API キー プリセットを昇格しました。そして
• プロバイダーがレジストリに存在しません。

アダプターは、解決された URL を後で調整できます。たとえば、Kiro は、インポートされた資格情報の正規 runtime.{region}.kiro.dev の API リージョンに従います。 アダプターを参照してください。

ルーティングで baseUrl が破棄されると、opencodex はレジストリ エンドポイントと構成された起点のみをログに記録します。構成されたパス自体に資格情報が含まれる場合があります。未使用の URL を削除するか、目的のリージョンに一致するプロバイダー エントリを選択します。 alibaba-token-plan は北京に固定されていますが、alibaba-token-plan-intl は国際エンドポイントをカバーしています。

壊れた openai-responses ゲートウェイの場合、修復はプロバイダー オブジェクトに属します。

{
  "providers": {
    "custom-gateway": {
      "adapter": "openai-responses",
      "baseUrl": "https://gateway.example/v1",
      "apiKey": "${GATEWAY_KEY}",
      "responsesItemIdRepair": {
        "reasoning": ["rs_0"],
        "message": ["msg_0"],
        "repairMissingTerminalIds": true
      }
    }
  }
}

プレースホルダー リストは完全に一致します。通常/ステートフル応答プロバイダーのフィールドを未設定のままにして、パススルーがバイトごとに同一になるようにします。

Cursor プロバイダー (adapter: "cursor")

カーソルブリッジは実験的なものです。 ocx login cursor の後に、providers.cursor を追加または編集します。ピッカーはカーソル固有のモデル パラメーターをレンダリングできないため、カーソル ルーターの最適化ラダーは別の Codex ID として公開されます。

Codexモデル	カーソル ルーターモード
cursor/auto	チーム/アカウントのデフォルト
cursor/auto-cost	コスト
cursor/auto-balance	バランス
cursor/auto-intelligence	インテリジェンス

明示的なバリアントは、Cursor の default モデルを optimization パラメータとともに送信し、リクエストごとに選択を保持します。ライブディスカバリーで default を省略しても、これらは引き続き使用できます。

カーソル サーバー駆動のローカル ツールは、デフォルトでは無効になっています。 Codex は、独自の承認とサンドボックス ポリシーを備えた apply_patch や exec_command などの独自のツールを引き続き使用します。

• "off" (デフォルト) は、カーソルネイティブの read、write、delete、ls、grep、shell、および fetch実行。
• "on" は、信頼できるローカルでの実行を選択し、Codex 承認/サンドボックス セマンティクスをバイパスします。
• "codex-sandbox" は互換性のために残されていますが、"off" と同様にフェールクローズされます。散文のリクエストは 信頼できるサンドボックス証明書ではありません。

{
  "providers": {
    "cursor": {
      "adapter": "cursor",
      "baseUrl": "https://api2.cursor.sh",
      "authMode": "oauth",
      "defaultModel": "auto",
      "nativeLocalExec": "off"
    }
  }
}

最上位ではなく、providers.cursor にフィールドを設定します。ダッシュボードで プロバイダー > カーソル > JSON の編集 を使用し、保存して再起動します。従来の unsafeAllowNativeLocalExec: true は、nativeLocalExec が設定されていない場合にのみ nativeLocalExec: "on" と等しくなります。 MCP、画面録画、およびコンピューターの使用は、mcpServers および desktopExecutor によって個別に制御されます。

各 mcpServers.<name> は、command (stdio) または url (ストリーミング可能な HTTP) のいずれかを受け入れます。 Stdio は args、env、および cwd も受け入れます。 HTTP は headers を受け入れます。どちらも enabled (デフォルトは true) と toolPrefix をサポートします。 desktopExecutor は、computerUseCommand、recordScreenCommand、cwd、env、および timeoutMs (デフォルトは 30000) を受け入れます。コマンドは sh -c を通じて実行され、stdin から 1 つの JSON リクエストを読み取り、1 つの JSON 結果を stdout に書き込む必要があります。

安全

デフォルトのループバック バインドでは、マルチユーザー ホスト上の他のユーザーを含む、認証なしのローカル プロセスを許可します。すべてのデータプレーン呼び出し元が信頼されており、Codex 承認とサンドボックス セマンティクスのバイパスを意図的に受け入れる場合を除き、ローカル exec はオフのままにしておきます。

xAI の Grok 4.7

Grok 4.7 は OAuth で Fast を利用でき、low / medium / high / xhigh と 500,000 トークンのコンテキストを提供します。xAI の標準料金は 100 万トークンあたり入力 2.00 ドル、キャッシュ入力 0.50 ドル、出力 6.00 ドルです。コンテキストが 200,000 トークン以上の場合は 4.00 / 1.00 / 12.00 ドルになります。

プロバイダーの fastWire を明示的に設定していない場合、allowedModels で制限した opencodex API キーの OAuth Fast リクエストには、xai/grok-4.7-build-fast（またはプロバイダー名を除いたモデル ID）の許可が必要です。xai/grok-4.7 だけの許可では、この Fast モデルを利用できません。Fast モデルだけを許可したキーでも利用できますが、通常のリクエストや Fast が無効な場合には xai/grok-4.7 の許可が必要です。fastWire を明示的に設定した場合は、実際に送信されるモデルを許可してください。例えば、service-tier 方式では xai/grok-4.7 が維持され、そのモデルの許可が必要です。プロバイダーの制限も引き続き適用されます。

OpenRouter プロバイダーのルーティング

OpenRouter は、複数の推論プロバイダーを通じて 1 つのモデルを提供できます。 openRouterRouting は優先プロバイダーでリクエストを保持します。 modelOpenRouterRouting は、正確なモデル ID に置き換えられます。キャッシュのサポート、保持、ヒット率、価格は推論プロバイダーによって異なるため、これはプロンプト キャッシュ アフィニティに役立ちます。

プロバイダー名は OpenRouter スラッグです。 allowFallbacks: false はフェールクローズされます。 true では、順序付きリストの後に別の適格なプロバイダーを許可します。 only は常に許可リストです。

{
  "providers": {
    "openrouter": {
      "adapter": "openai-chat",
      "baseUrl": "https://openrouter.ai/api/v1",
      "apiKey": "${OPENROUTER_API_KEY}",
      "openRouterRouting": {
        "order": ["deepseek"],
        "allowFallbacks": false
      },
      "modelOpenRouterRouting": {
        "anthropic/claude-sonnet-5": {
          "only": ["anthropic"],
          "allowFallbacks": false
        }
      }
    }
  }
}

モデル キーは、外部の opencodex プロバイダー プレフィックスを除いた、正確なネイティブ OpenRouter ID です。 openrouter/anthropic-claude-sonnet-5 を選択すると、モデル ルールを適用する前のネイティブ anthropic/claude-sonnet-5 が復元されます。

Vercel AI Gateway プロバイダーのルーティング

Vercel AI Gateway は、1 つのモデルを複数の基盤となる推論プロバイダーへルーティングできます。vercelGatewayRouting はプロバイダー全体の設定を構成し、modelVercelGatewayRouting は正確なモデル ID ごとにそれを置き換えます。両方とも未設定の場合、resolveVercelGatewayRouting() は undefined を返すため、Chat リクエスト ビルダーは provider フィールドを省略し、Vercel AI Gateway のデフォルトの動的ルーティング動作が維持されます。

• order: 優先順位順の Vercel AI Gateway アップストリーム プロバイダー スラッグ。
• only: 対象となる Vercel AI Gateway アップストリーム プロバイダーを制限する明示的な許可リスト。
• sort: 対象となるプロバイダーを "cost" (最安コスト)、"ttft" (最初のトークンまでの時間)、または "tps" (1 秒あたりのトークン数) で自動的に並べ替えます。

{
  "providers": {
    "vercel-ai-gateway": {
      "adapter": "openai-chat",
      "baseUrl": "https://ai-gateway.vercel.sh/v1",
      "apiKey": "${VERCEL_AI_GATEWAY_KEY}",
      "vercelGatewayRouting": {
        "sort": "ttft"
      },
      "modelVercelGatewayRouting": {
        "zai/glm-5.2": {
          "only": ["novita", "deepinfra"],
          "order": ["novita", "deepinfra"]
        }
      }
    }
  }
}

モデル キーは、外側の opencodex プロバイダー プレフィックスを除いた Vercel の公開モデル セレクターです。vercel-ai-gateway/zai-glm-5.2 を選択すると、モデル ルールを適用する前にネイティブの zai/glm-5.2 が復元されます。ネイティブの vercel/<model-id> セレクターにも同じマッピングが適用されます。opencodex ではエンコードされた vercel-ai-gateway/vercel-<model-id> セレクターを使用し、モデル キーには vercel/<model-id> を指定してください。

静的モデルのホワイトリスト

liveModels: false で models が空または省略されている場合、初期一覧には設定済みの defaultModel、retainModels の順で ID を追加し、重複は最初の出現だけを残します。 空でない models が明示されている場合は、models、retainModels の順になり、別の defaultModel を暗黙に追加しません。そのモデルも models または retainModels に明示すれば 含められます。どのフィールドにも ID がなければ初期一覧は空です。この順序は最終的なピッカーの 表示順を保証しません。selectedModels、disabledModels、プロバイダーの無効化は引き続き適用されます。 authMode: "forward" は別の分岐を維持し、このルーティング用の静的一覧を使いません。 これらの規則はライブ検出失敗時のフォールバックを変更しません。

ライブ ディスカバリは、キャッシュする前に 4 MiB または 2,000 を超える生のモデル行を拒否します。組み込みのプリセットは下限を使用し、チャットに適した行にフィルターをかけることができます。サイズが大きすぎる、または形式が正しくない結果は、古い/構成されたフォールバックに続きます。ゼロに適格な有効な結果は引き続き権威を持ち、暗黙的に置き換えられたり切り捨てられたりすることはありません。

検出を実行する必要があるが、選択した ID のみが Codex および /v1/models に表示される必要がある場合は、selectedModels を使用します。ダッシュボードには、後で許可リストを変更できるように、検出された完全なリストが保持されます。

表示名には modelDisplayNames を使用します。優先順位は、運用者が設定した modelDisplayNames、プロバイダーカタログのメタデータ、通常の provider/model 表示の順です。キーはこのプロバイダー内の正確なネイティブモデル ID です。例えば xai/grok-4.6 のキーは grok-4.6 です。ラベルは表示専用で、正確なルーティング ID や上流モデル ID を変更しません。config.json の既存プロバイダー設定にこのフィールドだけを追加し、他のすべてのフィールドを残してください。PUT /api/providers/:provider/model-display-names に { "modelId": "grok-4.6", "displayName": "Grok 4.6" } を送ると保存され、displayName: null を送るとその名前だけがリセットされます。

ローカル Codex カタログでサポートされるプレフィックスなしのネイティブ GPT 行にも、 providers.openai.modelDisplayNames で正確な表示名を指定できます。例えば "gpt-6-astra": "GPT 6 Astra" です。 起動時の同期とローカルカタログの収束処理は、どちらもこれらの名前を再適用します。名前の設定を削除すると、行の現在の表示名が 適用済みの上書きとまだ一致する場合にのみ、元のネイティブ名が復元されます。外部で変更された表示名にも既存のネイティブメタデータ正規化が適用されます。 例えば Astra (gpt-6-astra) では、固定されたネイティブ名と異なる名前は引き続きその固定名に置き換えられます。 表示名の上書きによってモデル ID、メタデータ（機能を含む）、順序、ルーティングされたコンボのエイリアス、アカウント修飾付きの行は変更されません。 このローカルカタログの上書きは、HTTP のモデル一覧や仮想 *-pro 行の表示名には適用されません。

プレビュー GPT-5.6 フォールバック エントリは同じメカニズムを使用します。 OpenAI API キー プリセットは、ベース ID と Pro ID にコンテキスト 1050000 と最大入力 922000 をシードします。 OpenRouter は、コンテキスト 1050000 を持つ openai/gpt-5.6-sol、openai/gpt-5.6-terra、および openai/gpt-5.6-luna をシードします。ネイティブのプール/ダイレクトのウィンドウは予約 OpenAI プロバイダーのポリシーに従います。同期されたカタログは、xhigh を区別しつつ、max をアドバタイズします。

{
  "providers": {
    "openrouter": {
      "adapter": "openai-chat",
      "baseUrl": "https://openrouter.ai/api/v1",
      "apiKey": "${OPENROUTER_API_KEY}",
      "liveModels": false,
      "models": ["deepseek/deepseek-v4-flash", "qwen/qwen3-coder-plus"]
    }
  }
}

モデルの表示名エディター

ダッシュボードの Models では、検出されたモデルに読みやすい名前を付けて永続的に保存できます。プロバイダーを展開し、検出された モデルを見つけて Name を選択します。読みやすい名前を保存する間も、ダイアログには正確な provider/model セレクターが表示されます。Reset name を選ぶと、プロバイダーのメタデータ、 または通常のセレクター表示に戻ります。Name が変更するのは表示だけです。別のエイリアス用 鉛筆アイコンは短いルーティングエイリアスを変更するもので、表示名エディターではありません。 ネイティブ OpenAI とカスタムモデルの行では、既存の操作方法が維持されます。

変更は保存されたものの更新に失敗した場合、ダイアログは保存済みの上書き設定を反映し、Retry を 引き続き利用できます。サーバーがカタログの収束処理の失敗を報告した場合、Retry はその処理を再実行し、 一覧取得のリクエストだけが失敗した場合は一覧を再読み込みします。リセット後の復旧でもリセット操作を 維持し、以前の名前には戻しません。リクエストには、書き込みとその後の一覧更新を合わせて 60 秒の 期限があります。タイムアウトしても書き込みは取り消されません。次の変更を行う前に Retry で 現在の名前を確認してください。

完全な例

{
  "port": 10100,
  "defaultProvider": "openai",
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward"
    },
    "anthropic": {
      "adapter": "anthropic",
      "baseUrl": "https://api.anthropic.com",
      "authMode": "oauth",
      "defaultModel": "claude-sonnet-4-6"
    },
    "ollama-cloud": {
      "baseUrl": "https://ollama.com/v1",
      "apiKey": "${OLLAMA_API_KEY}",
      "defaultModel": "glm-5.2",
      "noVisionModels": ["glm-5.2", "gpt-oss", "qwen3-coder", "deepseek-v4-flash"]
    }
  },
  "subagentModels": ["anthropic/claude-opus-5", "ollama-cloud/glm-5.2"],
  "disabledModels": [],
  "websockets": false,
  "webSearchSidecar": {
    "maxSearchesPerTurn": 3,
    "routedModelStallTimeoutMs": 200000,
    "timeoutMs": 60000
  },
  "visionSidecar": { "enabled": true }
}

anthropicAccountPool.routes

anthropicAccountPool.routes は Anthropic OAuth の保存済みアカウント ID をモデルに割り当てます。有効なプールでは、大文字小文字を区別する match グロブの最初の一致が初回選択と 429 再試行を制限します。fallback: true はルート内に適格なアカウントがない場合だけ通常のプールを使います。

promptLengthPricing

省略可能な promptLengthPricing は4つの基本料金に追加します。mode: "automatic"（または省略）はカタログのコンテキスト料金規則を維持し、mode: "flat" はその規則を無効にします。mode: "custom" では、thresholdTokens に正の安全な整数、comparison に "gt"（>）または "gte"（≥）、rates に4つの絶対額の代替料金を指定します。判定にはキャッシュの読み書きを含む全プロンプトトークンを使い、出力は含めません。選択された料金は出力を含むリクエスト全体に適用され、しきい値の上下どちらでもカタログの規則を置き換えます。Fast/Priority 調整は料金の選択後に1回だけ適用され、そのモデルについてカタログが公開している Priority との関係に従います。推定値が下限として表示されるのは、カタログがその関係を lower-bound と宣言している場合（現在は xAI Grok）だけです。カタログに規則がないモデルでは、Priority 倍率は1回だけ適用されます。Models → Price で設定できます。Reset to automatic は基本料金と規則を含む上書き全体を削除します。既存設定との互換性は維持され、表示される推定料金だけに関する設定です。