Voxtype: push-to-talk dictation for Wayland compositors

What problem Voxtype solves, and for whom

Linux desktops have had speech recognition for years, but the pieces were separate: a model runner, an audio capture tool, and something to inject text into the focused window. Voxtype bundles all three behind a single push-to-talk gesture. You hold a hotkey while speaking, release it, and the transcribed text appears at your cursor position. The README describes the default hotkey as ScrollLock and notes that the daemon runs in the foreground until you press Ctrl+C.

The intended audience is narrow and specific. The repository topics list accessibility, dictation, gnome, hyprland, kde, sway and wayland, and the README's compositor section covers Hyprland, Niri, Sway, River, GNOME and KDE. If you are on X11, Voxtype still works through an evdev fallback, but that path requires adding your user to the input group and logging out and back in. If you are on Windows or macOS, the README mentions a Homebrew formula for macOS, yet every integration described in detail is Linux-specific.

The privacy stance is explicit rather than implied. The README states that audio stays on the machine until you choose otherwise, with optional remote Whisper servers as an opt-in. That matters for anyone dictating meeting notes, medical text, or anything covered by an internal policy that forbids third-party transcription services.

How the daemon, engines and typing backends fit together

Voxtype is a Rust binary built around an async runtime (tokio appears in Cargo.toml with the full feature set) and cpal for audio capture. When the hotkey fires, the daemon records from the microphone; on release it hands the buffer to the selected transcription engine, then passes the resulting text through a chain of output layers.

The engine layer is the part that changed most recently. The README lists nine engines: Whisper, Parakeet, Moonshine, SenseVoice, Paraformer, Dolphin, Omnilingual, Cohere and OpenVINO Whisper. Cohere Transcribe is described as quantized to 1.5 GB (q4f16) and running at 9-11x realtime on a Zen 4 CPU, with punctuation, capitalization and inverse text normalization handled by the model itself. Parakeet runs on AMD and NVIDIA GPUs, with MIGraphX 7.2 for Radeon and separate CUDA 12 and CUDA 13 binaries. OpenVINO Whisper targets Intel NPU, CPU or GPU, and the v1.1.0-rc5 release notes name OpenVINO NPU support explicitly. The repository carries one Dockerfile per backend (Dockerfile.onnx-cuda-12, Dockerfile.onnx-cuda-13, Dockerfile.onnx-migraphx, Dockerfile.vulkan, Dockerfile.avx512 and others), which is a reasonable signal of how many build targets the project maintains.

Memory is managed by loading models on first use and unloading them when idle, so configuring several engines does not mean paying for all of them at once. That design is what makes the nine-engine list practical rather than aspirational.

Output is where the Wayland constraint shows. The README describes a fallback chain: wtype first, then dotool, then ydotool, then the clipboard if none of those can type. wtype is the only layer the README credits with full CJK support. If you end up on the clipboard path, the text is not inserted at the cursor; you paste it yourself. That is a functional difference, not a cosmetic one, and it is the first thing to check if output looks wrong.

Installing Voxtype and dictating your first sentence

The README states that most users should install a pre-built package and points to docs/INSTALL.md, with AUR packages voxtype and voxtype-bin, plus voxtype-bin-rc for pre-release builds, alongside .deb, .rpm and Homebrew on macOS. The source build below is what the README documents for people who want to compile it themselves.

Install the build dependencies for your distribution first. The README gives Fedora, Arch and Debian/Ubuntu commands; the Fedora set is shown here.

sudo dnf install rust cargo alsa-lib-devel clang-devel cmake pkgconf

Then build the release binary and install the Wayland typing backend. wtype is the layer the README credits with full CJK support.

cargo build --release
sudo dnf install wtype

Download a model before the first run. The setup subcommand fetches what the default configuration expects.

./target/release/voxtype setup --download

Wire the hotkey into your compositor. For Hyprland, the README's snippet uses two bindings: one fires on press, one on release.

bind = SUPER, V, exec, voxtype record start
bindr = SUPER, V, exec, voxtype record stop

Start the daemon and dictate. It runs in the foreground, so keep a terminal open or launch it from your session startup.

./target/release/voxtype

Hold the hotkey, speak, release. The README says text appears at your cursor, or in the clipboard if typing is unavailable. If you are not sure which desktop you are on, the README suggests running echo $XDG_CURRENT_DESKTOP, which typically prints Hyprland, sway, river, KDE or GNOME.

The KDE key-release problem and other real limits

The sharpest limitation is stated plainly in the README: KDE does not support key-release events, so push-to-talk is not available there. KDE users must configure a Custom Shortcut in System Settings and point it at voxtype record toggle, then disable the built-in hotkey in config.toml. That is a different interaction model, and it changes how you dictate: a tap to start, a tap to stop, with no way to hold a key and have recording end on release.

