Qwen Code Config Generator

Qwen Code config generator: point ~/.qwen/settings.json at Model Studio, OpenRouter or a local model

Qwen Code is an OpenAI-compatible agent, which is both its best feature and the reason its configuration confuses people. There is no proprietary auth flow — you tell it a base URL, a model name, and where to find an API key, and it works against Alibaba's Model Studio, against OpenRouter, or against a model running on your own laptop through Ollama or LM Studio. This generator is a provider-wiring tool: pick where the model lives and it writes a valid ~/.qwen/settings.json, plus the equivalent shell exports if you would rather not keep a settings file at all.

It is deliberately narrow. There is one form group — Provider — with three controls, and two output files. There is no permission model to configure, no MCP picker, and no context-file tab, so unlike the Claude Code, Codex and Gemini generators there is no AI assist panel anywhere in this tool. Everything it produces is deterministic string assembly, computed in your browser with no network call.

Install

One command, shown with a copy button at the top of the tool:

npm install -g @qwen-code/qwen-code

That is the whole prerequisite for the hosted providers. For the two local options you also need the runtime itself installed and serving before Qwen Code can reach it. Run the CLI once so it creates ~/.qwen, or create the directory yourself before saving either output file into it.

The seven provider choices, and the base URL each one writes

The three Model Studio rows are the same service in three regions, and the hostname is the only difference: dashscope-intl, dashscope, dashscope-us. Pick the region your account was created in — a key issued in one region will not authenticate against another, and the resulting error looks like a bad key rather than a wrong endpoint. All three end in /compatible-mode/v1, which is the OpenAI-compatible path rather than DashScope's native API; using the native path here will not work.

The model name field is optional. Leave it blank and the provider's default from the table above is used. Fill it in and it overrides. The one syntax difference worth remembering is OpenRouter, which namespaces models as provider/model with an optional :tag — hence the default qwen/qwen3-coder:free. Model Studio and local runtimes take a bare model name.

Inside the generated settings.json

The structure is more layered than a flat settings file, so it is worth reading once. For Model Studio International with defaults, the output is:

{ "modelProviders": { "openai": [ { "id": "qwen3-coder-plus", "baseUrl": "https://dashscope-intl.aliyuncs.com/compatible-mode/v1", "envKey": "OPENAI_API_KEY" } ] }, "env": { "OPENAI_API_KEY": "your-key-here" }, "security": { "auth": { "selectedType": "openai" } }, "model": { "name": "qwen3-coder-plus" } }

Four blocks, each doing one job:

• modelProviders — keyed by provider protocol, not by vendor. The valid keys are openai, anthropic and gemini; this generator always uses openai, because the OpenAI-compatible path is what every option in the picker speaks, including the local ones. Inside is an array of entries, each with an id (the model), a baseUrl, and an envKey.
• envKey — the name of the environment variable holding the real key, not the key itself. It is always OPENAI_API_KEY here.
• security.auth.selectedType — tells Qwen Code which auth path to actually use. Set to openai to match the provider block. If you add a second provider by hand, this is the switch that selects between them.
• model.name — the active model, matching the id above.

The duplication between modelProviders[].id and model.name is not a bug in the output: the first declares a provider entry, the second selects which one is live. They match because there is one entry. Add a second entry for a cheaper model and you switch between them by changing model.name alone.

The key placeholder is the one thing you must edit

The generated env block contains a literal placeholder. For hosted providers it is "your-key-here"; for Ollama and LM Studio it is "local". Two practical consequences:

For hosted providers, this file will not work until you replace the placeholder, and once you do it contains a live credential. Do not commit ~/.qwen/settings.json to a dotfiles repository after that edit. If you want a committable config, delete the env block entirely and export OPENAI_API_KEY in your shell instead — the envKey field already points there, which is precisely what it is for.

For Ollama and LM Studio the placeholder is the answer. Local OpenAI-compatible servers do not authenticate, but the OpenAI client libraries refuse to send a request with an empty key, so any non-empty string satisfies them. local is as good as anything.

