Voice dictation cannot use Token Plan ASR: resolveVoiceTransport rejects qwen-audio-3.0-asr-flash as unsupported

[adityaa91990]

Summary

Model Studio's Token Plan serves speech recognition under the new model family ID qwen-audio-3.0-asr-flash, but Qwen Code's voice pipeline hardcodes the old IDs, so voice transcription cannot use any Token Plan ASR model. Mic capture itself works; the gate is purely the model-ID allowlist.

Environment

• Qwen Code 0.22.3 (global npm install), Linux
• Provider: OpenAI-compatible, baseUrl https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1 (Model Studio Token Plan, Global/Intl)
• Settings: general.voice.enabled: true, voiceModel: "qwen-audio-3.0-asr-flash", model registered in modelProviders.openai with the Token Plan baseUrl

Repro

1. Configure the voice model as above.
2. Press Space to start dictation.
3. Error: Voice model 'qwen-audio-3.0-asr-flash' cannot be used for transcription. Configure an OpenAI-compatible model with baseUrl in settings.modelProviders.

Evidence

• Token Plan docs list qwen-audio-3.0-asr-flash as the supported speech-recognition model (plus qwen-audio-3.0-realtime-plus, qwen-audio-3.0-tts-plus): https://www.alibabacloud.com/help/en/model-studio/token-plan-personal-overview

• Live endpoint probes against the Token Plan baseUrl (POST /chat/completions with an input_audio message, same shape as transcribeViaQwenAsr):

  • qwen3-asr-flash → 404 model_not_found (old ID no longer exists on this endpoint)
  • qwen-audio-3.0-asr-flash → 400 with empty body (model exists; the batch request shape is apparently not accepted for this ID)

• resolveVoiceTransport in packages/cli/src/services/voice-model.ts (0.22.3, and unchanged on upstream main as of 2026-09-03) only matches:

  • ^qwen3-asr-flash-realtime(?:-|$) → qwen-asr-realtime
  • ^qwen3-asr-flash(?:-\d{4}-\d{2}-\d{2})?$ → qwen-asr-chat
  • ^(fun-asr|paraformer).*realtime(?:-|$) → dashscope-task-realtime
  • anything else → unsupported

  So qwen-audio-3.0-asr-flash is rejected before any request is made.

Expected behavior

Qwen Code recognizes the current qwen-audio-3.0-* ASR family (at minimum qwen-audio-3.0-asr-flash) and routes it to the correct transport, so Token Plan subscribers can use voice dictation.

Suggested fix

Extend the resolveVoiceTransport allowlist to accept the qwen-audio-3.0-asr* family. Note the transport choice needs verification: my batch chat/completions probe of qwen-audio-3.0-asr-flash returned 400 {}, so this ID may speak one of the WebSocket protocols instead (/api-ws/v1/realtime or /api-ws/v1/inference) — i.e. it may need mapping to qwen-asr-realtime/dashscope-task-realtime rather than qwen-asr-chat.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug — confirmed in source, not a config mistake
• Labels: type/bug, category/cli, scope/model-switching, scope/interactive, priority/P2, status/ready-for-human
• Next: widen the ASR model-ID allowlist, but the transport for qwen-audio-3.0-asr-flash has to be confirmed against the live Token Plan endpoint first — see verification below.

Thanks for the unusually thorough report: exact settings, endpoint probes, and the responsible function named correctly. That made this quick to confirm.

中文说明

• 类型：bug —— 已在源码中确认，不是配置错误
• 标签：type/bug、category/cli、scope/model-switching、scope/interactive、priority/P2、status/ready-for-human
• 下一步：放宽 ASR model ID 白名单，但 qwen-audio-3.0-asr-flash 应该走哪个 transport，需要先对着 Token Plan 线上端点确认——详见下方验证结果。

感谢这份非常完整的报告：明确的配置、端点探测结果，并且准确指出了出问题的函数，因此确认过程很快。

---

Verification

Reproduced: not executed. This was an unattended CI run, so the analysis below is static source reading only — no build, no dictation attempt. Verified against main @ b4e9e40b (v0.23.0); the voice gate is unchanged from your 0.22.3, so this is not a stale-version report.

Root cause: confirmed. resolveVoiceTransport() in packages/cli/src/services/voice-model.ts is exactly the three-pattern allowlist you transcribed — qwen3-asr-flash-realtime* → qwen-asr-realtime, qwen3-asr-flash (optionally date-suffixed) → qwen-asr-chat, (fun-asr|paraformer)*realtime → dashscope-task-realtime, everything else → unsupported. qwen-audio-3.0-asr-flash matches none of them. The string qwen-audio appears nowhere in the codebase outside two unrelated design docs, so this family has never been wired up.

Affected area: isSelectableVoiceModel() (same file) builds on that function and gates every voice-model surface — the /model --voice command, the model dialog, and listWorkspaceVoiceModels() / validateWorkspaceVoiceModel() in voice-service.ts, which is what the daemon and Web Shell picker read. So one missing pattern blocks selection, record-time transcription, and the Web Shell at once.

