Most dictation features are built around one unstated assumption: hold the key, and your voice goes to a server. That's a fine trade for a notes app. It's a worse one for a coding tool, where holding a key to dictate just as often means describing a database schema, reading out a client's proprietary architecture, or narrating a chunk of code you're not supposed to paste into a browser. Influxx's hold-to-dictate feature inverts the usual order: offline speech-to-text dictation is the real, fully-functional default for coding work, and sending audio to a cloud model is something you opt into — with your own API key — only if you want it.
The Privacy Trade-Off Most Dictation Features Skip
Voice input got normalized by consumer products that had every incentive to route audio through a server: it's how the underlying model improves, how the feature gets built at all, sometimes how it gets monetized. None of that is sinister on its own. But it means "send my voice to a cloud API" became the unremarkable default almost everywhere, including in developer tools that were never built to ask whether that default made sense for what developers actually dictate.
What developers dictate into a coding tool is rarely small talk. A hold-to-dictate prompt to an agent might describe an internal service name, a bug tied to a client's data model, or the exact shape of a feature under NDA. A quick note might reference a customer by name. None of that is unusual — it's just what technical work sounds like out loud — but it's exactly the content that makes "cloud by default" a real cost for a lot of professional and enterprise use, not a theoretical one.
Our answer wasn't to bury an offline mode in a settings menu for the privacy-conscious minority to go find. It was to make the offline path the one everybody uses without thinking about it, and let the cloud option exist for the people who specifically want it.
"We didn't want to ship an offline mode that exists on paper but that nobody actually uses because the cloud path is obviously faster or more accurate. If local is the default, it has to be good enough that most developers never feel a reason to leave it."
— Amara Okafor, Head of Developer Experience at ETAPX
Hold the Key, Say the Thing: How Dictation Works in Influxx
The mechanics are deliberately simple. Hold a key, speak, let go, and what you said appears as text wherever your cursor was focused — a prompt box for whichever agent is running in the active tab, a note in Influxx's built-in notes pane, a commit message, anything with a text cursor. There's no separate dictation window to open, no confirmation step, no app to switch to.
The point is that reaching for the keyboard to type a long, precise instruction breaks flow in a way that talking doesn't. If you're mid-session with an agent and want to describe several things it should change, saying them out loud is often faster and more natural than typing a paragraph. A few places this shows up in practice:
- Prompting an agent: describe a multi-step instruction to Claude Code, Codex, Cursor, or whichever CLI is running in the active tab, instead of typing it out by hand.
- Capturing a note mid-session: drop a thought into Influxx's notes pane without breaking away from the terminal or reaching for the mouse.
- Anything else you'd otherwise type: a commit message, a comment explaining a workaround, a PR description — hold-to-dictate works anywhere there's a cursor waiting for text.
None of that requires deciding, case by case, whether this particular thought is sensitive enough to type instead of speak. That decision gets made once, by the model you've picked as your default, not every time you hold the key.
On-Device by Default: The Models Doing the Work
When dictation runs locally, it uses one of several open, on-device speech-recognition models from the sherpa-onnx family — options include Parakeet, Zipformer, Paraformer, and Whisper Tiny variants, several of which handle multiple languages, not just English. All of them run entirely on the machine doing the dictating. No audio and no transcript is sent anywhere.
That also means the trappings that usually come bundled with cloud dictation simply don't apply. There's no account to create, no API key to configure, and no network connection required — dictation works the same on a plane with no wifi as it does at a desk with gigabit fiber. Because there's a choice of models rather than one fixed option, you can weigh the trade-offs that actually matter to your machine and your work:
- Speed versus accuracy: a lighter model responds a bit faster and uses less memory; a larger one trades a little latency for better transcription quality.
- Language coverage: some available models are English-only; others handle multiple languages, which matters if you regularly dictate in more than one.
- Machine footprint: you can pick a model that sits comfortably alongside whatever else is running, rather than being handed a single one-size option.
This is what makes offline speech-to-text dictation for coding actually mean something, rather than being a checkbox that exists to satisfy a privacy audit. The models are capable and varied enough that choosing them isn't a compromise made for privacy's sake — for most dictation, they're simply the transcription engine, full stop.
Opting Into the Cloud: GPT-4o and GPT-4o Mini
None of this rules out the cloud. If you specifically want the accuracy or broader language coverage a large hosted model can offer — for a difficult accent, a less common language, or just personal preference — Influxx supports cloud transcription through OpenAI's GPT-4o and GPT-4o mini transcription models. You supply your own OpenAI API key, and that dictation session is transcribed through your account rather than a local model.
The distinction that matters is opt-in versus default. The cloud path exists because some developers will specifically want it, for specific reasons, and there's no benefit pretending otherwise. It just isn't the path you land on by default, and it isn't the only path available.
The Engineering Problem: Instant, Without Reloading a Model Every Time
A local speech-recognition model doesn't load instantly. Reading weights into memory and initializing the model takes real time — enough that if Influxx reloaded the model fresh every single time you held the dictate key, the feature would feel sluggish exactly when it needs to feel instant. Hold-to-dictate is only useful if talking is faster than typing, and a noticeable pause at the start of every dictation would undercut the entire point.
The fix is a background worker thread that runs the local model and stays warm — loaded, initialized, ready to transcribe — for a period of idle time, roughly an hour, after the last dictation. As long as you're actively using dictation within that window, there's no reload cost; the worker is already sitting there waiting. Only after an hour of not being used does Influxx tear the worker down and free the memory it was holding, on the assumption that you've moved on for now.
"Nobody wants to hold a key, talk, and then sit there for a second waiting for a model to wake up before anything happens. But you also don't want a speech model parked in memory forever on the off chance someone dictates again next week. An hour of idle time before we tear the worker down is the balance — instant response for anything resembling a real session, and the memory comes back once you've clearly moved on."
— Marcus Webb, Principal Systems Engineer at ETAPX
What Happens When You Cancel Mid-Sentence
Keeping a worker warm across many separate dictation sessions is what makes the feature feel instant, but it introduces a problem that's easy to miss until it actually happens: the same worker thread has to cleanly separate audio that belongs to one dictation session from audio that belongs to the next one.
Here's the concrete failure case. You hold the key, start dictating, and change your mind partway through — you release the key early, or cancel outright. A moment later, you hold the key again and start a completely new, unrelated dictation. Because the same warm worker is handling both, there's a real risk that a leftover audio chunk from the stopped session is still in flight when the new one starts, and ends up bleeding into the transcription of dictation that has nothing to do with it. Nobody wants a fragment of an abandoned thought showing up in the middle of an unrelated note.
We treat that as a bug class worth designing against explicitly, not an edge case to shrug off. Each dictation session is bounded so that stopping or canceling one clears its in-flight audio before the worker accepts anything new — a stopped session's leftover audio is discarded rather than carried forward, so the next dictation starts clean regardless of how the previous one ended.
It's a small failure mode with an outsized cost. The entire point of hold-to-dictate is trusting that what comes out is what you actually said, and a feature that occasionally splices in a stray phrase from a different session breaks that trust fast.
A Default That Matters More the More Sensitive Your Work Is
None of this is only about individual preference. Developers doing contract or consulting work are often bound by an NDA that makes "where does this audio go" a real question, not a hypothetical one. Teams working under enterprise security requirements frequently can't adopt tools that phone home by default, no matter how good the transcription is. For both, a dictation feature that defaults to local isn't a nice-to-have privacy option — it's the difference between a tool they can use and one they can't.
"I do contract backend work for clients who would not be thrilled about voice recordings of internal discussions going to some third-party API by default. Being able to leave dictation on a local model means I don't have to think about it every time I hit the key — it's just handled."
— Jordan Alvarez, independent backend contractor and Influxx user
That's really the shape of the decision: capable local models as the thing that actually works, day to day, for most dictation — and a cloud option that's there for the developer who specifically wants it, on their own terms, rather than the only door in.
Frequently Asked Questions
Does dictation work without an internet connection?
Yes. The local speech-recognition models run entirely on-device, so hold-to-dictate works with no network connection, no account, and no API key. The cloud path is available if you add your own OpenAI API key, but it's never required for dictation to function.
Which local speech models can I choose from, and how do they differ?
Influxx offers a choice of open, on-device models from the sherpa-onnx family, including options like Parakeet, Zipformer, Paraformer, and Whisper Tiny variants. Several support multiple languages. They differ in speed, memory footprint, and accuracy, so you can pick whichever balance fits your machine and how you work.
Is there any scenario where my audio leaves my machine?
Only if you deliberately switch to the cloud transcription option and supply your own OpenAI API key. In that case, audio for that dictation is sent to OpenAI's GPT-4o or GPT-4o mini transcription models. With a local model selected, nothing about your dictation — audio or transcript — leaves the machine.
Why does the first dictation feel a little slower than the ones right after it?
The local model loads into a background worker thread on first use, which takes a moment. After that, the worker stays warm for roughly an hour of idle time, so every dictation in that window starts instantly. If you step away for longer than that, the worker is torn down to free up resources, and the next dictation pays that startup cost again.
What happens if I release the dictate key early or cancel partway through?
The session ends there, and Influxx guards against that partial audio leaking into whatever you dictate next. Because the same warm worker thread handles back-to-back dictation sessions, we built explicit safeguards so a stopped session's leftover audio can't stick around and contaminate the next, separate transcription.
Do I need an OpenAI account to use dictation at all?
No. An OpenAI API key is only needed if you specifically choose the cloud transcription path for accuracy or language coverage beyond what the local models offer. The default experience — the one most developers will use every day — requires no account of any kind.
Hold-to-dictate is a small feature by surface area: a key, a beep, some text landing where your cursor was. The decision underneath it isn't small — local models as the working default, cloud as an opt-in with your own key, and the unglamorous engineering, a warm worker thread and careful session boundaries, that makes the private path feel as fast as the convenient one. That's the standard we think voice input deserves in a tool built for writing code.
