Connect Qwen Code to Router One with one .qwen/.env file or a modelProviders entry

Install Qwen Code and create a dedicated key

The npm install needs Node.js 22 or newer; the README also lists a standalone install script for Linux, macOS and Windows and a Homebrew formula. Install, open a terminal in the project and start qwen. The first run opens the /auth menu, whose Custom Provider option covers OpenAI-compatible endpoints, but the two files in this guide configure the same thing without the menu; /doctor shows the authentication and environment checks at any time. Before that, create a Router One key for Qwen Code alone with a maxSpend cap: an agent session sends one request per model turn and per tool-result continuation, so the cap is the hard stop. The key goes into .qwen/.env below, never into settings.json.

npm install -g @qwen-code/qwen-code@latest
cd /path/to/your-project
qwen

Configure Qwen Code to use the Router One base URL

Create .qwen/.env in the project root with the three variables below; it is the file the Qwen Code docs prefer for project-local secrets, and it must stay out of git. OPENAI_API_KEY is the Router One key, and the authentication docs state that exporting OPENAI_API_KEY is what selects OpenAI-compatible auth from environment variables alone; provider-specific variable names do not. OPENAI_BASE_URL takes https://api.router.one/v1 with /v1: the openai auth type builds an official OpenAI Node.js SDK client from this value, and the SDK posts to /chat/completions relative to it, so each model turn is one POST /v1/chat/completions. OPENAI_MODEL (alias QWEN_MODEL) is the exact catalog ID and becomes the model field of every request; --model <id> overrides it for one session. Qwen Code loads only the first .env file it finds, .qwen/.env then .env walking up from the current directory, then ~/.qwen/.env and ~/.env, and it never overwrites a variable already exported in the shell, so a stale OPENAI_BASE_URL in ~/.zshrc wins over this file. This form creates what the docs call a Runtime Model: one model and no picker entries; if qwen still opens the /auth menu, add security.auth.selectedType as in the next section. Start qwen, run /doctor, send one short prompt, and match its trace in Logs. The file, with the key and the model ID replaced:

# <project>/.qwen/.env — the first .env file Qwen Code finds; keep it out of git
OPENAI_API_KEY=sk-your-router-one-key
OPENAI_BASE_URL=https://api.router.one/v1
OPENAI_MODEL=<exact-model-id-from-/models>

Register Router One in modelProviders for the /model picker

To switch between several catalog models inside a session, declare them in ~/.qwen/settings.json, the user scope the docs recommend, because project settings replace the whole modelProviders object instead of merging it. The key openai is the auth type and fixes the transport; a misspelled key such as openai-custom is skipped with a warning and its models never appear in /model. Each entry needs id, the exact catalog ID sent as the model field; name is only the picker label; envKey names the environment variable that holds the key, since the runtime reads process.env[envKey] and never stores the credential, so put ROUTER_ONE_API_KEY=sk-your-router-one-key in .qwen/.env or ~/.qwen/.env, or export it; baseUrl is the same /v1 URL, and within one auth type entries are identified by id plus baseUrl, so a duplicate pair is skipped. generationConfig is optional and sealed: when a provider model is selected its values apply atomically and top-level model.generationConfig is ignored; in the source, timeout defaults to 120000 ms and maxRetries to 3. security.auth.selectedType set to openai starts qwen without the /auth menu, and model.name must equal one of the ids. A running session picks up edits to modelProviders (reopen /model), and /model and /auth write model.name and selectedType back to the scope that defines modelProviders. When a provider entry is selected, its baseUrl and envKey outrank --openai-base-url, OPENAI_BASE_URL and OPENAI_API_KEY.

{
  "modelProviders": {
    "openai": [
      {
        "id": "<exact-model-id-from-/models>",
        "name": "<label shown in /model>",
        "envKey": "ROUTER_ONE_API_KEY",
        "baseUrl": "https://api.router.one/v1",
        "generationConfig": { "timeout": 120000, "maxRetries": 3 }
      },
      {
        "id": "<another-model-id-from-/models>",
        "envKey": "ROUTER_ONE_API_KEY",
        "baseUrl": "https://api.router.one/v1"
      }
    ]
  },
  "security": { "auth": { "selectedType": "openai" } },
  "model": { "name": "<exact-model-id-from-/models>" }
}

Which value goes where, and how to verify it

Everything Router One needs is three variables or one provider entry; the rows below give each value and the check that proves it took effect. The quickest view of the actual request is Qwen Code's own log: model.enableOpenAILogging, or the --openai-logging flag, writes each request and response as JSON under logs/openai in the working directory.

Budget a Qwen Code session and reconcile it with Logs

One prompt in Qwen Code is rarely one request. Each model turn is a request, every tool result the agent feeds back is another turn, model.maxToolCallsPerTurn caps a turn at 100 tool calls by default, adaptively, with a hard backstop of 1000, and side models chosen with /model --fast, --compaction or --vision send their own requests. The openai transport also passes timeout (default 120000 ms) and maxRetries (default 3) to the OpenAI SDK, and every attempt that reaches the gateway is its own request with its own request_id and charge. Give Qwen Code a dedicated key with maxSpend: a session that hits the cap gets HTTP 402 and stops, while the wallet and other keys are untouched. Client-side, model.maxSessionTurns and model.sessionTokenLimit bound the conversation, and a stream the client cancels is recorded as HTTP 499 client_cancelled and billed only for the usage reported. Reconcile with /stats model, which shows Qwen Code's per-model token breakdown and its own cost estimate; Dashboard → Logs is the charge, per request, with model, tokens, cost, latency, status and request_id, and /stats export writes the client side to CSV or JSON. Router One records model-call metadata only; tools, approvals, sessions and subagents run in Qwen Code.

Which model ID should Qwen Code send?

Copy the exact model ID from /models, preserving case, hyphens, and version suffixes; do not substitute a display name. Open its detail page and match the supported API endpoints, context window, and capabilities such as tool calling to the provider and features selected in Qwen Code. A catalog listing does not mean the client can use every feature of that model. Give each tool a dedicated API key with a maxSpend cap.

Which API protocol is Qwen Code using?

OpenAI-compatible describes an interface format; it does not make Chat Completions (/v1/chat/completions), Responses (/v1/responses), and Anthropic Messages (/v1/messages) interchangeable. Check the installed client version, provider configuration, and actual request path against the model detail page and API compatibility fact sheet. A successful plain-text chat does not establish support for hosted tools, conversation state, or file-editing features.

Verify the Qwen Code call in your request trace

Send a simple text request from Qwen Code, then match its trace in Dashboard → Logs by time, model, and request_id: tokens, cost, latency, and status. Next, test streaming, tool calls, and multi-turn history separately. For failures, retain the actual request path, full error message, and request_id. If there is no matching log, check client configuration and connectivity before attributing the error to the gateway or upstream.

FAQ