Harness composition
Qwen Live voice control plane
Qwen Live is an incubating standalone voice control plane for Qwen Code sessions. Its current merged implementation uses Qwen Code as the backend; broader ACP and multi-harness adapters remain roadmap work.
Status first
Section titled “Status first”Qwen Code pull request #10367, merged on 1 September 2026 at commit 8290c81e, adds packages/qwen-live: an independently versioned standalone voice daemon that extracts the Live voice-control loop from the qwen serve process. The package metadata on current Qwen Code main identifies @qwen-code/qwen-live version 0.1.0 and describes it as a realtime voice control plane that orchestrates Qwen Code sessions.
This is merged upstream source, not a verified package-registry release. The package is explicitly incubating and excluded from the Qwen Code CLI’s lockstep release train. The upstream pull request describes #10367 as the first shippable M1+M2 step of the Live split roadmap; later roadmap stages remain separate work.
Architecture
Section titled “Architecture”The merged M1+M2 architecture separates the voice front end from the coding-agent backend:
- Live Host ↔ Qwen Live: the daemon speaks the existing Live Host WebSocket protocol v6 and publishes the same discovery file at
~/.qwen/live/daemon.json, so the already-published Live Host application can connect without a protocol migration. - Realtime voice: Qwen Live starts with the DashScope
qwen-omnirealtime API for speech interaction. - Qwen Code backend:
QwenCodeAdaptordrives a runningqwen servedaemon through the TypeScript SDK over REST/SSE. Prompt admission, session events, steering, permission voting and image attachments cross that backend boundary. - Decoupled lifetimes: the Live session owns the realtime conversation and its own JSONL log; coding sessions are managed resources rather than being the same session object as the voice conversation.
That separation is the important architectural change. The voice interaction loop can evolve on its own lifecycle and package cadence rather than remaining embedded inside the Qwen Code CLI process.
Seven receipt-style control tools
Section titled “Seven receipt-style control tools”The voice model receives seven orchestration tools:
| Tool | Role |
|---|---|
handoff | Send work or a follow-up instruction to a managed coding session. |
session_list | Enumerate sessions visible through the current backend adaptor. |
session_create | Create a backend session and return a handle. |
session_monitor | Request current task/session progress. |
session_stop | Stop managed work. |
respond_permission | Relay a user permission decision to the backend session. |
appshot | Request a Host-side application screenshot through the capture channel. |
The tools are deliberately receipt-oriented. Completion, progress, errors and permission requests return through a separate injector instead of forcing the model to synchronously wait for every backend operation. The dispatcher answers every call, including a pending receipt on timeout while the underlying operation continues, so a delayed operation is not automatically retried as a second command.
Result injection, interruption and steering
Section titled “Result injection, interruption and steering”Backend events are fed into the live conversation through an injector that waits for a safe insertion window. It accounts for voice activity, an in-flight realtime response and estimated playback, batches related items, throttles progress and drops stale progress when the user barges in. Permission items are prioritized ahead of ordinary context so a blocked backend does not lose its authorization request behind status chatter.
Mid-task instructions use the backend capability that is actually available. The Qwen adaptor can steer an admitted running prompt when the daemon accepts mid-turn input; otherwise it falls back to a queued prompt rather than pretending that a live steering operation succeeded. The pull request also records the daemon-issued client identifier per session after the end-to-end tests caught a real registration/correlation failure caused by using a self-generated identifier.
Permission boundary
Section titled “Permission boundary”Qwen Live turns backend permission requests into spoken questions and returns the user’s choice through respond_permission. The merged implementation classifies structured permission-option kinds and selects the least-escalating matching allow option. Its local allow_always experience is implemented as a one-shot backend vote backed by a local TTL rule narrowed to the exact normalized command; it is not a new permanent permission primitive in qwen serve.
If local automatic approval fails, the request falls back to the spoken ask instead of disappearing. Remote resolutions retract queued asks, and adopted sessions retain vote attribution. These details matter because a voice control plane can otherwise become an authority-confusion layer between the human and the coding harness.
BackendAdaptor is a seam, not yet multi-harness support
Section titled “BackendAdaptor is a seam, not yet multi-harness support”The new BackendAdaptor interface is intentionally capability-driven so the voice loop does not need to know every backend’s transport. The merged M1+M2 implementation provides QwenCodeAdaptor. The project roadmap proposes later support for terminal-owned Qwen sessions and an AcpAdaptor for non-Qwen agents, with capability-based degradation for products such as Claude, Codex or Gemini.
Those later stages are not shipped by #10367. The upstream roadmap still places cross-session aggregation in M3, generalized ACP/multi-harness support in M4, and protocol-v7/legacy-Live retirement work in M5. It would therefore be inaccurate to describe Qwen Live 0.1.0 source as a universal voice harness router today.
Validation and current limits
Section titled “Validation and current limits”The PR reports 167 package unit tests and 11 end-to-end tests. The end-to-end stack uses a real spawned qwen serve daemon, a fake OpenAI-compatible model endpoint, a scripted fake DashScope realtime WebSocket server, the Qwen Live daemon as a child process, and a protocol-v6 fake Host client. The scenarios exercise discovery, session startup, two-way audio, handoff and result return, safe injection, permission relay and steering.
The reported end-to-end environment is Linux with Node.js 22. macOS and Windows manual Host smoke tests were not reported as completed. The Host protocol implementation is currently ported into the new package rather than shared with the built-in CLI implementation, so the upstream PR explicitly identifies protocol-copy drift as a temporary risk. Protocol v6 also estimates playback timing; a later v7 receipt is planned rather than already present.
Relationship to UHP and HarnessRouter
Section titled “Relationship to UHP and HarnessRouter”Qwen Live and UHP address different boundaries:
| Boundary | Qwen Live | UHP / HarnessRouter |
|---|---|---|
| Primary role | Voice control plane over coding sessions | Client ↔ server ↔ selected complete-harness execution contract |
| Current backend | Qwen Code through qwen serve REST/SSE | HarnessRouter exposes multiple released harness backends through UHP |
| Host transport | Live Host WS protocol v6 | UHP HTTP/SSE contract |
| Session model | Live-owned voice session plus backend coding sessions | UHP task/session objects at the server boundary |
| Cross-harness state | Future BackendAdaptor roadmap | Existing HarnessRouter backend catalogue |
| Adoption evidence | No native UHP evidence | HarnessRouter integrates Qwen Code; upstream Qwen UHP adoption remains not established |
A future ACP adaptor inside Qwen Live would still be an inner composition choice, not evidence that ACP becomes part of UHP or that an ACP-backed child natively adopts UHP.
Why it matters
Section titled “Why it matters”Qwen Live is a concrete example of a broader harness-engineering pattern: a user-facing control plane can be decoupled from the coding harness it commands. The front end owns interaction state and orchestration policy, while backend adaptors translate into the execution/session surfaces of the selected harness. That can make one interaction modality reusable across runtimes, but only if capability negotiation, identity correlation, cancellation, permission ownership and outcome delivery remain explicit.
The project is especially relevant to harness composition because its roadmap openly targets non-Qwen backends. At the current cutoff, however, that architectural direction should be tracked as a roadmap seam, not represented as released cross-harness interoperability.
Related pages
Section titled “Related pages”Read UHP and Qwen Code for the released HarnessRouter adapter and upstream Qwen runtime details, harness composition for internal agent/runtime topologies, UHP and ACP for the editor/client↔agent protocol boundary, and HarnessRouter Community Edition for UHP-side multi-backend routing.