Codex CLI で Qwen 3.8 Max を使う 2026：6 行の設定、258K 上限の外し方、実測コスト

Codex CLI は Qwen 3.8 Max に対応しているのか？

ゲートウェイ経由で対応し、agent ループも完全に動きます。 Codex 側に組み込みのエントリが無いので、カスタム provider を宣言して Responses API を話すエンドポイントに向けます。全体像はこれだけです。

できること：       Qwen 3.8 Max で Codex の完全な agent ループ（apply_patch、shell、マルチターン）
所要時間：         TOML 6 行、約 5 分
必要なもの：       codex-cli 0.146.x、ofox の API key、ChatGPT サブスクリプションは不要
モデル slug：      bailian/qwen3.8-max
ワイヤープロトコル： responses（2026 年の Codex が受け付ける唯一の値）
得られる文脈長：   デフォルト 258,400 token。モデルが対応する 100 万ではない
上限の外し方：     model_catalog_json。model_context_window ではない
3 タスクの費用：   $0.0804（GPT-5.5 では $0.5387、2026-08-06 実測）
定価：             1M あたり入力 $2 / 出力 $6、キャッシュ読み取り $0.25

Qwen は 2026 年 8 月 3 日に 3.8 Max を、100 万コンテキストかつ GPT-5.5 のおよそ 5 分の 1 の価格でリリースしました。その予算を使う場所として Codex CLI は素直な選択肢です。接続は通り、設定も短いのですが、途中の 2 つが静かにコストを増やします。Codex が実際にモデルへ渡すコンテキストウィンドウと、実行後に CLI が表示する token 数です。

以下はどちらも codex-cli 0.146.1 上で計測した値です。

Codex の Qwen 3.8 Max で何ができて、何ができないのか？

得られるのはチャットボックスではなく本物の agent ループです。 テストでは Qwen 3.8 Max がファイルを読み、Codex の apply_patch ツールでパッチを当て、python3 を実行して自分の修正を検証し、結果を報告しました。最後の部分は聞こえ以上に重要です。この経路では apply_patch が複数のモデルの脱落地点になっています。同じゲートウェイ経由の Claude Sonnet 5 は Codex の freeform ツール形状を tools.0.custom.strict: Extra inputs are not permitted で拒否し、DeepSeek と Grok は Encrypted content is not supported with this model で失敗します。Qwen 3.8 Max は落ちません。

得られないもの：

• 100 万コンテキストの全量。 Codex は未知のモデルを 258,400 token に制限します。外せますが、多くの解説記事が挙げる設定では外れません。
• Codex 組み込みのシステムプロンプト。 上限を外すためにカスタムモデルカタログを渡すと、base_instructions も自分で用意することになります。OpenAI がコンパイル時に埋め込んだプロンプトはサードパーティ slug には提供されません。
• 信用できる課金表示。 tokens used の行はキャッシュ分だけ少なく出ます。ある実行では入力の 85% がそれでした。
• ChatGPT プラン課金。 これは API key 経路です。Codex の週次上限も ChatGPT サブスクリプションも消費しません。

どんなときに使い、どんなときに使わないべきか？

問題がモデル品質ではなく Codex の請求額であるときです。 以下はすべて、すでに Codex を日常的に使っていて支出額も把握していることを前提にしています。

使うべきケース：

• GPT-5.5 で Codex の週次上限を使い切りつつあり、日常業務の 3 分の 2（リファクタ、テストの足場作り、コード説明）を安いモデルに回したい。
• Qwen、GPT、Claude 系モデルに 1 本の API key で届かせたい。認証経路を 3 つ維持したくない。
• すでに Codex を使っていて、中国製フロンティアモデルのために CLI を乗り換えたくない。

使わないほうがいいケース：

• Codex のチューニング済みシステムプロンプトと skills の挙動が必要。カスタムカタログのエントリはそれを自分が書いた内容に置き換えます。
• 業務が本当に 258K を超える文脈を要求し、かつそれを解放するための JSON カタログを保守する気がない。
• agent を動かすのではなくモデル品質を比べたいだけ。それなら直接 API を叩くほうが簡単で、この層は丸ごと不要です。

打ち切りルール： 短いタスク用に安いモデルが欲しいだけなら、ステップ 3 で止めて構いません。ステップ 4 のカタログ作業が報われるのは、セッションが上限に届くほど長くなる場合だけです。