One thing worth confirming. The message you quoted is formatUnsupportedVoiceModelMessage(), which fires from the selection gates and from the isTranscribableVoiceModel() check — but isTranscribableVoiceModel() is deliberately transport-agnostic, so a correctly registered OpenAI-compatible model with a baseUrl passes it. The allowlist itself, hit at record time in transcribeVoiceAudio(), throws a different string: Voice model '…' is not a supported transcription model. So if you hand-set voiceModel in settings.json and pressed Space, the expected message is the second one. Which surface produced your exact text — the picker//model --voice, or the Space press? It matters only for completeness: if it was the Space press, something also failed the transcribable check (authType, isRuntimeModel, imageOnly, or an empty baseUrl), which would be a second thing to look at. Either way the allowlist rejection is independently confirmed and is a real blocker on its own.

Fix direction

1. Two allowlists, not one. isVoiceModelId() in packages/web-shell/client/voice/voiceModels.ts is a hand-maintained mirror of the CLI patterns — its own comment says it can't import the CLI's voice modules. Widen only resolveVoiceTransport() and the Web Shell picker keeps rejecting the new family.
2. The transport mapping is the actual hard part, and your hesitation is well-founded. The three transports are not interchangeable: qwen-asr-chat POSTs {baseUrl}/chat/completions with an input_audio message (the exact shape you probed and got 400 {}); qwen-asr-realtime opens wss://{host}{prefix}/api-ws/v1/realtime?model=…; dashscope-task-realtime opens wss://{host}{prefix}/api-ws/v1/inference. A wrong guess fails twice over — mapping it to qwen-asr-chat also makes isStreamingVoiceModel() false, which silently routes dictation down the batch path instead of streaming.
3. Good news: no new URL plumbing is needed. deriveWebSocketBase() in voice-stream-session.ts already strips a trailing /compatible-mode/v1 — precisely your Token Plan baseUrl suffix — so https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1 derives to wss://token-plan.ap-southeast-1.maas.aliyuncs.com and both WebSocket transports would build correct URLs unchanged. Combined with your probe results (old ID → 404 model_not_found, new ID → 400 on the batch shape), the evidence points at a WS transport rather than qwen-asr-chat.
4. Two loose ends for the same change: docs/users/configuration/settings.md scopes keyterms biasing to "Qwen ASR models (qwen3-asr-*)", and buildKeytermsContext() is only wired into the qwen-asr-realtime transport — decide whether the new family gets keyterms too.

What would unblock this: the one missing fact is which protocol qwen-audio-3.0-asr-flash actually speaks on the Token Plan endpoint. A captured successful request — or just the WS handshake — from any working client would settle it. That needs Token Plan credentials we don't have here, which is why this is labelled status/ready-for-human rather than handed to an autofix agent that could only guess at the transport.

中文说明

是否复现：未执行。本次为无人值守 CI 运行，以下均为静态源码分析——没有构建，也没有实际尝试语音输入。核对版本为 main @ b4e9e40b（v0.23.0），语音判定逻辑与你使用的 0.22.3 一致，因此不是旧版本问题。

根因：已确认。 packages/cli/src/services/voice-model.ts 中的 resolveVoiceTransport() 正是你抄录的那三条白名单规则，qwen-audio-3.0-asr-flash 一条都不匹配。除两份无关的设计文档外，整个代码库没有任何 qwen-audio 字样，说明这个模型系列从未接入过。

影响范围：同文件的 isSelectableVoiceModel() 基于该函数，把守了所有语音模型入口——/model --voice 命令、模型选择对话框，以及 voice-service.ts 中的 listWorkspaceVoiceModels() / validateWorkspaceVoiceModel()（守护进程与 Web Shell 选择器读取的正是它们）。因此一条缺失的规则同时阻断了选择、录音转写和 Web Shell。

有一处想请你确认。 你引用的报错来自 formatUnsupportedVoiceModelMessage()，它由选择阶段的校验以及 isTranscribableVoiceModel() 抛出；而 isTranscribableVoiceModel() 刻意不检查 transport，所以一个正确注册的、带 baseUrl 的 OpenAI 兼容模型是能通过它的。白名单本身在录音阶段（transcribeVoiceAudio()）抛出的是另一句：Voice model '…' is not a supported transcription model.。所以如果你是手动在 settings.json 里写入 voiceModel 再按空格，预期看到的应是第二句。想确认你看到这句原文的入口是选择器//model --voice，还是按空格那一刻？这只影响完整性：若是按空格时报的，说明还有一项没通过 transcribable 校验（authType、isRuntimeModel、imageOnly，或 baseUrl 为空），那就是第二个要看的点。无论如何，白名单拒绝这一条已独立确认，本身就构成阻塞。

修复方向