# ~/.config/voxtype/config.toml
[hotkey]
enabled = false

A second documented failure mode concerns multi-modifier bindings. The README warns that on Omarchy and similar setups, releasing keys slowly can cause the typed text to trigger window manager shortcuts instead of inserting text. The fix lives in the troubleshooting guide under Modifier Key Interference, which the README points to rather than reproducing. A user hitting this will need to read that page; the README alone is not enough.

The typing backend is a third constraint. wtype is listed first, and the fallback chain ends at the clipboard. If your compositor or keyboard layout is not served by wtype, dotool or ydotool, you get clipboard output. Nothing in the README suggests a workaround for that beyond installing the earlier layers.

Finally, the release tags matter. The three most recent releases are v1.1.0-rc3, v1.1.0-rc4 and v1.1.0-rc5, all dated September 2026. The AUR package voxtype-bin-rc exists specifically for testers who want pre-release builds, per the README. A stable 1.0.1 version appears in Cargo.toml, so the rc line is ahead of the packaged stable version. Anyone who needs predictability should install the stable packages rather than the rc channel.

How Voxtype differs from a plain whisper.cpp setup

whisper.cpp is the obvious comparison, and the difference is architectural rather than a matter of model quality. whisper.cpp gives you a library and a CLI that turns an audio file into text; it does not capture from your microphone, does not bind a hotkey, and does not insert output into a focused window. Wiring those three pieces together is left to you, usually as a shell script plus a compositor binding plus something like wtype or ydotool.

Voxtype takes that assembly and ships it as one daemon with a TOML config and an interactive TUI. The README describes voxtype configure as editing every option in ~/.config/voxtype/config.toml for you, auto-downloading missing models, swapping GPU binaries via pkexec, and restarting the daemon when needed. It also surfaces in Walker, fuzzel and rofi. That is the value proposition: not a better model runner, but a packaged dictation loop.

The trade-off is that Voxtype embeds its own engine layer instead of being a thin wrapper. It carries nine engines, each with its own build target and model download, and the repository reflects that with a Dockerfile per backend. If you already have a whisper.cpp pipeline tuned to your hardware and your scripts, Voxtype adds a layer you would have to learn and configure. If you want dictation working this afternoon without writing the glue, that layer is the point.

Voxtype also does things whisper.cpp has no opinion about. It pauses MPRIS-speaking media players such as Spotify and Plasma media players when dictation starts and resumes them on release, and it draws a floating waveform OSD that matches the swayosd band by default. Those are desktop integration features, and they only make sense in a daemon that already owns the microphone.

Meeting mode, text processing and licence terms

Meeting mode extends the daemon beyond single utterances. The README describes continuous transcription with chunked processing, speaker attribution, and export to Markdown, JSON, SRT or VTT. The usage section shows voxtype meeting start --title "Weekly standup" and voxtype meeting status, with a stop command that the truncated README cuts off mid-sentence. If you need artifact files rather than text at a cursor, this is the mode to read up on.

Text processing happens between transcription and output. The README lists spoken punctuation ("comma" becomes a comma), per-user replacement tables for common mistranscriptions, and an optional post-processing pipe through any LLM or shell script. The examples directory backs this up with scripts: gemini-cleanup.sh, ollama-cleanup.sh, openai-cleanup.sh and swedish-chef.sh. The first three are exactly what the name suggests, and the fourth is a novelty filter. The point is that the pipe is generic, so cleanup is a script you control rather than a feature the project has to implement.

Licensing is MIT, stated in both the README and Cargo.toml. The repository also carries a THIRD_PARTY.md file, which is where the obligations of the bundled model runtimes and libraries would be recorded. MIT on the project itself does not automatically settle the terms of every engine you enable, particularly the ones distributed as separate GPU binaries. If you are packaging Voxtype for redistribution, read THIRD_PARTY.md rather than assuming the top-level licence covers everything.

Upgrade cost is mostly model and binary churn. The README notes that voxtype configure can swap GPU binaries via pkexec and restart the daemon, which suggests upgrades are intended to be handled through that path rather than manual file replacement. The rc channel exists for people who want to track changes before they land in a stable package.

Editorial conclusion

Adopt Voxtype if you already run a Wayland compositor with native keybindings and want dictation that never leaves the machine; the README's compositor snippets for Hyprland, Sway and River are the fastest path to a working setup. Skip it if you are on Windows, or if your desktop cannot deliver a key-release event, because KDE has to fall back to toggle mode and the built-in hotkey is the only other route. Before committing, check three things: which typing backend is present (wtype, then dotool, ydotool, then clipboard), which engine and model size your CPU or GPU can actually run, and whether the release you install is an rc build, since the most recent tags are v1.1.0-rc3 through v1.1.0-rc5.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. peteonrails/voxtype on GitHub
4. README
5. Releases