始める前に必要なもの

現行の Codex、ゲートウェイの key、そして OpenAI 側には何も不要です。

命名規則で 1 つ引っかかりやすい点があります。カスタム provider 配下では名前空間付きの bailian/qwen3.8-max を使い、OpenAI ネイティブ認証では gpt-5.5 のように接頭辞なしの素のモデル名を書きます。この接頭辞はゲートウェイのカタログ名前空間であってモデルの識別子の一部ではなく、1 つの設定ファイルで両形式を混ぜるのが model-not-found を最短で引き当てる方法です。

Codex CLI で Qwen 3.8 Max をどう設定するか？

インストール、provider の宣言、実行の 3 ステップです。 以下の設定は 0.146.1 で実際に動いたもので、各自で改変する前提のテンプレートではありません。

ステップ 1：Codex のインストールと key の設定

npm i -g @openai/codex
export OFOX_API_KEY="sk-of-..."
codex --version   # 0.146.x を期待

ここで codex login --with-api-key は使わないでください。あれは組み込み provider 用に OpenAI の key を auth.json に書き込む経路で、カスタム provider が読むのはそこではありません。

ステップ 2：provider ブロックを書く

~/.codex/config.toml を作成します：

model = "bailian/qwen3.8-max"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox"
base_url = "https://api.ofox.io/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

provider 設定 6 行、そのすべてに意味があります：

• wire_api = "responses" は現在唯一受け付けられる値です。"chat" を渡すと警告ではなく起動時エラーになり、エラーは OpenAI の非推奨化ディスカッションを指します。現行の設定リファレンスには responses が「唯一のサポート値であり、省略時のデフォルトでもある」と明記されています。
• env_key は Codex が読む環境変数名を指定します。この行を省略しても Codex はエラーになりません。auth.json にある OpenAI の key にフォールバックして、それをあなたのゲートウェイに送ります。結果は 401 で、あなたの key のせいに見えますが、実際は別の key が飛んでいるのが原因です。
• requires_openai_auth = false は ChatGPT のログイン画面をスキップします。古い解説にある key 形式の話とは関係ありません。

ステップ 3：実行する

codex exec --sandbox workspace-write "median() is wrong for even-length input. Fix it in stats.py."

