Qwen 3.8 Max in Codex CLI 2026: Config, 258K Fix, Real Cost

Does Codex CLI Support Qwen 3.8 Max?

Yes, through a gateway, and the full agent loop works. Codex has no built-in entry for it, so you declare a custom provider and point it at an endpoint that speaks the Responses API. Here is the whole setup at a glance.

What you can do:     Run the full Codex agent loop (apply_patch, shell, multi-turn) on Qwen 3.8 Max
Time required:       6 lines of TOML, about 5 minutes
What you need:       codex-cli 0.146.x, an ofox API key, no ChatGPT subscription
Model slug:          bailian/qwen3.8-max
Wire protocol:       responses (the only value Codex accepts in 2026)
Context you get:     258,400 tokens by default, not the 1M the model supports
Cap fix:             model_catalog_json, not model_context_window
3-task cost:         $0.0804 vs $0.5387 on GPT-5.5 (measured 2026-08-06)
Rate card:           $2 / $6 per 1M in/out, cache read $0.25

Qwen shipped 3.8 Max on August 3, 2026 with a 1M context window and a price roughly a fifth of GPT-5.5’s. Codex CLI is the obvious place to spend that budget. The connection works, and the config is short, but two things in the middle will quietly cost you: the context window Codex actually gives the model, and the token number the CLI prints at the end of a run.

Both are measured below on codex-cli 0.146.1.

What Can You Do With Qwen 3.8 Max in Codex (and What Can’t You)?

You get the real agent loop, not a chat box. In testing, Qwen 3.8 Max read files, patched them through Codex’s apply_patch tool, ran python3 to verify its own fix, and reported back. That last part matters more than it sounds. The apply_patch tool is where several other models fail on this exact path: Claude Sonnet 5 through the same gateway rejects Codex’s freeform tool shape with tools.0.custom.strict: Extra inputs are not permitted, and DeepSeek and Grok fail on Encrypted content is not supported with this model. Qwen 3.8 Max does not.

What you do not get:

• The full 1M context. Codex clamps unknown models to 258,400 tokens. Fixable, but not with the setting most guides name.
• Codex’s built-in system prompt. Once you supply a custom model catalog to lift the cap, you also have to supply your own base_instructions. OpenAI’s compiled-in prompt is not available to third-party slugs.
• A billing display you can trust. The tokens used line under-reports by whatever was cached, which in one run was 85% of the input.
• ChatGPT-plan billing. This is an API-key path. Your Codex weekly limit is untouched, and so is your ChatGPT subscription.

When Should You Use This Setup (and When Not)?

Use it when your Codex bill is the problem, not your model quality. Everything below assumes you already run Codex daily and know what you spend.

When to use it:

• You are burning through Codex’s weekly cap on GPT-5.5 and want a cheaper model for the routine two-thirds of your work (refactors, test scaffolding, code explanation).
• You want one API key that reaches Qwen, GPT, and Claude models without maintaining three auth paths.
• You already run Codex and do not want to switch CLIs to get at a Chinese frontier model.

When NOT to use it:

• You need Codex’s tuned system prompt and skills behavior. Custom catalog entries replace it with whatever you write.
• Your work genuinely needs more than 258K of context and you are not willing to maintain a JSON catalog file to unlock it.
• You only want to compare model quality, not run an agent. A direct API call is simpler and skips this entire layer.

Stop rule: if all you want is a cheaper model for short tasks, stop after Step 3. The catalog work in Step 4 only pays off when your sessions run long enough to hit the cap.

What Do You Need Before You Start?

A current Codex, a gateway key, and nothing from OpenAI.

One naming rule trips people up. Under a custom provider you use the namespaced slug bailian/qwen3.8-max. Under native OpenAI auth you would write bare model names like gpt-5.5, with no prefix. The prefix is the gateway’s catalog namespace, not part of the model’s identity, and mixing the two forms in one config is the fastest way to get a model-not-found error.

How Do You Configure Qwen 3.8 Max in Codex CLI?

Three steps: install, declare the provider, run. The config below is the version that worked on 0.146.1, not a template to adapt.

Step 1: Install Codex and set your key

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

Do not use codex login --with-api-key here. That path writes an OpenAI key into auth.json for the built-in provider, which is not what a custom provider reads.

Step 2: Write the provider block

Create ~/.codex/config.toml:

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

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

Six lines of provider config, and every one of them earns its place:

• wire_api = "responses" is now the only accepted value. Passing "chat" is a hard startup error, not a warning, and it points at OpenAI’s deprecation discussion. The current config reference states plainly that responses “is the only supported value, and it is the default when omitted.”
• env_key names the variable Codex reads. Omit this line and Codex will not error. It falls back to whatever OpenAI key sits in auth.json and sends that to your gateway, producing a 401 that blames your key when the problem is that a different key went out.
• requires_openai_auth = false skips the ChatGPT login screen. It does not mean what older guides claim about key formats.

