Voxera
Voice input for desktop and coding agents
Press a global hotkey, speak, and the text lands where you were already typing — an editor, a terminal, a prompt to a coding agent. Recognition goes to a local engine or to a cloud engine you configured yourself; delivery goes to the focused input, or to a bridge that listens only on 127.0.0.1.
There is no download on this page
The project is early. Milestone M0 — infrastructure — is in progress: there is no release, and there is no public repository, because the repository address and its visibility have not been decided. So this page carries no version number, no install command, and no button that does nothing when you press it. What it carries instead is the design record: where the boundaries were drawn, what data leaves the machine in which mode, and why it deliberately refuses to be three things it looks a lot like.
- The workspace libraries, a headless CLI (list engines, run a staged benchmark, run the text post-processing rules on their own), and the repository’s own check scripts.
- The desktop UI code and the packaging path exist, but the repository is not public and has never produced an installable release artefact.
- Roadmap items are not presented as existing features. A phone acting as a LAN thin microphone is a designed shape, not something you can use today.
Three steps, one straight line
No wake word, no conversational turns, no intermediate state waiting for you to confirm. A dictation begins at the keypress and ends when the text lands.
Capture
One global hotkey, pressable anywhere in the desktop session. CPAL opens the device; a VAD cuts out the part where you were actually speaking.
Recognise
Handed to a local offline engine — sherpa-onnx against models on disk — or to a cloud engine you configured yourself. Both are first-class paths: local is not what happens when the cloud is unavailable.
Deliver
The text lands in whatever input has focus, or goes to an agent bridge that listens only on 127.0.0.1. Replacement rules and hotwords have already run by then.
Three things it deliberately is not
Read "voice input" and most people picture one of the three below. Voxera is none of them. That is not unfinished work — the boundary was drawn somewhere else, and each choice carries a cost.
Not a voice assistant
No wake word, no intent parsing, no acting on your behalf. It turns what you said into text and then lets go. Deciding what to do with that text is your job, or the job of the agent you handed it to.
Not a meeting recorder
It does not sit there recording, does not diarise speakers, does not summarise. One dictation is one deliberate keypress worth of speech — measured in sentences, not hours.
Not an input method
It does not register itself as an IME on any platform: no InputMethodService on Android, no keyboard extension on iOS, and no entry in the system’s keyboard or input-source list. It uses the synthetic-input and clipboard paths available to an ordinary application.
That last one is not a wording choice; it has a price. Anywhere that only accepts a real input method will not receive its text — a window running at higher integrity than Voxera on Windows being the clearest case. What it buys is that Voxera never needs system-level input trust and never takes over the typing experience you already have. The cost is stated here, not buried at the end of a doc.
What leaves this machine, in which mode
Only one of the modes below genuinely sends nothing. Saying that plainly matters more than saying it nicely. The rows are ordered on one axis — transmission. Which mode you are in follows from settings you chose, and the interface shows it while a dictation is running.
Local recognition
Nothing
No audio, no transcript, no metadata. Recognition happens inside the Voxera process against model files on disk; once the models are installed this path needs no network at all and works with the link down. The single network operation is the model download before your first dictation, verified against a hash compiled into the binary.
Cloud recognition
Audio + model id + your credentials
Sent to the one provider you selected — OpenAI, Groq, DashScope, VolcEngine, or a custom endpoint whose address you supply. If you configured hotwords and that provider supports biasing, the list goes along as prompt text. There is no server operated by Voxera anywhere on this path, and no mode that sends audio to a provider you did not configure. Each provider’s retention policy is recorded in the project docs as a verbatim quote, with a source URL and a read date.
LLM polish (off by default)
Transcript text, no audio
The text after the rule chain, plus a chat model id and credentials, sent to the OpenAI-compatible chat endpoint you configured. Off by default, and the default is the point: it adds latency and moves text off the machine. The recipient is whoever runs that address.
Three more decisions that live in the defaults: history is off, and once on it stays local with both a count and an age ceiling — 500 entries or 30 days, whichever comes first — while anything typed in an input the system marks as secure never reaches disk at all; the agent bridge listens only on 127.0.0.1 and accepts nothing from the LAN; credentials live in the OS keychain, referenced from config by label alone.
Not a settings page full of switches
The four things you reach for repeatedly are each something you can write yourself, read back, and switch off.
- A custom chain of text substitutions that finishes before the text lands. You say the spoken form; what arrives is the spelling you specified — project names, function names, internal abbreviations, without fixing them by hand every time.
- A word list you maintain. The local engine uses it for biasing; if a cloud provider supports biasing, the same list goes along as prompt text.
- Off by default. Once on it is written locally only, bounded by both an entry count and an age, and content from inputs the system marks as secure — password fields and the like — never enters that path.
- A headless CLI: list the engines that are configured and resolvable, run staged timings, run the text post-processing rules without touching audio. Results on stdout, diagnostics on stderr, exit codes you can branch on — where 3 means specifically "a precondition is missing" and is kept distinct from 1, a runtime failure.
One Rust workspace, with the boundaries enforced
The split is not about looking tidy. Each line is a dependency edge that, once crossed, would make one side heavier, slower, or aware of something it has no business knowing.
- voxera-audio
- Capture and voice activity detection. CPAL for the device, a VAD for the speech.
- voxera-asr
- Recognition engines. The local path runs sherpa-onnx against models on disk; the cloud path is one adapter per provider.
- voxera-pipeline
- Everything between a keypress and a piece of text: capture, recognition, replacement rules, hotwords, the delivery decision.
- voxera-bridge
- The local bridge. Axum plus WebSocket, bound to 127.0.0.1; QUIC and mDNS sit alongside for the designed phone-companion shape.
- voxera-cli
- The headless entry point. Verifies the whole pipeline on a machine with no desktop session, and is the end an agent automates against.
- apps/
- Desktop and mobile. Platform integration lands on the Windows API, macOS AppKit and X11 respectively.
The dependency edges the phone side is not allowed to have are written down in the architecture doc and guarded by a check script — crossing one fails CI rather than earning a comment in review. In the same spirit, the prebuilt sherpa-onnx libraries the local engine needs come from a SHA-256 manifest committed to the repository, not from a fetch at build time.
Stack
- Rust · Tauri 2 · React 19 · Vite · Tailwind 4
- CPAL · VAD · sherpa-onnx
- Axum · WebSocket · QUIC · mDNS · SQLite
- Windows API · macOS AppKit · X11
The inconsistencies, stated
Cross-platform does not mean identical everywhere. Three known differences that will not be smoothed over with wording.
- Wayland has no cross-compositor global-shortcut protocol that reports both the press and the release edge, so there is no push-to-talk on Wayland — only press once to start, press again to stop. That is not a setting, and not a defect this project can fix locally.
- UIPI does not let a medium-integrity process send input to a high-integrity window, and Voxera will not request elevation to work around it. It surfaces a message that names UIPI and keeps the text in history and the staging area instead of failing silently.
- The benchmark’s staged mode reports diagnostics. End-to-end latency only becomes meaningful once the delivery layer is finished, and until then the mode refuses to print a number rather than returning something that looks like a conclusion.
The application and the adapters are split
The two layers get used differently: one is a program you install, the other is a few dozen lines of glue you paste into your own agent configuration. So the licences are split too.
- The GNU Affero General Public License, version 3 only, distributed with the repository complete and unmodified.
- The MCP stdio bridge adapter script, the OpenCode plugin, and the Claude Code hook script. The dual licence has a specific purpose: they can be embedded directly in your own agent configuration without the AGPL reaching your work.
- Because Voxera interacts with users over a network, section 13 applies: the running bridge serves the corresponding source offer on GET /source, and the phone side shows the same entry point on its about screen.
- Each keeps its own licence and does not become AGPL by being used alongside Voxera.
When the repository is settled, this page grows an install section
Until then it is a design record. Every claim above traces to the project’s own README and architecture docs — nothing here was written for this page, including the parts that do not flatter it: no push-to-talk on Wayland, no delivery into elevated windows on Windows, no end-to-end latency number today.