12 Sep 2026model-ops

Use QwenCloud with Codex CLI without the 401

We hit a simple problem: Paperclip/Codex accepted a QwenCloud key as a secret, but Codex still called api.openai.com/v1/responses. The key failed with a 401 because it was being sent to OpenAI, not Qwen.

Diagram showing Codex using a custom config.toml provider to reach DashScope instead of api.openai.com — One provider is only compatible when base URL, auth, model, and wire API all line up.

The fix was not another env var. Codex needed a custom provider in $CODEX_HOME/config.toml.

model = "qwen3.8-max"
model_provider = "qwencloud"

[model_providers.qwencloud]
name = "QwenCloud DashScope"
base_url = "https://dashscope-intl.aliyuncs.com/compatible-mode/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

Why this matters

Many tools say “OpenAI-compatible,” but still hard-code the OpenAI base URL or the Responses transport. A provider is only compatible when the base URL, auth header, model name, and wire API all line up.

Quick checks

Chat Completions worked: /compatible-mode/v1/chat/completions
Responses worked too: /compatible-mode/v1/responses
Anthropic-compatible endpoint also worked for Claude-style tooling.

Once the custom provider existed, the Qwen-backed agent completed the task and commented OK QWEN TEST.

No Monkey Business installs and operates sovereign/local AI infrastructure. If this problem sounds familiar, book a 30-minute assessment.