Subvocal: talking to your computer without making a sound

Have you ever tried to dictate a commit at the office and given up because the coworker next to you would hear "fix: stupid bug I created myself"? Subvocal wants to end that embarrassment. It showed up in a Show HN with a simple promise: talk to your computer without making a sound.

The idea touches an old frustration. Voice dictation has worked well for years, but almost nobody uses it at work. The reason isn't technical. It's social.

So what is Subvocal?

The pitch is to control the machine using subvocal speech. That's the speech you "almost" make. You move your mouth, tongue and throat, but no sound comes out. Everyone does it without noticing when reading carefully.

The concept isn't new. MIT showed AlterEgo in 2018, a device that read electrical signals from facial muscles to recognize words spoken in silence. NASA studied something similar in the 2000s. What changed since then is the rest of the stack. Recognition models got cheap, run locally and understand context much better.

An honest disclaimer: I haven't tested Subvocal on my machine. What I write here is about the idea, the kind of pipeline a project like this needs and what I'd do to validate it before trusting it. If you want hardware and accuracy details, the original thread is the right place.

Why silent interfaces matter for devs

Think about your day. How many times do you stop what you're doing to:

• open a terminal and run the same old command;
• switch branches;
• ask the coding assistant for something;
• find a file by name.

Each of these takes a few seconds. The problem is the context switch. Taking your hands off the code to click something breaks your train of thought.

Voice would solve part of this, if not for three things: background noise, privacy and the awkwardness of talking to yourself in an open office. Silent speech tackles all three at once. You keep typing and, in parallel, "say" a short command.

The bottleneck of dictation was never the model. It was the coworker at the next desk.

Now, the part few people mention. With coding agents becoming routine, the amount of natural language text we send to the machine has exploded. Prompts are long. Typing prompts is tedious. An input that needs neither a keyboard nor a loud voice fits right into that workflow.

Where Bun fits in

Tools like this always share the same architecture underneath. A sensor or model produces text. Something receives that text and turns it into an action on the system. That second part is glue, and glue is exactly where Bun shines.

Why? Because you get an HTTP server, WebSocket, process execution and file reading in the runtime, with nothing to install. It starts in milliseconds. For a daemon that runs all day waiting for commands, that matters.

A prototype of the "action side" fits in a few lines:

// daemon.ts: receives recognized text and triggers actions
const commands: Record<string, string[]> = {
  "status": ["git", "status", "--short"],
  "tests": ["bun", "test"],
  "main": ["git", "switch", "main"],
};

Bun.serve({
  port: 4321,
  hostname: "127.0.0.1",
  fetch(req, server) {
    if (server.upgrade(req)) return;
    return new Response("WebSocket only", { status: 400 });
  },
  websocket: {
    async message(ws, msg) {
      const text = String(msg).trim().toLowerCase();
      const cmd = commands[text];
      if (!cmd) return ws.send(`didn't get that: ${text}`);

      const proc = Bun.spawn(cmd, { stdout: "pipe" });
      ws.send(await new Response(proc.stdout).text());
    },
  },
});

Notice two choices. First, the server only listens on 127.0.0.1. A daemon that runs commands in your shell can't be exposed to the network, not even by accident. Second, the commands live in a closed list. No taking the recognized text and throwing it straight into sh -c. Recognition will make mistakes, and you don't want "run tests" turning into "rm" because of a misread muscle.

The problems no pretty post solves

I like the idea. But I've seen enough Show HN demos to know where they usually break.

Accuracy. Speech recognition with sound already fails in noisy places. Without sound, the signal is much weaker. A 5% error rate looks good on paper. In practice, it means getting one command in twenty wrong. If the command is "open file", fine. If it's "push", not so much.

Vocabulary. Systems like this tend to do very well with a small set of words and get worse fast with free text. For short commands, it works. For dictating a three-paragraph prompt, I'd stay skeptical until I see real numbers.

Calibration. Everyone moves their mouth differently. If the tool needs per-user training, the onboarding friction goes up. It's worth checking how long it takes to become usable.

Privacy. If the signal leaves your machine for an API, you're sending, literally, what you thought about saying. I'd only use something like this with local inference. Period.

The good news is that you can mitigate a lot of this with design, not with a better model. A pattern I'd use:

// confirmation for actions with side effects
const dangerous = new Set(["push", "deploy", "reset"]);

function needsConfirmation(text: string) {
  return [...dangerous].some((d) => text.includes(d));
}

Safe commands run right away. Dangerous commands ask for a "yes" on the keyboard. Simple, boring and effective.

How to evaluate Subvocal (or any similar tool)

If you want to try it, I suggest a quick checklist instead of getting hyped by the demo video:

1. Pick 10 real commands from your day. Not the demo ones, yours.
2. Repeat each one 10 times in normal conditions: sitting down, tired, after lunch.
3. Write down hits and latency. If it takes more than half a second between "speaking" and the action happening, you'll go back to the keyboard.
4. Test for false positives. Spend 15 minutes reading docs in silence. Did the tool trigger anything on its own? This is the test that matters most, because we subvocalize all the time without meaning to.

That last point is my biggest worry with the whole category. Reading code is subvocalizing. If the system can't tell "I'm reading" from "I'm giving a command", it'll become an assistant that butts in at the wrong time. A wake word or a keyboard shortcut for "I'm talking to you now" solves it, and I'd be suspicious of any project that doesn't have something like that.

What changes in your workflow

Today, almost nothing. Realistically, silent interfaces are still in the exciting prototype phase. They won't replace the keyboard anytime soon. The keyboard is fast, precise and needs no calibration.

What changes is the direction. We spent decades with two inputs: keyboard and mouse. Voice became the third, but got stuck in the car and the kitchen. A silent input could be the first one that works inside the office, alongside the keyboard, not instead of it.

And for people who build tools, the lesson is different. The hard part (the model, the sensor) will be more and more outsourced. The value will be in the integration layer: which commands exist, how to confirm dangerous actions, how to avoid false positives. That's plain application code, the kind we write every day in TypeScript.

My take: the idea is good and the timing is right, but I'll only take it seriously when someone uses it eight hours a day without turning it off on day three. Until then, I'll play with a Bun daemon and a list of five commands, which is how every good tool starts. If you're into this kind of experiment, take a look at what I've been building in my projects.

Voice dictation never caught on at the office, and the reason wasn't technical. It was the coworker at the next desk.

Subvocal showed up on Hacker News with a bold pitch: control your computer by moving your mouth and throat, without making a single sound.

With coding agents becoming routine, we've never written so many prompts. An input that needs neither a keyboard nor a loud voice fits right into that workflow.

But my biggest worry is something else. Reading code is already subvocalizing. Without a wake word, the tool becomes an assistant that butts in at the wrong time.

That's why I'd validate it with 10 real commands, local inference and keyboard confirmation for anything dangerous, like push or deploy.

On the blog, I wrote about how I'd build the Bun daemon that handles the action side. Would you use a silent interface at work?

#SoftwareDevelopment #ArtificialIntelligence #Bun #TypeScript #DevTools