Token Station 経由で Codex に任意のモデルを使う

OpenAI が Codex について控えめながら有用な点を示した。Codex の app、CLI、SDK は OpenAI 製に限らず任意のモデルを動かせる。プロダクトはこのハーネスであり、背後のモデルは選択肢にすぎない。だから Codex はそのままに、GPT-5.5、Claude、あるいは GLM-5.2 や Kimi K2.7 のようなオープンウェイトモデルなど、タスクに合うものに向ければよい。

ただし多くの人がつまずく落とし穴がひとつある。2026 年 2 月以降、Codex は OpenAI の Responses API に統一された。プロバイダ連携は wire_api = "responses" を前提とし、旧来の Chat Completions 経路はもう入口ではない。つまり Codex を向けるモデルプラットフォームは、Chat Completions だけでなく Responses API をネイティブに話せる必要がある。多くのゲートウェイは後者しか実装しておらず、ここで動かなくなる。

Token Station はホストするすべてのモデルを OpenAI の Responses API（/v1/responses）で公開しているため、Codex はシムなしで直接つながる。本記事ではそのままの設定、検証コマンド、1 行でのモデル切り替え、そして smart routing の位置づけを示す。

なぜカスタムプロバイダが必要か（環境変数だけでは不十分）

Claude Code なら環境変数だけで別のエンドポイントへリダイレクトできる。Codex は違う。組み込みの OpenAI プロバイダは OPENAI_BASE_URL を無視し、常に api.openai.com に接続する。この変数を設定してもデフォルトプロバイダには何の効果もない。

OpenAI の高度な設定ドキュメントによれば、サポートされる方法は ~/.codex/config.toml の [model_providers.<id>] に独自エントリを定義し、model_provider で選択することだ。（組み込みプロバイダを変えるには openai_base_url を使い、予約済みの openai という id は再利用できないため、名前付きのカスタムプロバイダがすっきりした道筋になる。）API キーは環境変数に置いたままで、設定からは env_key で参照するので、秘密の値がファイルに残ることはない。

一度きりの設定

設定ファイルを作る。これは Responses API を使う token_station プロバイダを定義し、デフォルトにする：

mkdir -p ~/.codex
cat > ~/.codex/config.toml <<'EOF'
model = "openai/gpt-5.5"
model_provider = "token_station"

[model_providers.token_station]
name = "Token Station"
base_url = "https://models.bytefuture.ai/v1"
env_key = "TOKEN_STATION_API_KEY"
wire_api = "responses"
EOF

次に Token Station のキーをエクスポートし（変数名は上の env_key と一致させる）、1 行で確認する：

export TOKEN_STATION_API_KEY="YOUR_TOKEN_STATION_KEY"

codex exec "Respond with exactly the word: pong"

pong と表示されれば、Codex は Responses API 経由で Token Station と通信できている。ここから codex を実行すれば、同じプロバイダで対話セッションが開く。

各フィールドの意味

OpenAI 公式ドキュメントと一致する

上のキーはすべて、OpenAI がドキュメント化したカスタムプロバイダの schema そのままだ。トップレベルの model と model_provider、続いて name・base_url・env_key・wire_api を持つ [model_providers.<id>] テーブル。token_station という id が許されるのは、予約済み id（openai、ollama、lmstudio）ではないからだ。今日の Codex でひとつだけ正確に合わせる必要がある値は wire_api = "responses"。このブロックに Token Station 固有の構文は一切なく、どのプロバイダでも書く形と同じだ。

1 行でモデルを切り替える

Token Station のすべてのモデルは同じキー、同じ Responses エンドポイントの背後にあるため、モデルの切り替えは設定の model を一箇所書き換えるだけ、または起動時のフラグで済む：

codex --model anthropic/claude-opus-4-8 exec "Summarize git diff and suggest a commit message"

同じ設定のまま、いますぐ model に入れられるモデル ID をいくつか：

OpenAI が示したかった点がここに着地する。Codex はモデル非依存だ。難しいタスクには高価なモデルを、定型コードには安価なオープンウェイトモデルを。ハーネスを離れることなく、書き換えるのも 1 行だけだ。

Smart routing：1 つの ID にモデルを選ばせる

タスクごとにモデルを固定するのも構わないが、Token Station では名前ではなくルールで振り分けることもできる。ワークロードにポリシーを定義し（品質の下限を満たす最も安いモデル、しきい値以下のレイテンシでプロバイダ許可リスト付き、あるいは主モデルの背後に予備を置く厳格なフォールバックチェーンなど）、Token Station がリクエストごとにモデルを選ぶ。

Codex にとってこれは好都合だ。Codex 自身はモデル ID を 1 つ送るだけだから。model をルーティング済みのワークロードに向ければ、判断はサーバ側に移る。主モデルが遅い、または使えない場合は予備が応答し、Codex セッションはそれを知る必要すらない。ルーティングは config.toml ではなく Token Station 側で変えるので、同じ Codex 設定がポリシーの進化に自動で追従する。

Codex はモデル ID を 1 つ送る。実際に応答するのは誰かを smart routing が決めるので、コストやフォールバックのロジックは設定に固定されず Token Station 側に置かれる。

うまくつながらないとき

• まだ api.openai.com につながる。OPENAI_BASE_URL を設定して組み込みプロバイダが従うと思っていないか。従わない。上のカスタムプロバイダを使い、model_provider = "token_station" を設定する。
• 401 / 認証エラー。エクスポートした変数名は env_key（TOKEN_STATION_API_KEY）と完全に一致し、かつ codex を実行する同じシェルでエクスポートする必要がある。
• モデルでプロトコルエラーまたは 404。wire_api = "responses" を確認する。Codex は Responses API を必須とし、Chat Completions だけのゲートウェイでは満たせない。
• モデル id が間違っている。provider/model 形式（例：anthropic/claude-opus-4-8）を使い、裸のモデル名は使わない。

はじめよう

Codex で任意のモデルを動かすのは、結局 4 行の TOML と環境変数 1 つに尽きる。唯一引っかかる要件が Responses API だ。Token Station はホストするすべてのモデルをこの API で提供するので、上の設定は GPT-5.5、Claude、GLM-5.2、あるいはルーティング済みのワークロードでも、そのまま動く。

models.bytefuture.ai で登録し（無料クレジット 10 ドル、カード不要）、キーを TOKEN_STATION_API_KEY に入れて pong チェックを実行しよう。キー 1 つ、エンドポイント 1 つで、Codex セッションに必要なすべてのモデルが手に入る。