Qwen Code: Terminal AI Coding Agent with Multi-Protocol Provider Support

Qwen Code's scope: from terminal sessions to chat channels

Qwen Code is a terminal-based AI coding agent that also runs as a desktop application, an IDE extension for VS Code, Zed, and JetBrains editors, a browser-based web UI, and as a bot connected to Telegram, DingTalk, WeChat, and Feishu. The README describes it as "agentic out of the box," meaning it ships with Auto-Memory, Auto-Skills, SubAgents, Agent Teams, and Model Context Protocol support without requiring manual configuration to enable those features.

The intended user is a developer who wants LLM-powered assistance during coding but wants freedom over which model or provider handles the requests. That includes developers who need to switch between cloud providers based on cost or capability, and those who cannot send code to external APIs at all and must run models locally.

The project is written in TypeScript, requires Node.js 22 or later, and is distributed under the Apache-2.0 licence. The repository's package.json shows the current version as 0.24.6, with releases tracked in a CHANGELOG.md file. The README states that the project uses its own agent and models internally to file issues, submit pull requests, review code, and run tests, which the team treats as a development objective, not just a feature.

Multi-protocol switching and local model support

The central constraint in most AI coding tools is that the provider is fixed at installation time. Qwen Code separates the agent runtime from the provider. The README lists OpenAI, Anthropic, Gemini, and Qwen as directly supported API protocols. It also explicitly documents third-party providers and local models running via Ollama or vLLM as supported options.

Inside a running session, the /auth command is the entry point for configuring the provider and API key. The README points to the project's Authentication Guide and Settings Reference for detailed setup, but /auth is the in-session path. Switching providers does not require restarting the agent or editing a configuration file before launch.

This separation is particularly useful for developers who want cost control. Low-complexity queries can go to a cheaper or local model, while a cloud API handles harder tasks. The README does not document whether provider routing happens automatically or requires manual session commands each time. That detail is in the Settings Reference, not the README.

For local model use, both Ollama and vLLM are named as supported integrations. A local model setup eliminates cloud API costs, but performance depends entirely on the hardware running the model. Qwen Code does not document minimum hardware requirements for local inference.

Installing Qwen Code and starting a first session

Qwen Code offers three installation paths. On Linux and macOS, the standalone installer runs as a single shell command:

curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash

The README states that restarting the terminal after installation is necessary for environment variables to take effect. The Windows equivalent is a PowerShell script hosted at the same domain.

For users who prefer a package manager, npm is available. This path requires Node.js 22 or later to be installed first:

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

Homebrew is also an option on macOS and Linux:

brew install qwen-code

Once installed, navigate to a project directory and start the agent:

qwen

Inside the session, run /auth to configure the provider. The README's Quick Start suggests asking the agent to explain the repository and show where to start as a first task. The session runs interactively until the user exits.

Desktop app, IDE plugins, and chat channel integrations

Beyond the terminal, Qwen Code ships a desktop application for macOS, Windows, and Linux. The README links to a desktop-latest release tag in the repository's releases page. The desktop app is a separate download, not part of the npm or Homebrew install.

IDE integrations for VS Code, Zed, and JetBrains are documented in the project's documentation site. These add the agent to the editor environment rather than requiring a separate terminal window, though the README does not describe how the IDE integrations differ in capability from the terminal version.

The chat channel integrations use a dedicated command to activate the bot connection:

qwen channel start

The README lists Telegram, DingTalk, WeChat, and Feishu as supported channels, each with its own setup guide in the documentation.

The web UI mode starts with:

qwen serve --open

This opens a browser-based interface. The README marks this mode as experimental. The same `qwen serve` command without the --open flag starts the agent as a daemon that accepts connections from clients over HTTP and Server-Sent Events using the ACP protocol. This daemon mode is also experimental.

Headless mode and the Python, TypeScript, and Java SDKs

For automation, Qwen Code accepts a prompt directly on the command line without opening an interactive session:

qwen -p "..."

The README describes this as suitable for scripts, CI/CD pipelines, and batch jobs. The agent processes the prompt and exits.

The project ships three SDKs for programmatic access: TypeScript, Python, and Java. The Python SDK example in the README shows how to query the agent and iterate over the response stream:

import asyncio
from qwen_code_sdk import is_sdk_result_message, query
async def main() -> None:
    result = query(
        "Summarize the repository layout.",
        {
            "cwd": "/path/to/project",
            "path_to_qwen_executable": "qwen",
        },
    )
    async for message in result:
        if is_sdk_result_message(message):
            print(message["result"])
asyncio.run(main())

The SDK starts the qwen executable locally and streams results back. The cwd key sets the working directory for the agent session, and path_to_qwen_executable names the binary to invoke. The TypeScript and Java SDKs follow the same pattern, with their own README files in the packages/ directory of the repository.

Limitations and where Qwen Code is the wrong choice

Node.js 22 is a hard requirement. Environments where Node.js cannot be upgraded to version 22, such as certain enterprise systems or CI runners locked to an older Node.js version, cannot run Qwen Code without infrastructure changes.

The web UI and daemon mode are both experimental in the current release. The README labels them explicitly as experimental and provides no timeline for stabilization. Building production workflows around these interfaces carries risk until that label is removed.

The repository includes a Dockerfile using a digest-pinned node:22-slim base image, which is appropriate for containerized deployments. The Docker build process runs QWEN_SKIP_PREPARE=1 corepack pnpm install followed by build and bundle steps. Teams who need a container-based deployment have a supported path, but the Dockerfile requires a full source build rather than pulling a pre-built image.

The README draws a direct comparison to Claude Code, stating that if you know Claude Code, you already know Qwen Code. Claude Code is Anthropic's own terminal AI agent, and it targets developers using the Anthropic API exclusively. The practical difference is scope: Qwen Code adds multi-provider routing, local model support, and a wider range of interface modes. Claude Code is simpler to configure and audit when a single Anthropic API key is all that is needed. Qwen Code is the appropriate choice when provider flexibility or local model operation is a requirement, not a nice-to-have.

Editorial conclusion

Developers who need a terminal AI coding agent that can switch between Alibaba Qwen, OpenAI, Anthropic, and Gemini APIs, or route requests to a local model through Ollama or vLLM, will find Qwen Code well-matched to that use case. Teams on Windows should confirm that the PowerShell installer from qwen-code-assets.oss-cn-hangzhou.aliyuncs.com finishes without error and that the qwen command appears in PATH after the required terminal restart. Anyone planning to rely on the web UI or the daemon should treat those components as experimental until the project marks them stable.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes