Talk to Claude Code (with your voice) from anywhere

by

Here's an MCP server that lets you talk to Claude Code from anywhere you can negotiate a WebRTC connection (or make a phone call):

I’ve been talking to all the programs I use on my computer as much as I can, and I have a bunch of different hacked-up ways to do that. This is a pretty clean implementation of an MCP server that any harness (like Claude Code) with MCP support should be able to use. This shows both the strengths and weaknesses of MCP in interesting ways, I think.

What I really want is deep, configurable integration of voice into Claude Code (and other programs that I have long-running “conversations” with, with seamless background process management and network transport). And I think that will actually start to be the norm at some point. Voice such a natural interface for so, so many kinds of interactions.

I was telling a friend the other day that our kids will think about keyboards the way I think about punch cards. “Kind of cool that they used to program computers like that.”

Video here:

853 views

Add a comment

Replies

Best
i can talk to claude already why would i use this
cool project thanks for sharing
in long running agents, instead of checking about the progress what if you could able to manipulate without restarting or stopping the work completed by agents , thats possible with help of relay. AI workflows can run for 30+ minutes. A policy changes. A human intervenes. Requirements change. Today, most systems restart from scratch. Why can't we steer a running workflow instead? That's what I'm building with Relay.
interesting 💭
cool
Really solid direction. A few things I'd be curious about under the hood: Session negotiation & reconnects — WebRTC's ICE negotiation typically adds a few hundred ms on cold start depending on STUN/TURN availability. For a tool meant to be invoked mid-workflow (e.g., "talk to Claude Code" spontaneously from a walk), that latency matters a lot more than in a scheduled call context. Is the MCP server keeping any warm connection state, or is every invocation a full renegotiation? A short-lived session cache keyed to the user/device could probably shave that down significantly if it's not already doing that. Concurrency between audio and tool-call streams — Claude Code's tool-use responses are already a fairly chatty event stream (especially with parallel tool calls). Layering a live audio channel on top means you're now multiplexing two asynchronous, latency-sensitive streams. Curious whether you're handling that with separate transport layers entirely, or if MCP's existing message framing is doing double duty. If it's the latter, I'd expect some jitter under load — worth stress-testing with a long agentic run where the model is issuing several tool calls back-to-back while also expected to respond conversationally. Interruption handling — this is the part that makes or breaks voice UX in my experience. If I start talking while Claude Code is mid-response (especially mid-tool-execution), does the server support barge-in / cancellation cleanly, or does it queue and finish the current turn first? That's usually where "clean MCP implementation" and "actually pleasant to use hands-free" diverge. Appreciate you open-sourcing this — even the "weaknesses of MCP" you mention are useful signal for anyone building adjacent tooling. Would genuinely try this on a long build session to see how it holds up over an hour+ of continuous back-and-forth rather than a quick demo.
Very interesting idea. How is the latency in real-world use? Does it feel natural enough for daily coding sessions?

Very promising. For long-running voice sessions, I’d want clear confirmation before file changes or terminal actions—especially when connecting remotely. Does the MCP server support configurable approval checkpoints?

this is so cool
i am not sure but anthropic don't have their own voice model....they use 11labs