Skip to content
Back to blog
codexArticle

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.

Author

Syntalith

Published Updated 4 min read

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:

Create result.json with source: "codex-qwen-smoke" and ok: true. Validate it with jq -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:

MeasureCodexQwen Code
Score under Syntalith's criteria87/100100/100
Elapsed run time1,150.42 s502.14 s
Context compactions10
Tool calls56 shell calls52 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

  1. Use a separate Codex profile and leave the normal provider unchanged.
  2. Store the local key in a mode-0600 file.
  3. Start in a disposable worktree.
  4. Exclude deployment commands and secrets.
  5. Set a context limit that matches the server.
  6. Independently test tool shape and session resume.
  7. Keep a tested profile or approved API as fallback.
  8. 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

Book a free process scan (30 min)

Times are shown in your own time zone. We work with clients across time zones.

Describe the process in the form