Codex の新モデルが表示されないとき：公式 Model Catalog と Sub2API を同期する
Codex に新しいモデルが追加されたとき、私は最初からクライアント設定を書き換えないようにしています。
まず公式のモデル catalog に本当にその slug があるかを確認し、その後でローカル catalog、クライアントの最低バージョン、最後に Sub2API のルーティングを確認します。
この順番にすると、「モデルが選択肢に出ない」「選べるが Sub2API が拒否する」「上流で別モデルに変わる」という三つの問題を混ぜずに済みます。
私が今固定している流れは次です。
OpenAI 公式 models.json
↓
実際のモデル slug を確認
↓
ローカル codex-models.json へ同期
↓
minimal_client_version を確認
↓
Codex / Desktop を再起動
↓
Sub2API の許可リストとモデルマッピング
↓
Responses API で元のモデル名を透過
↓
要求モデル / 上流モデルを比較現在の公式 catalog にある gpt-6.1-sol を例にすると、条目には次の情報があります。
slug: gpt-6.1-sol
display_name: GPT-6.1-Sol
minimal_client_version: 0.153.0
supported_in_api: trueつまり最初にやるべきなのは、自分でそれらしいモデル名を作ることではなく、公式 catalog を確認することです。
slug だけ手書きせず、公式の完全な条目を同期する
私の ~/.codex/config.toml ではローカルモデル catalog を指定しています。
model_catalog_json = "~/.codex/codex-models.json"新モデルを同期するときは、まずバックアップします。
cp ~/.codex/codex-models.json \
~/.codex/codex-models.json.bak.$(date +%Y%m%d-%H%M%S)次に公式 catalog を取得します。
curl -fsSL \
https://raw.githubusercontent.com/openai/codex/main/codex-rs/models-manager/models.json \
-o /tmp/codex-models-official.json対象モデルを指定します。
MODEL="gpt-6.1-sol"まず公式データに存在するか確認します。
jq --arg MODEL "$MODEL" '
.models[]
| select(.slug == $MODEL)
| {slug, display_name, minimal_client_version, supported_in_api}
' /tmp/codex-models-official.json見つかったら、簡略化した条目を手書きするのではなく、公式オブジェクト全体をローカル catalog にマージします。
jq --arg MODEL "$MODEL" \
--slurpfile official /tmp/codex-models-official.json '
.models = (
[.models[] | select(.slug != $MODEL)]
+
[$official[0].models[] | select(.slug == $MODEL)]
)
' ~/.codex/codex-models.json > ~/.codex/codex-models.json.new
jq empty ~/.codex/codex-models.json.new &&
mv ~/.codex/codex-models.json.new ~/.codex/codex-models.jsonこうしておけば slug だけでなく、display name、reasoning level、コンテキスト制限、ツール能力、バージョン条件なども公式と揃います。
更新後は Codex / ChatGPT Desktop を完全に終了してから開き直します。macOS なら私は ⌘ + Q でプロセスごと終了させます。
catalog にあるのに表示されない場合
まずローカル条目を確認します。
jq --arg MODEL "$MODEL" '
.models[]
| select(.slug == $MODEL)
| {slug, display_name, minimal_client_version}
' ~/.codex/codex-models.json条目が存在するなら、次に見るのは現在のクライアントバージョンと minimal_client_version です。
gpt-6.1-sol の現在の公式値は 0.153.0 です。このフィールドはクライアント側の互換性ゲートとして扱うのが自然です。
私の確認順序は次です。
Codex を更新
↓
クライアントを再起動
↓
モデルが表示されるか確認
↓
まだ必要なら最低バージョンを診断純粋に「バージョン条件で UI から隠れているのか」を切り分ける場合、バックアップ後に単一モデルの値を一時的に null にすることはできます。
jq --arg MODEL "$MODEL" '
(.models[]
| select(.slug == $MODEL)
| .minimal_client_version
) = null
' ~/.codex/codex-models.json > ~/.codex/codex-models.json.new &&
jq empty ~/.codex/codex-models.json.new &&
mv ~/.codex/codex-models.json.new ~/.codex/codex-models.jsonただし、これは診断用です。
選択肢に表示されることと、現在のクライアントがそのモデルに本当に対応していることは別です。
通常は先にクライアントを更新します。
Codex 側で見えた後は Sub2API を別レイヤーとして確認する
ローカル Codex で gpt-6.1-sol が選べても、それだけでは実際の API リクエストが正しく流れる保証にはなりません。
Sub2API 側にも許可やマッピングがあります。
公式 slug が存在する場合、私はできるだけ原名のまま通します。
Codex: gpt-6.1-sol
↓
Sub2API: gpt-6.1-sol
↓
OpenAI: gpt-6.1-sol確認するポイントは主に次です。
- OpenAI グループのモデル許可リストに新モデルがあるか
- アカウント単位の許可リストで制限されていないか
- モデルマッピングで旧モデルへ強制変換されていないか
- unknown model のデフォルト fallback で別 slug に送られていないか
公式に実在する slug なら、必要のない alias は増やしません。
マッピングが少ないほどログを読みやすく、将来の障害切り分けも簡単です。
Codex provider は Responses API のままにします。
wire_api = "responses"もし gpt-6 → gpt-6.1-sol のような alias が本当に必要なら、暗黙の fallback ではなく明示的な Sub2API ルールとして管理します。
最終確認は「見えること」ではなく上下流が一致すること
まずローカル catalog に slug があることを確認します。
jq -r '.models[].slug' ~/.codex/codex-models.json | grep "$MODEL"次に実際のリクエストを送り、Sub2API のログを確認します。
理想は次です。
要求モデル = gpt-6.1-sol
上流モデル = gpt-6.1-sol
リクエスト成功つまり完了条件は、
Codex の選択肢に表示される
+
要求モデルが正しい
+
Sub2API の上流モデルも正しい
+
実際の呼び出しが成功するです。
問題がある場合はレイヤーごとに見ます。
選択肢にない
→ catalog / クライアントバージョン
選択できるが Sub2API が拒否
→ 許可リスト
要求モデルは正しいが上流が違う
→ マッピング / デフォルト fallback
上流モデルも正しいのに失敗
→ 上流権限、アカウント、API 互換性この手順を固定してから、新しい Codex モデルが出るたびに「どこを変えるべきか」を最初から考え直す必要がなくなりました。
まず公式 catalog を信頼し、ローカル表示と Sub2API ルーティングを別々に確認するのが一番安定します。
Codex を自分の代理エンドポイントに接続しているなら、CLIProxyAPI と Codex の構成 も関連します。現在の Codex 自体の位置付けを理解したい場合は、新しい Codex は何が変わったのか も参考になります。