Qwen Code 1.0 Preview Merges Qoder and Qwen Code Into One Open-Source Agent With Native Packages

Qwen Code’s 1.0 line has arrived as a pre-release, and it is a different kind of release than the busy v0.27.x channel. Where v0.27.2 added WeChat, QQ and Email channels to the managed-agent surface, Qwen Code 1.0 Preview consolidates the product itself: the agent capabilities of Qoder and Qwen Code are being brought together into a single open-source coding agent, distributed as native packages for macOS, Linux and Windows that do not require a separate Node.js installation.

The GitHub releases page now lists v1.0.0-preview as the newest pre-release, ahead of the v0.27.2 stable line released a day earlier, which signals that 1.0 is where the project’s interface work is heading. The release notes carry an explicit caveat: some interfaces, configuration options and behaviors may change during Preview. Treat this as a parallel track to evaluate, not a drop-in upgrade to your v0.27 workflow.

What actually changed

Three capabilities in the 1.0 Preview matter for working developers:

1. One merged agent. Code understanding, implementation, debugging and testing come from a single harness that combines Qoder’s agent work with Qwen Code’s terminal agent, instead of two tools with overlapping jobs.
2. Native packages, no Node.js runtime dependency. The release ships operating-system and architecture-specific binaries, so installation no longer starts with npm install -g or a Node version check. That removes a whole class of environment friction for teams distributing a coding agent across mixed machine fleets.
3. Resumable and scriptable sessions. Session resumption and non-interactive execution are first-class, aimed at ongoing development, scripting and automation rather than only interactive chat.

The multi-provider story carries over: the release notes confirm support for Qwen and Qoder accounts, multiple model providers and custom compatible endpoints. The project overview documentation shows what that looks like at first launch — a provider menu offering a Qwen account subscription, QwenCloud keys, Alibaba ModelStudio, built-in third-party providers such as DeepSeek, MiniMax, Z.AI, Kimi and OpenRouter, and a fully custom provider slot for local servers or proxies.

Install and first run

The documented installer uses a standalone archive when one exists for your platform, falling back to npm only when it does not:

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

# Windows PowerShell
irm https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.ps1 | iex

After installation, cd into a project and run qwen. First launch prompts you to connect a provider, after which you can start with codebase questions like what does this project do?. The docs recommend restarting your terminal if qwen is not immediately on PATH, and for offline installs, downloading a release archive and running the installer with --archive PATH while keeping the SHA256SUMS file next to the archive — a habit worth keeping for any binary agent you distribute to a fleet.

Why the native package matters more than the version number

For operators, the Node.js removal is the consequential change. Node-version drift, native module rebuilds and npm-global permission issues are recurring failure points when rolling a coding CLI out to a team. A standalone binary with published checksums turns agent distribution into ordinary software packaging: pin the archive, verify the hash, ship it through the same channel as everything else on the machine. That also simplifies running the agent in CI and on build runners where you control the base image but not the Node toolchain.

Session resumption plus non-interactive execution extends the same idea. The Qwen Code docs already describe the composable pattern — piping logs into qwen -p or having CI run a one-shot prompt — and a 1.0 harness that treats resumable, scriptable sessions as core behavior makes that pattern reliable enough to build automation on. Combined with the custom-endpoint slot, it positions Qwen Code 1.0 as an open-source harness you can point at your own model gateway rather than a vendor-locked client. Readers weighing that trade-off may want the broader landscape in our guide to open-source coding agents.

What to do this week

• Evaluate, don’t migrate. Install the Preview in a scratch project, connect a non-production provider key, and run a representative task. Interfaces and behaviors may change, so keep v0.27.2 as the stable lane.
• Verify the archive. If you install offline, check the SHA256SUMS file against the downloaded package before running the installer, and record which archive version each machine carries.
• Test the automation surface. Try a non-interactive run with qwen -p in a throwaway CI job and confirm session resumption works across a machine restart — those two features are the reason to care about 1.0.
• Watch the provider menu. If your organization routes models through a gateway, test the custom provider path early, since endpoint dialect differences are where multi-provider CLIs usually bite.

Qwen Code 1.0 Preview is not yet a stability story; the merged harness, native packages and scriptable sessions, though, are exactly the changes that decide whether an open-source coding agent is practical to standardize on. The Preview label means the contract can still move — the architecture question it answers is the one worth tracking.