Typing is not the only way to talk to an agent. Mobile users, developers mid-flow who do not want to break hand position, accessibility scenarios — voice input is the “low upvotes, high real usage” kind of need.
The demand
- #5049 and #4164: two independent requests for native voice input.
- #2431: proposes the official side expose ASR/TTS as a capability seam.
- #6552: an Android voice-input bug report — reverse evidence that people already use voice input on phones.
The gap
In the 2026-09-16 index snapshot, 248 repositories touch voice/audio and none has reached 100★; the highest, dsh-omi-voice at 74★, only reads aloud and does not do input. Across our whole index analysis this is the category with the widest gap between demand-keyword volume and working supply.
Proposed shape
Client UI first: a microphone button in the composer (hold to talk, release to send), with an optional host service forwarding to a local whisper or cloud ASR. Read-aloud starts from Speech Synthesis.
Implementation notes
- Web Speech API / getUserMedia is enough to start; do not build an audio pipeline on day one.
- Audio is sensitive input: process locally by default or disclose cloud forwarding explicitly, and state the permission surface plainly — reviewers look at exactly this.
- For the composer extension point see the official slots.md and web-client.md.
The MVP
Hold-to-talk-to-text into the composer on desktop Chrome. Read-aloud in v2.
Risks
Honestly: the Discussion threads have modest upvotes. The thesis here is not “loud demand” but “zero supply” — the first solid voice plugin likely takes the category, but growth may be slow. Go in with that expectation.
FAQ
Why has none of the 248 repos taken off?
Most are demos or bundled inside do-everything plugin packs. None is single-purpose with polished interaction (hold/release, misfires, permission onboarding).