IntegrationsDev tool
Qwen Code
三个环境变量、或 settings.json 里一条 provider，就能让 Qwen Code 走 RouteMux。
Qwen Code 讲四种协议，靠 auth type 选其中一个。走 OpenAI 兼容这条路接 RouteMux 最短。
环境变量
export OPENAI_API_KEY="sk-..." # 你的 RouteMux key
export OPENAI_BASE_URL="https://api.routemux.com/v1"
export OPENAI_MODEL="openai/gpt-5.5" # 别名:QWEN_MODEL然后在项目里跑 qwen。是 OPENAI_API_KEY 这个变量本身选中了 OpenAI 兼容的 auth type ——
只导出某个厂商专用的 key 变量是不够的。
或者在 settings.json 里定义 provider
放用户级的 ~/.qwen/settings.json，官方建议如此以避免合并冲突：
{
"modelProviders": [
{
"id": "routemux",
"name": "RouteMux",
"baseUrl": "https://api.routemux.com/v1",
"envKey": "ROUTEMUX_API_KEY"
}
],
"security": { "auth": { "selectedType": "openai" } },
"model": { "name": "routemux" }
}model.name 必须与某个 provider 的 id 一致。这样存好之后，qwen 启动不再需要走交互式
/auth。进到 CLI 里，/model 可以在已配置的模型之间切换（按协议分组），/doctor 会打印
解析出来的 auth 状态。
key 从哪来，优先级从高到低
- 命令行参数如
--openai-api-key—— 永远最高 - shell 环境变量
.env文件 —— 只写入环境里还没有的变量settings.json的env—— 最低，而且是明文存 key
只读第一个 .env
Qwen Code 只加载它找到的第一个 .env，不跨文件合并。它从当前目录向上走，
依次看 .qwen/.env 再看 .env，都没有就回落到 ~/.qwen/.env 再 ~/.env。
项目级的密钥放 .qwen/.env —— 不会和别的工具撞，也容易排除在版本控制外。
其他协议
/auth → Custom Provider 也能接 Anthropic、Gemini 及其他兼容端点。
要用 Claude 模型就得走这条：它们在这里只在 Anthropic Messages 上提供，
而且 base URL 的约定不同 —— 见兼容矩阵。
验证
curl https://api.routemux.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"openai/gpt-5.5","messages":[{"role":"user","content":"ping"}]}'排查
| 现象 | 原因 |
|---|---|
| 选中了错误的 auth type | 导出的是某个厂商专用的 key 变量，而不是 OPENAI_API_KEY。 |
| 改了 key 没反应 | 优先级更高的东西盖住了 —— 命令行参数、或者已经 export 过的 shell 变量会压过 .env。 |
第二个 .env 里的变量不生效 | 只读找到的第一个文件，不合并。 |
| 每条请求都 404 | OPENAI_BASE_URL 漏了 /v1。 |
400 MODEL_PROTOCOL_UNSUPPORTED | 在 OpenAI 兼容 auth type 下用了 Claude 模型。改用走 Anthropic 协议的 Custom Provider。 |
| 模型被拒 | id 与 GET /v1/models 不一致。 |
422 BILLING_INSUFFICIENT_CREDITS | 钱包余额不足。失败请求不计费。 |