最終更新

Codex にカスタムモデルを追加 — user-models.json と汎用プロバイダー

Codex のカスタムモデルとは、独自のエンドポイントを Codex Router の custom プロバイダーと汎用プロバイダー経由で Codex ピッカーに追加することを意味します。他のすべてのプロバイダーは 1 つのアドレスを持ちますが、custom は持ちません——各モデルが独自のエンドポイント、独自の認証、独自のメタデータを指定します。

custom プロバイダーとは

1 つの custom プロバイダーが、無料のコミュニティエンドポイント、友人のセルフホストサーバー、有料 API キーを同時に保持できます。キーが必要なモデルはその行でその旨を明示します。プロバイダーが自動で選択されたり、デフォルトセットに含まれたりすることはありません。保持する内容は誰かが入れたものだからです。

有効化します——費用も要求もありません:

./bin/model-router codex providers enable custom

Windows では同じコマンドで ./model-router.ps1 codex を使います。

認証情報なしの許可リスト境界

認証情報なしで到達するエンドポイントは、レジストリ断片が単独で導入できない唯一のものです。そのアドレスは、匿名プロバイダーとまったく同様に src/model-registry.mjs の許可リストに登録する必要があります。そうしないと、config/custom/ 配下に JSON ファイルを追加するだけで、認証するものがないままインターネット上の任意のホストにプロンプトを送信できてしまいます。

キーを持つエンドポイント、またはループバックに留まるエンドポイントには許可リスト登録は不要です——キーまたはアドレスがすでに境界だからです。これが「便利」と「安全でない」の意図的な線引きです。

Control Center から Models → Custom → Add endpoint を選び、名前、ベース URL、Chat Completions または Responses、キーを入力できます。保存時に GET /models を確認し、専用チップから一覧のモデルや By name で非公開 ID を追加、エンドポイントの編集、モデルの削除、キーとモデルを含むエンドポイントの削除ができます。

各 user-models.json のモデルは個別に endpoint.protocol を指定できます。openai は Chat Completions(既定)、anthropic は Messages、openai-responses は Responses です。プロトコルと認証情報は共有の custom コンテナではなく各モデルのエンドポイントに属します。supportedEndpoints を書く場合、選んだ OpenAI プロトコルに対応する /chat/completions または /responses を含めます。Messages モデルは OpenAI の supportedEndpoints を宣言しません。

明示的に設定したエンドポイントは、内蔵プリセットと同じ上流モデル ID を使っていても独自の接続先を保持し、そのプリセットの公開クラウド接続先へ黙って切り替わることはありません。

モデルごとの任意フラグ goalContinuationGuard は、ツール操作がなく、短くほぼ同じ完了済みゴール応答が 3 回続くと、自動ゴール継続をローカルで停止します。既定ではオフで、新しい指示、ツール操作、目標の変更で判定はリセットされます。

もう一つのモデルごとの任意設定 repetitionGuard: true は、GLM-5.3 の継続的な文章の繰り返しを、プロバイダーへの再送なしで止めます。JSON の例、コード、ツール、推論は判定から除外され、既定ではオフです。

モデルごとの reasoningTagPolicy で、表示される回答内の推論タグに似た文字列の処理を指定できます。未知のルートは既定で preserve となり、XML の例や引用された <think> タグをそのまま残します。legacy-inline はそのルートでインライン推論タグの漏出を確認した場合にのみ使い、hy4-nonce は検証済み Hy4 Preview ルートに限られます。既知の Qwen Plan Flash と Hy4 Preview にはそれぞれの互換処理が残り、明示した preserve は既定の処理より優先されます。

汎用プロバイダー

汎用プロバイダーを使うと、レジストリエントリを待たずに OpenAI 互換サービスをプロバイダーとして登録できます。たとえば Perplexity 検索サイドカー:

./bin/model-router codex providers generic add perplexity-search \
  --name "Perplexity Search" \
  --base-url https://api.perplexity.ai \
  --adapter openai-chat
./bin/model-router codex providers generic credential perplexity-search set

汎用 Responses プロバイダーは --adapter openai-responses --transport websocket で上流 WebSocket の接続プールを選べます。ネイティブ通信は MODEL_ROUTER_NATIVE_TRANSPORT=websocket を設定しない限り HTTP のままです。送信前の失敗は HTTP にフォールバックできますが、処理中で結果が不明なターンは再送しません。

credential コマンドはキーを引数として受け付けません。プロンプトで入力を求めます。ディスクリプター、認証情報参照、モデル単位のバインディングはすべてプライベートでアトミックな状態です。

