Codex with local Qwen3.8-27B over the Responses API
Codex can use a custom provider over the Responses wire. This guide shows the minimum profile, support boundary and the Qwen result.
Syntalith
Codex documents a custom model provider that speaks the Responses protocol. In an after-hours experiment, we used it to connect the Codex client to Qwen3.8-27B behind patched vLLM. Transport, tools and context compaction worked. After the run, Codex evaluated the patch with Syntalith's criteria: correctness (40 points), regression tests (20), compatibility (15), scope and maintainability (10), verification (10) and documentation (5). The patch produced through the Codex client scored 87/100, while the Qwen Code patch on the same server scored 100/100. Codex was the evaluator in both cases; these were not independent-auditor scores.
The custom-provider feature belongs to the Codex client. It does not mean that OpenAI certifies Qwen, its weights or the patched vLLM instance. Repeat the five integration checks below after every client or server update.
The profile we actually used
Official Codex documentation describes base_url, the key source and wire protocol. This is the profile we measured, with local paths and host identity removed:
# ~/.codex/qwen-vllm.config.toml
model = "qwen3.8-27b"
model_provider = "qwen_vllm"
model_context_window = 150000
model_auto_compact_token_limit = 120000
model_auto_compact_token_limit_scope = "total"
model_reasoning_effort = "medium"
tool_output_token_limit = 6000
[model_providers.qwen_vllm]
name = "Qwen3.8-27B through local vLLM"
base_url = "http://127.0.0.1:18020/v1"
env_key = "QWEN_VLLM_API_KEY"
wire_api = "responses"
request_max_retries = 1
stream_max_retries = 1
On another device, 127.0.0.1 should terminate a local tunnel to the GPU host. Do not expose the port publicly. Keep the key in QWEN_VLLM_API_KEY, outside the TOML file and Git. We launched the profile separately:
export QWEN_VLLM_API_KEY="$(< ~/.config/qwen-vllm/api-key)"
codex --profile qwen-vllm
Codex documentation also says that project-level .codex/config.toml cannot override model_provider or model_providers. Put the provider in user configuration or a separate profile file. A valid table in the wrong configuration layer then appears to be a broken provider.
A five-minute gate before repository access
Once the model is running, check the HTTP layer first:
curl -fsS http://127.0.0.1:18020/health
curl -fsS \
-H "Authorization: Bearer $QWEN_VLLM_API_KEY" \
http://127.0.0.1:18020/v1/models
Then launch the profile in an empty disposable repository and use exactly this task:
Createresult.jsonwithsource: "codex-qwen-smoke"andok: true. Validate it withjq -e '.source == "codex-qwen-smoke" and .ok == true' result.json. Change no other files.
This small task checks five pieces together: a Responses response, a tool call, a file write, a command result and clean session completion. Our runs for this class of task took about 33–113 seconds. If the check exceeds five minutes, stop it and inspect transport or an agent loop. That delay should not be treated as normal for a short integration check.
In the same session, ask the agent to change source to codex-qwen-resume and validate again. A new turn can work while history resume is broken.
Two failures we actually saw
Wrong key. Using the old llama.cpp server key with vLLM returned HTTP 401. The run handler initially risked treating the textual API message as a task result. We changed it so a provider error marks the run as an integration failure and excludes it from model-quality scoring.
Session resume. In the llama.cpp profile, a new Codex turn worked but a resumed session failed with System message must be at the beginning. Codex placed a later developer message in the history, while the Qwen template accepted system content only at the front. The corrected template collects system and developer messages in the leading block. We separately checked a new turn, a system,user,assistant,developer,user history and a resume returning resumed-ok.
/health checks server availability. It does not check the complete client, tool and session-history integration.
The Codex result in the home experiment
On patched vLLM with a 150,000-token context and medium effort, running on a home RTX 3090, we recorded:
| Measure | Codex | Qwen Code |
|---|---|---|
| Score under Syntalith's criteria | 87/100 | 100/100 |
| Elapsed run time | 1,150.42 s | 502.14 s |
| Context compactions | 1 | 0 |
| Tool calls | 56 shell calls | 52 tool calls |
The 87/100 score reflected a material defect found during review. Codex built the project, passed focused tests and wrote documentation, but a fallback described as deterministic could print a memory address for a pointer or channel. Its tests covered easier cases and missed that property. The 100/100 score means Codex deducted no points from the Qwen Code patch under these criteria in this one run. Neither score establishes repeatability or general model reliability.
On a small import task, Codex passed 5/5 hidden checks while Qwen Code missed one validation. That result came from a different task and does not change the long-repair score. The task set and its checks should determine which client to use.
A slimmer Codex profile
The full client environment carried many instructions and skill descriptions. An isolated codex-qwen-vllm-slim profile reduced measured input bytes from 19,748 to 10,573, a 46.5% reduction.
That figure describes instruction footprint alone. It is not a quality or whole-run timing measure. Shorter instructions may lower cost and leave more context for code, while also removing a needed procedure. Call the profile better only after a new task with hidden checks.
Safe operating pattern
- Use a separate Codex profile and leave the normal provider unchanged.
- Store the local key in a mode-
0600file. - Start in a disposable worktree.
- Exclude deployment commands and secrets.
- Set a context limit that matches the server.
- Independently test tool shape and session resume.
- Keep a tested profile or approved API as fallback.
- Re-run the smoke test after every Codex, vLLM or chat-template update.
The home RTX 3090 was a test bench. Syntalith's offer covers configuration, concrete test cases, permission controls, failure documentation and team training. The AI-Native course teaches teams to separate client, model and protocol. A free process scan helps determine whether a local profile makes sense and which checks it must pass.
Free process scan
Start with a free process scan.
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
The scan chooses one process to assess, and within 2 business days you receive a recommendation, including when a simpler route is the better fit.
€0
30 minutes · written takeaway within 2 business days
Times are shown in your own time zone. We work with clients across time zones.
Describe the process in the form