What actually leaves your machine when you use voice coding

“Runs on-device” is the easiest claim in software to make and one of the hardest to check. So here is the boring version: a list of everything SKI sends over the network, and everything it doesn’t.

What never leaves

Speech-to-text runs entirely on your machine. Your spoken input becomes text before anything else happens to it, and that conversion happens locally, there is no upload step where audio is sent somewhere to be transcribed and sent back.

Text-to-speech runs locally too, using one of four on-device neural voices. The reply you hear is synthesised on your own hardware.

Both halves of the loop work with no network connection at all. That’s the practical test, and it’s the one worth running yourself: pull the wifi and keep talking to your agent. Everything except sign-in and updates carries on.

Why we’re not in the middle of your code

This is the part people assume wrong, and it’s the more important half.

SKI doesn’t sit between you and Claude Code’s or Codex’s model. It installs a shared skill into ~/.agents/skills/, a small set of instructions your agent already knows how to read, which teaches it that voice input exists and that it can emit spoken output. What you say still goes to that agent’s own model, over that agent’s own connection, exactly as if you had typed it.

There is no SKI server in that path. We never see your prompts, and we never see your repository, because neither one is ever routed through us. SKI is the I/O layer, not a new model in the middle.

The four things that do touch the network

Being precise here matters more than sounding absolute:

• Signing in: email and a one-time code, once.
• Update checks: the app asking whether a newer build exists.
• Optional anonymous analytics: feature counts only, never audio, code or transcript content. You can opt out during onboarding.
• Sending your agent into a live call: the one add-on that genuinely can’t be local, because a bot joining a Zoom, Meet or Teams call has to run somewhere that isn’t your laptop. That’s AgentCall, it’s clearly separate, and it’s the only metered piece.

“Works offline” and “has one cloud feature” aren’t in tension. The core voice loop is fully local; the meeting bot is a different product doing a different job, and you have to go out of your way to use it.

Mute that actually mutes

Here’s a small thing that tells you more than any policy page.

When you mute SKI, the microphone is actually released, not just ignored. A surprising number of voice apps don’t bother, they stop processing audio while keeping the stream open, so the light stays on and you have only their word for what’s happening.

That indicator is drawn by the OS, not by us. It’s one of the few privacy signals on your machine that an application cannot fake. Worth checking in any voice tool you try, including this one.

Two controls worth knowing about

Approve-before-send can be switched on per project. Your transcript becomes an editable draft that you confirm before the agent ever sees it, useful on a repository where you’d rather nothing reaches the model until you’ve read it back.

Silent mode renders replies as text only. The loop still works; the room just doesn’t hear it. Made for open-plan offices and live calls.

The honest part

SKI is free but closed source. The GitHub repository hosts release binaries, not the codebase, which means you can verify the behaviour described above, but you can’t read the implementation. We’d rather say that plainly than let “it’s on GitHub” imply something it doesn’t.

What you can do is check the claims from the outside: pull the network and keep working, watch the microphone indicator when you mute, and look at where your agent’s traffic actually goes. Those three tests cover most of what matters, and none of them require trusting us.

More on the architecture in how SKI works, or the practical setup in the voice coding guide.