チャットモデルとツール API

Models ピッカーが追加するのは会話モデルで、選択すると Codex のアシスタントが変わります。ツール API には別のクライアントが必要です。たとえば OpenRouter に接続すると、ローカルの /v1/decisions エンドポイントから非表示ルート openrouter-decisions/jev-latest を利用できますが、呼び出す Decisions クライアントを別途設定する必要があります。OpenRouter のチャットモデル typesafe/jev-router をピッカーに追加しても、非表示ルートは有効にならず、Codex のツール出力削減フックもインストールされません。設定後に Router がオフラインになった場合は Control Center の Status → Service health → Fix を使用し、健全性を確認して既知の正常なチャットモデルに戻してください。Fix はインストール済み Router を修復・再起動するため、ルーティング済みチャットを中断する可能性がありますが、Decisions クライアントは有効にしません。

検索サイドカー

検証済みの検索を持たないルーティング済みモデルのために、Codex は明示的な検索サイドカーを使用できます。バインディングは 1 つの正確なルーティング済みモデルと 1 つのプロバイダーを指定し、すでに検索機能を持つモデルには拒否されます:

./bin/model-router codex search-sidecar set PROVIDER/MODEL perplexity-search
./bin/model-router codex search-sidecar status PROVIDER/MODEL

バインディングを変更した後は Codex を完全終了して再起動し、モデルカタログを更新してください。汎用プロバイダーを削除すると、その認証情報と依存するすべてのサイドカーバインディングも削除されます。

キュレーションと検証のコマンド

ディスカバリー、キュレーション、検証は同じ保護されたユーザーモデル状態を基盤とします:

コマンド目的
./bin/discover-models <provider>プロバイダーのライブカタログが公開するものを一覧表示
./bin/curate-models <provider>公開するモデルとメタデータを選択
./bin/test-model 'PROVIDER/MODEL' --live --yesリアルタイム(クォータ消費)チェック
./bin/refresh-catalogCodex が読み取るマージ済みカタログを再構築

ライブテストでストリーミングが互換と判定されるのは、フレーム化されたアシスタント出力に期待したマーカーがあり、応答が正常終了を報告した場合だけです。入力のエコー、引用された完了語、推論だけのテキスト、失敗を示す終端イベントでは合格しません。

キュレーション済みエントリは user-models.json に保存され、更新を経ても残り、その場で編集でき、キュレーションを再実行して選択を外すと削除できます。

対話型キュレーションでは、プロバイダーのカタログが画像入力を示していても、明示的な「画像なし」の選択を尊重します。モデルの発見時には、大きい能力値ではなく、公開されたサービス上のコンテキスト上限の最小値を使います。カタログ発見と残量の読み取りには設定済みの API キープールを使用し、プールが使えないときに別の旧アカウントへ黙って切り替えることはありません。

無料カスタムモデルの例

レジストリには無料カスタムの例が 1 つ同梱されています:共有 Hugging Face Inference Endpoint 上の Qwen3.8-27-free-victor です。262,144 トークンのコンテキスト、画像入力、ツール呼び出し、IP あたり毎分約 30 リクエストを提供します。所有者はローンチへの関心が薄れれば廃止すると述べているため、依存先ではなく試すモデルとして扱ってください。

このエンドポイントは認証情報を持ちません。これらの無料ルートは自己責任で使用してください:誰もあなたへのサービス提供に同意しておらず、アクセスは権利ではなく公開された例外であり、予告なく狭められたり、レート制限されたり、撤回されたりする可能性があります。

FAQ

Codex Router の custom プロバイダーとは何ですか? custom プロバイダーは固定アドレスを持ちません。各モデルが独自のエンドポイント、認証、メタデータを指定するため、1 つのプロバイダーが無料のコミュニティエンドポイント、セルフホストサーバー、有料 API キーを同時に保持できます。

一部のカスタムエンドポイントに許可リストが必要なのはなぜですか? 認証情報なしで到達するエンドポイントは src/model-registry.mjs の許可リストに登録する必要があります。そうしないと、JSON ファイルを追加するだけで、認証するものがないまま任意のホストにプロンプトを送信できてしまいます。キーを持つエンドポイントやループバックのエンドポイントには許可リスト登録は不要です。

カスタムモデルを検証するにはどうしますか? ./bin/test-model ‘PROVIDER/MODEL’ —live —yes でリアルタイム(クォータ消費)チェックを行い、その後 Codex を完全終了して再起動しカタログを更新します。

関連:モデル概要、インストール、仕組み、ピッカーのトラブルシューティング。