mbailey/voicemode

North star Just call your assistant by name and start talking — no keyboard or screen needed. Pop in your wireless headphones, connect a wireless speaker, or just use your computer's mic, and Claude is simply there by voice, like a colleague in the room. Say "Hey Claude" (or whatever you've named your assistant), speak, hear the answer, carry on. This is an umbrella / north-star issue. It consolidates three existing requests that are all facets of the same dream: #58 — Listening for a wake word (@shenzo1): wake-word gating so VoiceMode is always listening but only acts when called. #457 — Ambient always-on mode (@DaemonNZ): a continuous VAD-gated listen/respond loop that runs in the background instead of per-converse. #210 — Trigger word for end-of-speech / "walkie-talkie mode" (@evbrandy): an explicit spoken end-marker ("over") for noisy environments where silence-VAD struggles. Those three are being closed and folded in here so there's a single place to track the vision —

I saw the "connect" feature but it didn't really seem like it would address my use case - I'm fine with using my laptop and local kokoro/whisper. The main pain point with voicemode is that it uses VAD and its not interruptible. So I have to speak quickly, with no interruption because if I pause VAD kicks in, starts processing my message and I can't interject again until claude runs voicemode again after its response. I want to approach a more natural language interaction. There are a lot of challenges implementing an always listening mic with buffer etc... (I tried vibe coding that but failed). A technically simpler, but still useful enhancement would be a push to talk mode that doesn't rely on VAD to stop and process but relies on explicit user input to determine when to start and stop recording. In addition the ability to cancel. I vibe coded a quick and dirty version. I couldn't think of a great way for the mcp server to receive the start/stop recording so I had it spawn a little pr

Thank you for this really useful project! Use Case When speaking in a non-English language (e.g., Greek), I want the STT output to be English so Claude can respond directly without needing to translate first. OpenAI and Groq Whisper APIs have two separate endpoints: /v1/audio/transcriptions — preserves input language (Greek speech → Greek text) /v1/audio/translations — translates to English (Greek speech → English text) VoiceMode currently uses the transcription endpoint exclusively. Proposed Solution Add a configuration option to use the translation endpoint instead: # In voicemode.env VOICEMODE_STT_TRANSLATE=true # Use translation endpoint (output always English) Or alternatively: VOICEMODE_WHISPER_TASK=translate # "transcribe" (default) or "translate" Implementation In simple_failover.py (line ~233), the change would be: # Current transcription = await client.audio.transcriptions.create(...) # With translation enabled if translate: transcription = await client.audio

Problem Statement Currently, when Claude responds via TTS, users must wait for the entire response to finish before they can speak. This creates friction in natural conversation, especially when: The user has already understood the point and wants to respond The user needs to redirect the conversation The response is longer than necessary for the user's needs Proposed Solution Add a "barge-in" or interrupt capability that detects when the user starts speaking and: Immediately stops TTS playback Seamlessly transitions to recording the user's voice input Continues the conversation without requiring manual intervention Technical Approach Looking at the existing NonBlockingAudioPlayer class in audio_player.py, a potential implementation could: Add a parallel VAD (Voice Activity Detection) thread that continuously monitors the microphone during TTS playback When voice activity is detected, stop the current TTS playback by: Clearing the audio queue Calling stream.stop() Setting the pla