Before EchoControl, I had an assistant called Lucía. That's why EchoControl never tries to understand everything

Before EchoControl, there was Lucía.

I built her for myself, a few years back: a general voice assistant that ran on my phone and my desktop, handling the normal things — check the weather, open an app, answer if she could. The first version ran on Whisper, an open transcription model, because that's what a general assistant is supposed to do: you don't memorize commands, you just talk and it figures out what you meant.

Lucía's desktop interface in listening mode, with her status log showing a wake word detected and gaze tracking data
Lucía, the general assistant that existed before EchoControl.

Whisper never really worked for this. It took too long to return a transcription, and turning whatever it had transcribed into a real action was harder than it should have been — too many ways to say the same thing, and no reliable way to map all of them to a fixed set of commands. Very early on, I made the call: drop open dictation, move Lucía to a closed grammar instead. A fixed, known list of phrases, checked directly, instead of an unlimited vocabulary you have to guess at every time.

The engine behind that switch was Vosk, and it turned out to be fast, and surprisingly easy to map directly to keyboard shortcuts and actions. That combination — speed, and a direct line from phrase to action — is what stuck with me.

Lucía's command list, showing fixed phrases like "close tab" mapped directly to a keyboard shortcut (Ctrl+W)
The same idea EchoControl runs on: a closed list of phrases, each one mapped straight to a key.

One evening I was playing something with a keyboard covered in bindings I never fully memorized, and I caught myself thinking: why not this too? Whatever had just solved Lucía's latency problem looked exactly like what a fast-paced game would need. Why not talk to the game the same way I'd already fixed Lucía to listen?

That question is where EchoControl started. The answer, once I actually sat down to build it, was the same one I'd already landed on with Lucía. Closed grammar wasn't a new idea for games — it was the one lesson Whisper had already taught me, applied somewhere with even less room for error.

Why open listening doesn't work mid-fight

Lucía's problem with Whisper was speed: a transcription that takes a second or two to come back, plus the extra time spent guessing which command it matches, is tolerable in a casual chat. It isn't mid-fight.

A game can't afford that lag, or the guessing that comes with it. If you say "reload" mid-firefight and the software takes half a second to weigh several possible interpretations before picking one, that half-second already cost you the fight. Worse still: pick the wrong one, and you didn't just lose time. You fired the wrong action.

The same latency problem that pushed Lucía off open dictation is the reason EchoControl never considered it in the first place.

So instead of open listening, EchoControl uses a closed grammar: a fixed, defined list of phrases per game, decided in advance. The software isn't guessing what you might mean out of an unlimited vocabulary. It checks your words against a short, known list, and fires whichever one matches. Nothing else gets considered.

What runs underneath: Vosk, and why offline

The recognition engine is Vosk, the same offline speech recognition engine that had already fixed Lucía's latency problem. Being offline wasn't a minor detail. It's the reason we picked Vosk over anything that sends your audio to a server.

A cloud recognizer has to send your voice out, wait for a server to process it, and send the result back. On a normal connection, that round trip alone can cost more time than EchoControl's entire budget for recognizing a command. Vosk runs the model on your own machine, so there's no network step to wait on. Just your CPU, doing the work locally, right when you speak.

Closed grammar and Vosk work together, not separately. A small, defined phrase list is also a smaller search space for the model, which is what makes local recognition realistic on a normal gaming PC. Running open recognition — any word, fully offline, fast enough for real gameplay, on the hardware most players actually own — wasn't something we could make work.

The latency budget, in real numbers

We test every profile against a rough target: under 200 milliseconds from the end of your sentence to the key firing. Fast enough to feel instant. Closer to a hotkey than to a conversation.

For comparison, casual back-and-forth with an assistant can tolerate a second or two of "thinking" without feeling broken. A voice command mid-combat can't. That's the real reason a general assistant and a game command system can share the same kind of model underneath and still end up as two completely different pieces of software.

What "recognizing a command" actually means here

When a profile ships, its phrases aren't loose examples. They're compiled into a grammar Vosk checks directly. A single command usually accepts several phrasings, all set as accepted for the same key — say:

  • "reload"
  • "reload weapon"
  • "put in a new mag"

Saying any one of them has to match a line already present in that list, or nothing fires.

The grammar only recognizes what's actually written into it. That's also why alternate phrasings matter so much in every profile: if a phrase a player would naturally say isn't on that list, it will never be understood, no matter how clearly they say it. It's one of the reasons every profile goes through repeated testing with more than one way to say the same thing — see the Commandos 2 command testing post for a real example of that process.

Lucía still runs, by the way. She still doesn't know a single voice command from any game EchoControl supports. That was never her job. It's a different job — running on the same idea that fixed her in the first place.

See EchoControl in action and hear how fast a closed grammar actually fires.

See EchoControl in action →