1. 要改两处白名单，不是一处。 packages/web-shell/client/voice/voiceModels.ts 里的 isVoiceModelId() 是 CLI 规则的手工镜像——其注释明确说明 Web Shell 无法 import CLI 的语音模块。只改 resolveVoiceTransport()，Web Shell 的选择器仍会拒绝新系列。
2. transport 映射才是真正的难点，你的保留意见是对的。 三种 transport 不可互换：qwen-asr-chat 向 {baseUrl}/chat/completions 发带 input_audio 的请求（正是你探测到 400 {} 的那个形状）；qwen-asr-realtime 连 wss://{host}{prefix}/api-ws/v1/realtime?model=…；dashscope-task-realtime 连 wss://{host}{prefix}/api-ws/v1/inference。猜错会双重失败——映射成 qwen-asr-chat 还会让 isStreamingVoiceModel() 返回 false，从而把语音输入悄悄改走批处理路径而非流式。
3. 好消息：不需要新增 URL 处理逻辑。 voice-stream-session.ts 中的 deriveWebSocketBase() 已经会剥掉结尾的 /compatible-mode/v1——恰好是你 Token Plan baseUrl 的后缀——因此 https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1 会推导为 wss://token-plan.ap-southeast-1.maas.aliyuncs.com，两个 WebSocket transport 都能原样拼出正确 URL。结合你的探测结果（旧 ID 返回 404 model_not_found，新 ID 在批处理形状下返回 400），证据更倾向 WebSocket transport，而非 qwen-asr-chat。
4. 同一次改动里的两个收尾项：docs/users/configuration/settings.md 把 keyterms 偏置限定为 "Qwen ASR models (qwen3-asr-*)"，而 buildKeytermsContext() 只接入了 qwen-asr-realtime transport——需要决定新系列是否也支持 keyterms。

解除阻塞所需：唯一缺失的事实是 qwen-audio-3.0-asr-flash 在 Token Plan 端点上究竟讲哪种协议。任何可用客户端抓到的一次成功请求（哪怕只是 WS 握手）就能定论。这需要 Token Plan 凭据，我们这里没有，因此本 issue 标记为 status/ready-for-human，而不是交给只能猜 transport 的自动修复 agent。

--- Qwen Code

[adityaa91990]

Transport verification for qwen-audio-3.0-asr-flash against the live Token Plan endpoint (follow-up to triage's "Next"; probed 2026-09-03 with a plan key on token-plan.ap-southeast-1.maas.aliyuncs.com).

The bare ID is present in the gateway registry, but none of the three voice transports Qwen Code implements completes a session:

1. qwen-asr-chat — POST /compatible-mode/v1/chat/completions with input_audio content (data-URL and raw base64, audio_url shape, with/without asr_options, stream on/off): always 400 with an empty body {}. Controls: qwen3.8-max + audio → descriptive 400 (An incorrect modal 'audio' was entered…); qwen3-asr-flash → 404 model_not_found.
2. dashscope-task-realtime — wss://…/api-ws/v1/inference run-task dialect: task-started then task-failed InvalidParameter: url error, please check url!. Control qwen3-asr-flash-realtime fails with Model not exist. on the same path — so the model is recognized but rejects this endpoint family.
3. qwen-asr-realtime — wss://…/api-ws/v1/realtime?model=qwen-audio-3.0-asr-flash (OpenAI dialect): handshake accepted, but the server never sends session.created and answers every client event (session.update incl. modalities:["text"] and empty-session variants, input_audio_buffer.append/commit) with a bare {}; raw binary frames → close 1003 BinaryWebSocketFrame is not supported. Controls: qwen3-asr-flash-realtime → close 1007 Model not exist.; qwen-audio-3.0-realtime-plus → full dialect works (session.created/session.updated, commit accepted).

Additionally, the family's streaming/filetrans IDs per the official model catalog (doc 2840914) — qwen-audio-3.0-asr-flash-streaming and qwen-audio-3.0-asr-flash-filetrans — return Model not exist on both WS paths: not provisioned on Token Plan; the roster exposes only the bare ID.

Conclusion: widening the ASR allowlist is the right fix shape, but on Token Plan the bare ID appears batch-only/unrouted — the allowlist alone will not produce working voice there until the plan provisions the streaming variant (or routes the bare ID to a live ASR backend). The empty 400 {} on chat and bare {} WS acks look like a gateway routing gap rather than a client protocol error, so it may be worth confirming server-side which backend (if any) the bare ID is bound to on this endpoint.

[now-ing]

Hi, I've opened #10981 to accept the qwen-audio-* Token Plan ASR family in resolveVoiceTransport() (and the web-shell's mirrored isVoiceModelId() allowlist), following the transport mapping evidenced in the thread:

• qwen-audio-<v>-asr-flash → qwen-asr-chat
• qwen-audio-<v>-asr-flash-streaming / -realtime / qwen-audio-<v>-realtime[-plus] → qwen-asr-realtime
• everything else (including -filetrans / -tts-plus) stays unsupported; version segment is forward-compatible ([\d.]+)

So qwen-audio-3.0-realtime-plus becomes immediately usable for Token Plan dictation, and the bare -asr-flash / -streaming variants will light up as soon as the server-side provisioning lands. New tests + a 221-test voice regression sweep are green (details in the PR).