Step 3: Run it

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

Expected result: Codex reads the file, calls apply_patch, runs the script to check its own work, and prints a summary. Our test repo went from a one-line return xs[n // 2] to a correct even-length branch plus an empty-input guard, verified by the model running python3 stats.py and reading 2.5 back.

If that worked, the integration is live. What follows is about the two numbers Codex reports along the way.

Why Does Codex Cap My Context Window at 258,400 Tokens?

Because Codex only knows the capabilities of OpenAI’s own models, and everything else gets conservative defaults. You will see this on the first run:

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

The warning reads like cosmetic noise. It is not. Codex ships a compiled-in catalog of model entries, and any slug outside it falls back to a fixed profile. Reading the session log confirms what that costs:

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

"model_context_window":258400

Qwen 3.8 Max carries 1,131,072 tokens on the ofox model page. Codex hands it 258,400, about 23% of what you are paying for access to. Long sessions start auto-compacting far earlier than they should, and you never see why.

Does model_context_window Fix It?

No, and this is the part worth testing before you trust it. The advice circulating for this problem is to add model_context_window to the top of config.toml. It is a real key, documented as “context window tokens available to the active model.” It did not work here.

Three of those four are the fix people recommend. Only the fourth moved the number on 0.146.1.

How Do You Actually Unlock the Full Context Window?

Point model_catalog_json at a JSON file that declares the model properly. Codex validates this file strictly, and the ModelInfo struct has 39 fields. Working around the validator one error at a time produced this, which loads cleanly:

{"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."
}]}

Save it and load it:

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

The warning disappears and the session reports the full 1,131,072. The agent loop still works: the same median fix ran through apply_patch with the catalog active.

Read the last field before you commit to this. base_instructions is required and must be a string, which means you are replacing Codex’s system prompt with your own. OpenAI’s compiled-in instructions run to thousands of words covering tool discipline, output formatting, and autonomy rules. The one-line placeholder above is enough to keep the agent functional in testing, but it is not equivalent. If your sessions comfortably fit in 258K, skipping this whole step is a defensible call.

What Errors Will You Hit During Setup?

Mostly authentication errors that blame the wrong thing. Every row here was reproduced on 0.146.1 rather than collected from other people’s guides.

Two of these deserve emphasis because they mislead actively. The missing env_key case produces an authentication error about a key you never intended to send. And codex login status does no network validation at all, so it will happily report a working login while every request fails. Diagnosing auth means sending a real request; /v1/models will not do it either, since ofox serves the catalog publicly and returns 200 with no key at all. We covered the full matrix in Codex CLI 401 unauthorized.

What Does Qwen 3.8 Max Actually Cost in Codex?

About $0.08 for three real coding tasks, against $0.54 for the same three on GPT-5.5. Both runs went through the same CLI, same gateway, same repo, same prompts, on 2026-08-06.

Prices are from the ofox model pages that day: Qwen 3.8 Max at $2/M input, $6/M output, $0.25/M cache read; GPT-5.5 at $5/M input, $30/M output, $0.5/M cache read.

Underlying token counts, since the totals alone are not checkable:

Is the 6.7x Gap Real?

Partly. The rate card justifies 2.5x on input and 5x on output; the rest comes from configuration and task-level variance, not from Qwen being a more efficient model. Two things inflate the measured gap beyond the price difference, and both are worth knowing before you quote the number.

The first is the system prompt. GPT-5.5 resolves against Codex’s built-in catalog and receives OpenAI’s full instruction set on every turn. Qwen 3.8 Max, running under a custom catalog, receives the one-line base_instructions shown earlier. That difference rides along in the input tokens of every single turn.

The second is turn count, which the model chooses for itself. On the “explain the repo” task, GPT-5.5 took 8 API round trips and 7 tool calls; Qwen took 4 and 3. That alone explains most of the 11.5x on that row. On the type-hints task the pattern inverted, with Qwen taking 6 round trips to GPT-5.5’s 5 and still costing less, which is where the per-turn overhead difference shows up cleanly.

Three tasks, one run each, one repo. Cache hit rates drift between runs depending on what you called before. Treat 6.7x as what this configuration billed on that day, and 2.5x/5x as the floor you can count on from the rate card alone. For a benchmark-driven comparison instead of a billing one, see Qwen 3.8 Max vs DeepSeek V4 Flash.

Why Is the Token Count in Codex Lower Than My Bill?

Because the tokens used line subtracts cached input. The median fix printed tokens used 5,859. The session log for the same run:

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

