Repository navigation
voice: first-party voice input and speech output #53977
Description
Summary
OpenCode has no built-in voice input or speech output. Every voice workflow requires assembling a plugin (capture, transcription, keybinding, dialog, TTS) by hand. Since the plugin API already makes all of this possible, the pieces exist, but there is no first-party UX for the single most common voice workflow: dictate a prompt and send it.
Problem
Typing is a hard requirement to use an AI coding assistant. That is fine for most people, but it makes OpenCode unusable for anyone who cannot type comfortably or quickly, including people with motor impairments, injuries, or visual limitations. Voice input is the obvious accessibility affordance here, and terminal-based assistants are notably behind web assistants: Gemini, Claude and ChatGPT all support microphone input natively.
OpenCode is well positioned for this, because it is commonly used on Linux desktops where audio capture (pw-record, arecord) and local models are readily available.
Proposal
Voice is most valuable when the user chooses how much of it they want:
-
Push-to-talk dictation (minimum viable). A microphone control next to the prompt input. Hold or toggle to record, release to transcribe, review the text, send. No audio file is ever sent to the model; only the resulting transcript becomes the prompt.
-
Hands-free mode (optional). Voice activity detection ends the utterance automatically, so the user does not need a key at all. The transcript is inserted into the prompt for review, or sent directly if the user opts in.
-
Speech output (optional, user-selectable). Read responses aloud, with the user able to pick a voice and a language. This needs streaming synthesis, so text is spoken per sentence as the response arrives rather than waiting for completion.
Language should follow the user's choice, with sensible per-language defaults.
Existing evidence that this is feasible
The plugin API is already sufficient to build all of the above. A working implementation exists as a TUI plugin and does the following:
- captures 16 kHz mono audio with
pw-record, falling back toarecord - transcribes with
whisper-large-v3-turbo, leaving the language on autodetect so Spanish speech keeps English technical terms intact - shows the transcript in a dialog for review before sending
- submits it to the current session
- stores the API key in a
chmod 600file, never in the config or the logs
That is roughly 170 lines of TypeScript, which raises two points:
- There is no missing platform capability. What is missing is a supported, discoverable and documented path.
- Third-party plugins require the user to supply and pay for a transcription provider and to manage credentials themselves. A first-party implementation could route this through the existing OpenCode account, and could support a local model for users who cannot or do not want to send audio off the machine.
Environment
- opencode version: 2.0.23
- OS: Debian GNU/Linux 13, kernel 6.12.111+deb13-amd64
- Clients: TUI, and the desktop app
- Shell: /bin/bash
- Audio: PipeWire capture via
pw-record, ALC897 onboard microphone
Current workaround
A local TUI plugin providing push-to-talk dictation with a configurable transcription provider. It requires a provider API key and some manual setup.
Scope notes
- TUI vs desktop: the desktop client is where a visible microphone button belongs, since the TUI has no pointer-based chrome and would need a keybinding instead. Supporting the desktop client first would cover the accessibility case best.
- Privacy: audio should never reach the model. Transcription is a separate step and only the transcript is sent as the prompt.
- Cost: this is optional functionality and should not change the behaviour or the cost of sessions that do not use it.
Activity
opencode-agent commentedon Oct 8, 2026
Thanks for the detailed write-up and for sharing how your plugin works.
I think this is a duplicate of #33300, which tracks built-in voice/speech input (push-to-talk, local or cloud transcription, privacy options, accessibility). It covers the main part of your request, dictating a prompt with the desktop client first.
Possible duplicates and closely related issues and PRs, ordered from most to least likely:
If you'd like to add your accessibility points or your hands-free and speech output ideas, #33300 is a good place for them, so the discussion stays in one thread.
The bot will close this issue as a duplicate in 1 day unless you reply explaining how your request is different.
NightCrewSec commentedon Oct 8, 2026
Thanks for triaging this.
I agree this is a duplicate of #33300 and I have nothing to add to the request itself, so this can be closed.
The parts of my write-up that were not already covered, the accessibility case, hands-free via voice activity detection, and speech output, I have posted as a comment on #33300 so that discussion stays in one thread:
#33300 (comment)
Two notes that may be useful for whoever picks this up. The TUI part of my request is already implemented as a working plugin in roughly 170 lines using
pw-recordandwhisper-large-v3-turbo, so the plugin API is sufficient for dictation end to end. And the label list already contains several open PRs for this, #53492, #50549, #29663 and #11345, which suggests the remaining work is mostly the hold/release keybinding gap and the speech-output half rather than dictation itself.Closing this one, no need to ping me again.
opencode-agent commentedon Oct 8, 2026
Thanks for confirming, and for moving the accessibility, hands-free (voice activity detection) and speech-output points to #33300 so the discussion stays in one thread. The bot will close this issue as a duplicate of #33300.
opencode-agent commentedon Oct 9, 2026
Closing this as a duplicate of #33300, as agreed above. Voice input is tracked there, and the accessibility, hands-free and speech-output points from this issue are now in the comment posted on #33300. Related work: #35219 (TUI hold-to-talk keybinding) and the open PRs #53492, #50549, #29663 and #11345. Thanks for the detailed write-up.