[FEATURE]: Voice/Speech Input Support for Desktop App

[dayesann]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

Currently, OpenCode Desktop does not support voice/speech input. Users must type all prompts manually, which is inefficient for long or complex instructions. Most mainstream AI coding agents (e.g., Cursor, GitHub Copilot Chat, Claude Desktop) already support voice input natively.

Proposed Solution

Add built-in voice/speech-to-text input capability to the OpenCode Desktop app, similar to what other AI coding tools offer:

• Push-to-talk button or always-on wake word in the chat input area
• Speech-to-text using local or cloud-based ASR (e.g., Whisper, browser Web Speech API)
• Configurable: Allow users to choose between local processing (privacy-first) or cloud-based transcription (accuracy-first)
• Cross-platform: Support macOS, Windows, and Linux

Use Cases

1. Hands-free coding — describe feature requests verbally while reviewing code
2. Accessibility — users with RSI or other conditions benefit greatly from voice input
3. Long prompts — faster to speak complex multi-step instructions than type them
4. Non-native speakers — easier to articulate ideas in spoken language for many users

Alternatives Considered

• OS-level dictation (macOS/Windows built-in) — works but lacks context awareness and requires switching modes
• Third-party tools — adds friction, not integrated into the workflow

Context

Voice input is becoming a standard feature in AI-powered developer tools. Adding this to OpenCode Desktop would significantly improve the user experience and accessibility, especially since OpenCode emphasizes being "the open source AI coding agent" — voice input aligns with making coding more accessible to everyone.

[LauraGPT]

For the first desktop voice-input slice, I would keep the UI small and make the STT backend pluggable from day one instead of hard-wiring browser/OS dictation.

A practical MVP shape:

• push-to-talk button records audio in the desktop app
• audio is sent to an app-side transcription provider, not directly from the renderer to a third-party URL
• transcript is inserted into the prompt box for review/edit by default, instead of auto-sending
• provider config supports a local OpenAI-compatible POST /v1/audio/transcriptions endpoint plus optional model/language fields
• OS dictation/Web Speech can stay as a fallback, but should be visibly distinct from a configured local/private STT provider

That provider boundary would let users run Whisper-compatible services, FunASR/SenseVoice, or other local ASR engines without OpenCode needing to embed each model runtime. It also matters for CJK/local/offline workflows where browser dictation is usually the wrong default.

Tests I would want around the first pass:

• provider API keys/base URLs are not exposed to the renderer when an app-side bridge is used
• failed transcription keeps the recorded audio or draft state intact
• language/model options are forwarded
• transcript insertion is reviewable before send
• local provider and cloud provider paths share the same UI contract

[x-lixu]

For anyone who wants voice with OpenCode today: qwen-audio-agent connects to OpenCode natively over ACP (one-click install inside the app) and provides full-duplex voice with barge-in, so the conversation keeps going while OpenCode runs tasks in the background. It ships a macOS desktop app, a TUI, and a web UI. It is external to OpenCode itself, but it covers the use case end to end until first-party support lands.

[liudongyan13701205717-source]

Supporting this request as a Chinese-speaking Windows desktop user (was tracked in #41364, closed as duplicate of this one). Strong demand: typing long prompts in CJK is slow, and voice would help a lot.

Additional context beyond the original proposal:

1. TTS voice summary output — after long agent tasks complete, optional spoken summary ("任务完成, 要点: ...") is a natural companion to voice input; suggested as a cheap sidecar feature (works offline, no model cost) via a plugin hook.
2. Windows UX details: on Windows use native Speech API (Windows Speech Recognition / WinRT SpeechSynthesizer) or Whisper local instead of cloud — keeps with privacy expectations of a desktop IDE-adjacent tool.
3. Scope layers (MVP first): (a) 🎤 button next to input box → OS speech-to-text → inserts into prompt; (b) push-to-talk hotkey (like Feature: Hold-spacebar push-to-talk voice input (like Claude Code) #35219); (c) TTS summary configurable in Settings.

This one issue (#33300) is the consolidation point for #35219, #37742, #39688, #38300, #18226, #31542 and my #41364 — worth a clean spec + assignment so all the voice threads can converge.

[x-lixu]

+1 to the consolidation — and a quick mapping for anyone who wants parts of this today, since qwen-audio-agent (ACP client running alongside OpenCode) already ships several of these points:

• Point 1 (TTS voice summary): it announces long-running task results back into the live conversation by voice — "任务完成 + 要点播报" style — which is the same UX this suggests.
• CJK input: Chinese speech recognition is fully supported, so the "typing long prompts in CJK is slow" pain is covered.
• Point 2 (privacy): wake word and the voice runtime run locally; only the realtime speech model is cloud-based (DashScope), configurable.

None of this replaces the native feature — just noting the overlap so the spec work can borrow what's already been validated. (Disclosure: maintainer, as before.)