期待される結果：Codex がファイルを読み、apply_patch を呼び、スクリプトを実行して自分の作業を検証し、サマリを出力します。テスト用リポジトリでは 1 行の return xs[n // 2] から偶数長の分岐と空入力ガードを持つ正しい実装に変わり、モデル自身が python3 stats.py を実行して 2.5 を読み戻すところまで確認しました。

ここまで動けば連携は生きています。以下は Codex が途中で報告してくる 2 つの数値についての話です。

なぜ Codex はコンテキストウィンドウを 258,400 に制限するのか？

Codex は OpenAI 自社モデルの能力しか知らず、それ以外はすべて保守的なデフォルトになるからです。 初回実行でこう出ます：

warning: Model metadata for `bailian/qwen3.8-max` not found.
Defaulting to fallback metadata; this can degrade performance and cause issues.

見た目は無害なノイズです。実際は違います。Codex はコンパイル時に埋め込まれたモデルエントリのカタログを持ち、そこに無い slug は固定プロファイルにフォールバックします。セッションログを読むとその代償が分かります：

grep -o '"model_context_window":[0-9]*' \
  ~/.codex/sessions/2026/08/06/rollout-*.jsonl | tail -1

"model_context_window":258400

Qwen 3.8 Max は ofox のモデルページ上で 1,131,072 token です。Codex が渡すのは 258,400、アクセス料を払っている量の約 23% です。長いセッションは本来よりずっと早く自動圧縮を始め、その理由は表に出ません。

model_context_window で直るのか？

直りません。ここは信じる前にテストする価値があります。 この問題に対して出回っている助言は config.toml の先頭に model_context_window を足すことです。実在するキーで、ドキュメントにも「現在のモデルで利用可能なコンテキストウィンドウの token 数」とあります。ここでは効きませんでした。

4 つのうち 3 つが世間で勧められている解決策です。0.146.1 で数値を動かしたのは 4 つ目だけでした。

完全なコンテキストウィンドウを実際に解放するには？

model_catalog_json を、モデルを正しく宣言した JSON ファイルに向けます。 Codex はこのファイルを厳密に検証し、ModelInfo 構造体には 39 個のフィールドがあります。バリデータのエラーを 1 つずつ潰して出来上がったのが以下で、これはクリーンに読み込まれます：

{"models": [{
  "slug": "bailian/qwen3.8-max",
  "display_name": "Qwen3.8 Max",
  "description": "Qwen3.8 Max via ofox",
  "context_window": 1131072,
  "max_context_window": 1131072,
  "effective_context_window_percent": 100,
  "default_reasoning_level": "medium",
  "supported_reasoning_levels": [
    {"effort": "low", "description": "low"},
    {"effort": "medium", "description": "med"},
    {"effort": "high", "description": "high"}],
  "shell_type": "shell_command",
  "visibility": "list",
  "supported_in_api": true,
  "priority": 1,
  "support_verbosity": false,
  "default_verbosity": "low",
  "truncation_policy": {"mode": "tokens", "limit": 10000},
  "apply_patch_tool_type": "freeform",
  "web_search_tool_type": "text_and_image",
  "input_modalities": ["text", "image"],
  "supports_image_detail_original": false,
  "supports_parallel_tool_calls": true,
  "tool_mode": "direct",
  "multi_agent_version": null,
  "use_responses_lite": false,
  "include_skills_usage_instructions": false,
  "auto_review_model_override": null,
  "auto_compact_token_limit": null,
  "comp_hash": "3000",
  "reasoning_summary_format": "experimental",
  "default_reasoning_summary": "none",
  "minimal_client_version": "0.0.1",
  "prefer_websockets": false,
  "supports_reasoning_summary_parameter": true,
  "supports_search_tool": false,
  "experimental_supported_tools": [],
  "additional_speed_tiers": [],
  "service_tiers": [],
  "default_service_tier": null,
  "availability_nux": null,
  "upgrade": null,
  "model_specialty": null,
  "memory_consolidation": null,
  "base_instructions": "You are Codex, a coding agent running in the Codex CLI. Use apply_patch for file edits."
}]}

保存して読み込ませます：

codex exec -c model_catalog_json=/path/to/catalog.json \
  --sandbox workspace-write "your task here"

警告は消え、セッションは 1,131,072 をそのまま報告します。agent ループも引き続き動作し、同じ median 修正がカタログ有効の状態で apply_patch を通りました。

これを採用する前に最後のフィールドを読んでください。base_instructions は必須かつ文字列である必要があり、つまり Codex のシステムプロンプトを自分の書いたもので置き換えることになります。OpenAI が埋め込んでいる指示はツール運用の規律、出力フォーマット、自律性のルールを含めて数千語規模です。上の 1 行のプレースホルダは検証中 agent を機能させるには足りましたが、等価ではありません。セッションが 258K に余裕で収まるなら、この工程を丸ごと飛ばすのは妥当な判断です。

セットアップ中にどんなエラーに当たるか？

大半は認証エラーで、しかも見当違いのものを責めてきます。 以下の各行は他人のガイドからの引用ではなく、0.146.1 上で再現したものです。

このうち 2 つは積極的に誤解を招くので強調しておきます。env_key の欠落は、送るつもりの無かった key についての認証エラーを生みます。そして codex login status はネットワーク検証を一切しないので、全リクエストが失敗している最中でも「ログインは有効」と平然と報告します。認証の診断には実リクエストを送るしかありません。/v1/models も役に立ちません。ofox はカタログを公開しており、key 無しでも 200 を返すからです。完全なマトリクスは Codex CLI 401 unauthorized で扱っています。

Codex での Qwen 3.8 Max は実際いくらかかるのか？

実際のコーディングタスク 3 件で約 $0.08、同じ 3 件を GPT-5.5 でやると $0.54 です。 どちらの実行も同じ CLI、同じゲートウェイ、同じリポジトリ、同じプロンプト、2026-08-06 のものです。

価格はその日の ofox モデルページから：Qwen 3.8 Max は 1M あたり入力 $2、出力 $6、キャッシュ読み取り $0.25。GPT-5.5 は入力 $5、出力 $30、キャッシュ読み取り $0.5。

合計だけでは検算できないので、内訳の token 数も出します：

6.7 倍という差は本物か？

一部は本物です。定価が説明できるのは入力 2.5 倍・出力 5 倍まで。残りは設定差とタスク単位のばらつきであって、Qwen が効率的なモデルだからではありません。 実測差を価格差以上に押し上げている要因が 2 つあり、どちらもこの数字を引用する前に知っておく価値があります。

1 つ目はシステムプロンプトです。GPT-5.5 は Codex の組み込みカタログに解決され、毎ターン OpenAI の完全な指示セットを受け取ります。カスタムカタログで動く Qwen 3.8 Max が受け取るのは、先ほどの 1 行の base_instructions です。この差は毎ターンの入力 token に乗り続けます。

2 つ目はターン数で、これはモデル自身が決めます。「リポジトリの説明」タスクでは GPT-5.5 が API 往復 8 回・ツール呼び出し 7 回、Qwen は 4 回と 3 回でした。あの行の 11.5 倍はほぼこれで説明がつきます。型ヒントのタスクではパターンが反転し、Qwen が往復 6 回に対して GPT-5.5 が 5 回、それでも Qwen のほうが安く済みました。ターンあたりのオーバーヘッド差がきれいに出ている箇所です。

3 タスク、各 1 回、リポジトリは 1 つ。キャッシュヒット率は直前に何を呼んだかで揺れます。6.7 倍はこの構成がその日に請求された額として扱い、定価だけから確実に見込めるのは 2.5 倍 / 5 倍のほうだと考えてください。課金ではなくベンチマーク中心の比較は Qwen 3.8 Max と DeepSeek V4 Flash を参照してください。

なぜ Codex の token 数は請求額より小さいのか？

tokens used の行がキャッシュ入力を差し引いているからです。 median 修正の表示は tokens used 5,859 でした。同じ実行のセッションログ：

{"input_tokens": 37401, "cached_input_tokens": 32512,
 "output_tokens": 970, "total_tokens": 38371}

38,371 から 32,512 を引くと 5,859 です。表示される数字は合計 token からキャッシュ分を引いたもので、限界コストの目安としては妥当ですが、請求書の目安としては不適切です。この 32,512 のキャッシュ token は無料ではなく、キャッシュ読み取り単価で課金されます。実数はログから取り出します：

grep -o '"total_token_usage":{[^}]*}' \
  ~/.codex/sessions/2026/08/06/rollout-*.jsonl | tail -1

reasoning effort で請求額は大きく変わるか？

token 数の変化ほどには変わりません。 同じタスク、同じモデルで model_reasoning_effort だけを変えました：

reasoning 出力は 2.5 倍に増え、請求額は 3.3% 増えました。agent ループでは会話の再送が支配的で、reasoning はその上に乗る薄い層です。少なくとも Codex 上の Qwen 3.8 Max については、コスト目的で effort を低く保てという通説とは逆の結果です。effort は出力品質で選び、予算の議論は外して構いません。

ただしこれは短い agentic タスクでの話です。ツール呼び出しが少なく推論が長い単発リクエストでは比率が変わります。

この設定をチームで共有するには？

profile を使い、モデル切り替えのために共有ファイルを誰も編集しなくて済むようにします。 profile は共有設定が 3 人分の私物パッチに退化するのを防ぐ仕組みです。両方のスタックを一度定義しておき、各開発者がプロジェクトごとに選びます：

[profiles.cheap]
model = "bailian/qwen3.8-max"
model_provider = "ofox"
model_reasoning_effort = "medium"

[profiles.heavy]
model = "openai/gpt-5.5"
model_provider = "ofox"
model_reasoning_effort = "high"

codex exec --profile cheap "add tests for the parser"
codex exec --profile heavy "redesign the scheduler's backpressure"

展開前にチームで決めておくことが 3 つあります：

• key は環境変数に置く。 env_key は変数名を読むので、設定ファイル自体は秘密情報を含まずリポジトリに入れられます。生の key を貼らせないこと。
• カタログファイルの置き場所を決める。 コンテキストウィンドウを解放するなら model_catalog_json は絶対パスを指します。JSON をリポジトリにコミットして各自が相対パスで参照する形にしないと、「自分の環境では動く」という報告が実は「ファイルの場所が違う」だったという事態になります。
• CLI のバージョンを固定する。 wire_api = "chat" の削除は 1 年動いていた設定を壊しました。検証したバージョンを設定の隣に書き残してください。

共有 ~/.codex/config.toml の構成は Codex config.toml 詳解とマルチ provider 設定ガイドでさらに扱っています。

応用：ここで Qwen を実際に代替できるモデルは？

OpenAI 互換ゲートウェイの背後にあるモデルがすべて、Codex の要求する Responses API 経路を生き延びるわけではありません。カタログに /v1/responses が載っているのは必要条件であって十分条件ではなく、失敗は実リクエストを送るまで表に出ません。以下 6 行はすべて 2026-08-06 に同じゲートウェイで実行したものです：

encrypted-content 系の失敗は利用者側では直せません。Codex は reasoning.encrypted_content を全リクエストにハードコードしており、設定で切れません。モデルが正しいエンドポイントを掲げていても失敗しうるのはこのためです。

セッションを 1 つ潰して確かめる前に候補を絞るには：

curl -s https://api.ofox.io/v1/models -H "Authorization: Bearer $OFOX_API_KEY" \
  | jq -r '.data[] | select(.supported_endpoints | index("/v1/responses")) | .id'

そのうえで実リクエストを 1 本送ります。この一覧は明らかな失敗は弾きますが、微妙なものは取り逃がします。各モデルの現在の価格とプロトコル対応は ofox のモデルページにあります。

検討に値する代替案

• ofox ゲートウェイ。 key 1 本で両プロトコル、本記事で使ったモデル slug もそのまま。Qwen 3.8 Max は $2/$6、キャッシュ読み取り $0.25/M。
• Alibaba DashScope 直接接続。 国際版の互換モードのベース URL には /responses パスがあり、key 無しでも 404 ではなく 401 が返るのでエンドポイントは存在します。DashScope の key が無く Codex ループを検証できていないため、確認済みではなく未検証として扱ってください。Alibaba は Model Studio の OpenAI 互換性ガイドで互換モードを説明しています。
• OpenRouter。 モデルの網羅性は広いものの、Codex の Responses 要件がここと同じように使える範囲を狭めます。
• GPT-5.5 のままにする。 Codex のチューニング済みシステムプロンプトと skills の挙動が、出力単価 5 分の 1 より価値があるなら、それは実在するトレードオフであって明らかな誤りではありません。

FAQ

価格だけを理由に Qwen 3.8 Max へ乗り換える価値はありますか？ 日常的な agent 作業なら、定価の差は動く理由になります。入力 2.5 倍、出力 5 倍です。間違った答えがデバッグ 1 セッション分のコストになる作業では、まず品質を評価してください。価格詳細とローンチ仕様は Qwen 3.8 Max ローンチ解説にあります。

ChatGPT や Codex のプラン上限に影響しますか？ しません。カスタム provider は課金が独立した API key 経路です。Codex の週次上限は消費しません。

Codex 経由で Qwen 3.8 Max の画像入力は使えますか？ モデルはテキストと画像の入力を受け付け、上のカタログエントリも両方を宣言しています。Codex ループ内での画像処理は今回の検証対象外です。

258K の上限は上流で修正されますか？ Codex はコンパイル時に埋め込まれたカタログからモデルメタデータを解決するため、その設計が変わらない限りサードパーティ slug はフォールバックし続けます。今日の時点で用意されている公式の抜け道はカタログファイルです。

References

• Codex CLI 設定リファレンス、wire_api と model_catalog_json キー（2026-08-06 確認）：https://learn.chatgpt.com/docs/config-file/config-reference
• OpenAI Codex discussion 7782、chat/completions サポートの非推奨化：https://github.com/openai/codex/discussions/7782
• Qwen 3.8 Max ローンチ記事、Alibaba Qwen チーム：https://qwen.ai/blog?id=qwen3.8
• Alibaba Model Studio OpenAI 互換性ドキュメント：https://www.alibabacloud.com/help/en/model-studio/compatibility-of-openai-with-dashscope
• bailian/qwen3.8-max と openai/gpt-5.5 の ofox モデルページ価格スナップショット（2026-08-06）
• ローカル実行：codex-cli 0.146.1、macOS 26.4 arm64、セッションログは $CODEX_HOME/sessions/2026/08/06/