The .env tab: skipping settings.json entirely

The second tab writes three shell exports that reach the same result without a settings file:

export OPENAI_API_KEY="your-key-here"
export OPENAI_BASE_URL="https://dashscope-intl.aliyuncs.com/compatible-mode/v1"
export OPENAI_MODEL="qwen3-coder-plus"

Qwen Code reads these OpenAI-compatible variables directly. The tab is labelled for ~/.qwen/.env, but the same three lines work pasted into a shell, added to .zshrc, or set as environment variables in a container. This route is usually better for CI and for containers — no file to bake into an image, and the secret arrives through the same mechanism as every other secret in the pipeline.

Use one or the other, not both. If a settings file and the environment disagree about the base URL, you will spend a while wondering why a change had no effect.

Worked example: a free local setup

Pick "Local — Ollama" and leave the model field blank. The settings tab produces a modelProviders.openai entry with baseUrl http://localhost:11434/v1, id qwen3-coder:30b, and an env block with OPENAI_API_KEY set to local. Pull the model with ollama pull qwen3-coder:30b first — Qwen Code will not fetch it for you, and a model that is not present returns a not-found error from Ollama that reads as a configuration failure.

The /v1 suffix on the local URL is mandatory. Ollama serves its own native API at the root and the OpenAI-compatible surface under /v1; omitting it is the single most common local-setup mistake. LM Studio behaves the same way on port 1234.

Custom endpoints

Selecting "Custom OpenAI-compatible endpoint" reveals a base URL field, hidden otherwise. Anything that speaks the OpenAI chat-completions protocol fits: a vLLM server, a corporate LLM gateway, an inference proxy, a self-hosted router. The field's own help text states the rule — it must end in /v1. Leave it blank and the generator writes the obvious placeholder https://your-endpoint/v1 so the file stays syntactically valid while you find the real one.

Which provider is the right one for you

The picker's seven rows collapse into three genuinely different decisions.

• Alibaba Model Studio is the first-party route to the Qwen models the agent is named after. It gives you the largest coder models without local hardware, and the only real configuration risk is choosing the wrong regional hostname. Pick this when you want the strongest Qwen model with the least setup.
• OpenRouter is an aggregator, so one key reaches many models. It is the easiest way to try Qwen Code without creating an account with Alibaba, and the generator's default qwen/qwen3-coder:free lets you evaluate the agent at no cost. Because it is a router, expect the provider/model naming and a wider set of models than the picker's defaults suggest.
• Local — Ollama or LM Studio keeps every prompt on your machine. No key, no per-token cost, no data leaving the laptop. The trade is model size against your available memory, which is why the generator's defaults differ between the two: qwen3-coder:30b for Ollama and the smaller qwen2.5-coder-14b for LM Studio. Both are starting points, not requirements — type any model you have pulled into the model field.

Because every one of these speaks the same OpenAI-compatible protocol, switching is cheap: change the base URL and the model name and nothing else in your workflow moves. That portability is the actual argument for configuring Qwen Code this way rather than through a vendor-specific login, and it is why the .env tab is a first-class option rather than an afterthought — three environment variables are all that distinguish a local free setup from a hosted one.

Errors you will hit wiring up a provider

• 401 or invalid key against Model Studio. Usually a region mismatch rather than a bad key. Confirm the hostname matches the region your account belongs to.
• Connection refused on localhost. The runtime is not running, or is on the other port. Ollama defaults to 11434, LM Studio to 1234.
• 404 on every request to a local model. The /v1 suffix is missing from the base URL.
• Model not found. On OpenRouter, check the provider/model namespacing. On Ollama, check ollama list — the model has to be pulled first.
• An edit had no effect. Environment variables and a settings file are both in play. Pick one source of truth.
• The key got committed. The generated env block holds a literal string. Strip it and rely on envKey plus a shell export for anything you version-control.

Both tabs have copy and download buttons, and Reset restores the defaults. If you are configuring the Ollama side of a local setup rather than the Qwen Code side — Modelfiles, context length, server tuning — the Ollama config generator covers that half.