38,371 minus 32,512 is 5,859. The displayed figure is total tokens minus the cached portion, which is a reasonable proxy for marginal cost and a bad proxy for your invoice. Those 32,512 cached tokens are billed at the cache-read rate, not free. Pull the real numbers from the log:

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

Does Reasoning Effort Change the Bill Much?

Not as much as the token counts suggest. Same task, same model, only model_reasoning_effort changed:

Reasoning output rose 2.5x. The bill rose 3.3%. In an agent loop the conversation replay dominates, and reasoning is a thin slice on top. This runs against the usual advice to keep effort low for cost reasons, at least for Qwen 3.8 Max in Codex. Pick effort on output quality and leave the budget argument out of it.

The caveat is that this holds for short agentic tasks. A single long reasoning-heavy request with little tool use will shift the ratio.

How Do You Share This Config Across a Team?

With profiles, so nobody edits a shared file to switch models. Profiles are how you keep a shared config from becoming three people’s private hacks. Define both stacks once and let each developer pick per project:

[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"

Three things to settle as a team before this spreads:

• Keys stay in the environment. env_key reads a variable name, so the config file itself holds no secret and can go in the repo. Do not let anyone paste a literal key into it.
• The catalog file needs a home. If you unlock the full context window, model_catalog_json points at an absolute path. Commit the JSON to the repo and reference it relatively per developer, or you will get “works on my machine” reports that are really “the file is at a different path.”
• Pin the CLI version. The wire_api = "chat" removal broke configs that had worked for a year. Note the tested version alongside the config.

Shared ~/.codex/config.toml layouts are covered further in our Codex config.toml deep dive and multi-provider setup guide.

Advanced: Which Models Can Actually Replace Qwen Here?

Not every model behind an OpenAI-compatible gateway survives the Responses API path Codex requires. A catalog listing /v1/responses is necessary but not sufficient, and the failures are silent until you send a real request. All six rows below were run through the same gateway on 2026-08-06:

The encrypted-content failures are not fixable from your side. Codex hard-codes reasoning.encrypted_content into every request with no config switch. That is why a model can list the right endpoint and still fail.

To check candidates before you spend a session finding out:

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

Then send one real request. That listing filters out the obvious failures and misses the subtle ones. Current pricing and protocol support for each model sits on the ofox model pages.

Alternatives Worth Considering

• ofox gateway. One key, both protocols, and the model slugs used throughout this article. Qwen 3.8 Max at $2/$6 with cache read at $0.25/M.
• Alibaba DashScope direct. The international compatible-mode base does expose a /responses path; it answers 401 rather than 404 without a key, so the endpoint exists. We had no DashScope key to test the Codex loop against it, so treat this as unverified rather than confirmed. Alibaba documents the compatible mode in its Model Studio OpenAI compatibility guide.
• OpenRouter. Broad model coverage, though Codex’s Responses requirement narrows what is usable there the same way it does here.
• Staying on GPT-5.5. If you need Codex’s tuned system prompt and skills behavior more than you need a 5x cheaper output rate, that is a real tradeoff and not an obviously wrong one.

FAQ

Is Qwen 3.8 Max worth switching to just for the price? For routine agent work, the rate card gap is large enough to matter: 2.5x on input and 5x on output. For work where a wrong answer costs a debugging session, evaluate quality first. Pricing details and launch specs are in our Qwen 3.8 Max launch breakdown.

Does this affect my ChatGPT or Codex plan limits? No. A custom provider is an API-key path with separate billing. Your weekly Codex cap is untouched.

Can I use Qwen 3.8 Max’s image input through Codex? The model accepts text and image input, and the catalog entry above declares both. Image handling inside the Codex loop was not part of this testing.

Will the 258K cap be fixed upstream? Codex resolves model metadata from a compiled-in catalog, so third-party slugs will keep falling back until that design changes. The catalog file is the supported escape hatch today.

Sources Checked for This Refresh

• Codex CLI configuration reference, wire_api and model_catalog_json keys (verified 2026-08-06): https://learn.chatgpt.com/docs/config-file/config-reference
• OpenAI Codex discussion 7782, deprecating chat/completions support: https://github.com/openai/codex/discussions/7782
• Qwen 3.8 Max launch post, Alibaba Qwen team: https://qwen.ai/blog?id=qwen3.8
• Alibaba Model Studio OpenAI compatibility documentation: https://www.alibabacloud.com/help/en/model-studio/compatibility-of-openai-with-dashscope
• ofox model page snapshots for bailian/qwen3.8-max and openai/gpt-5.5 pricing (2026-08-06)
• Local runs on codex-cli 0.146.1, macOS 26.4 arm64, session logs under $CODEX_HOME/sessions/2026/08/06/