Murmure: Local Speech-to-Text With Parakeet TDT, Reviewed for Adoption

The problem Murmure targets: dictation without a server round trip

Most dictation tools either send audio to a hosted API or ship a large desktop suite with accounts and sync. Murmure takes the opposite position: the README states that all processing happens locally, that no data leaves the computer, and that there is zero telemetry. The transcription engine is NVIDIA's Parakeet TDT 0.6B v3 model, loaded on-device rather than called over HTTP.

The intended user is someone who already talks to software. The README lists dictating into AI prompts (it names Cursor, ChatGPT, Mistral and Claude code), writing notes hands-free, capturing ideas, and post-processing with a local LLM to translate or fix grammar. That list matters: Murmure is positioned as an input layer for other tools, not as a note-taking application with its own database. There is no account, no sync, and according to the README no network connection is required for the core path.

The language scope is explicit and narrower than the word multilingual suggests. The README enumerates 25 languages, all European: Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Russian and Ukrainian. If your dictation is in Japanese, Mandarin, Arabic or Hindi, this project does not cover you, and the model choice is the reason rather than a configuration gap.

How the local pipeline is put together

What the repository material supports is a desktop application written in Rust that hosts a neural ASR model and writes recognised text into whatever window has focus. The README describes the user-facing flow in one line: launch it, start recording, and text appears processed on your computer. The demo asset in the repository is a .webp animation, so the exact interaction pattern (hold a key, toggle a hotkey, click a button) is not something I can confirm from the supplied text alone.

Two architectural details are visible. First, shortcut handling is delegated to the operating system rather than implemented as a global keyboard hook in every case. On Wayland, the README says KDE Plasma 6, Hyprland and Sway use the xdg-desktop-portal GlobalShortcuts portal with no manual setup, while GNOME defaults to a CLI mode where you must configure a custom OS shortcut yourself. That is a portal-based design, and it explains why behaviour differs between compositors that otherwise look similar.

Second, the audio path has to coexist with other applications. One roadmap entry describes restoring output streams that were recreated or started while dictating, noting that browsers drop and recreate their stream when tabs change, and that the audio server kept a lowered level for the whole application. That entry is a fix, but it reveals the mechanism: Murmure lowers other audio while the microphone is active and then restores it, which means it touches system audio state, not just its own process. Any bug in that restore path is audible to the user.

The post-processing step is mentioned in the feature list and usage notes as something done with a local LLM, to translate or fix grammar. The README does not document which runtime, which model, or which API that step uses, so treat it as an advertised capability whose configuration you must check against the docs site rather than the repository text.

Installing on Windows, macOS and Debian-based Linux

Windows requires Windows 10 or later. The README warns that older versions such as Windows 8.1 are unsupported and may fail with missing system libraries, naming dxcore.dll. Two install routes are documented: download Murmure_x64.msi or Murmure_x64-setup.exe from the releases page, or run `winget install Kieirra.Murmure` from the Console app. The README notes that a `--scope user` flag is planned but not yet available. A separate dependency is the Microsoft Visual C++ Redistributable; if you see an error about MSVCP140.dll, the README points to https://aka.ms/vc14/vc_redist.x64.exe. There is also an antivirus note: some users reported Kaspersky blocking Murmure, and the suggested workaround is an exclusion.

Debian-based Linux has three paths. The quick install is `curl -fsSL https://raw.githubusercontent.com/Kieirra/murmure/main/install.sh | sh`. The package route is downloading Murmure_amd64.deb and running `sudo dpkg -i Murmure_amd64.deb`. The portable route is downloading Murmure_amd64.AppImage, then `chmod +x Murmure_amd64.AppImage` and running it. Note that piping a remote script into sh executes whatever that URL returns at that moment; if that matters to you, download the .deb or AppImage instead and inspect it.

macOS ships as a DMG, with separate builds for Apple silicon (Murmure_aarch64_darwin.dmg) and Intel (Murmure_x86_64_darwin.dmg). You drag the app to Applications, open it from there, grant microphone and accessibility permissions, then restart the app for the permissions to take effect. The README also documents a painful upgrade path for anyone moving from 1.6.0: remove Murmure completely from System Settings, Privacy & Security, Accessibility, then from Input monitoring, install the new version, launch it, re-grant Accessibility, re-grant Input monitoring, and restart. The README's own explanation is that 1.6.0 has the same name but is not detected as the same application. That is a one-time cost, not a recurring one, but it is a real cost.

For fleet deployment there is a CLI import added in 1.8.0: `murmure import config.murmure`, with a `--strategy merge` option to keep existing settings. That is the mechanism to standardise shortcuts and preferences across machines without clicking through each one.

Where Murmure breaks down: GNOME Wayland, languages and model weight

The clearest limitation is documented by the project itself. On GNOME under Wayland, Murmure defaults to CLI mode: you must configure a custom OS shortcut before using it, and push-to-talk is not available. Push-to-talk is the interaction many dictation users actually want, because it bounds the recording window. On GNOME Wayland you do not get it. KDE Plasma 6, Hyprland and Sway get the portal path with no manual setup; GNOME does not. If your team standardises on GNOME, this is a functional difference, not a preference.

Language coverage is the second boundary. The README lists 25 languages, all European. There is no stated plan in the supplied material to extend beyond that set, and the model is named specifically as Parakeet TDT 0.6B v3, so the coverage is tied to that checkpoint rather than to a pluggable model registry. Do not assume you can swap in a different ASR model; nothing in the material describes a model selection interface.

The third issue is less a defect than an unverified assumption. The model is a 0.6B parameter neural network that must be present on the machine. The README says no network connection is required, which is true of the running application, but the first run has to obtain the weights somehow. The supplied material does not describe when or how that download happens, how large it is, or whether it can be pre-seeded for offline or air-gapped deployment. If you are evaluating Murmure for an environment without internet access, that is the first question to answer, and you cannot answer it from the README alone.

Finally, the audio-ducking behaviour described in the roadmap entry is a failure surface. Any application that lowers and restores system output levels can leave them wrong if it exits or crashes mid-dictation. The roadmap shows the maintainers fixing exactly this class of bug for browser streams. It does not follow that the problem is solved for every audio server configuration.

How Murmure differs from whisper.cpp and other local ASR routes

The obvious comparison for a local, offline speech-to-text tool is whisper.cpp, which wraps OpenAI's Whisper models in a C/C++ inference engine and is typically driven from a terminal or embedded in another application. The difference in approach is where the work sits. whisper.cpp gives you a library and a command-line binary; you supply the audio capture, the hotkey handling, the text injection into the focused window, and the packaging. Murmure supplies all of that as a finished desktop application with installers for three platforms and a configuration import command for fleet deployment.

That trade runs both ways. With whisper.cpp you choose the model, including larger ones and non-European language coverage, and you can embed it in a server process or a different UI. With Murmure you get Parakeet TDT 0.6B v3 and 25 European languages, and the integration work is already done. If your requirement is a dictation key that types into whatever window is focused, Murmure is closer to finished. If your requirement is transcription inside your own pipeline, or a language Murmure does not list, whisper.cpp is the more adaptable base and Murmure is the wrong shape of tool.

There is also a licensing difference worth naming before you build on either. Murmure is AGPL-3.0. That licence carries network-copyleft obligations: if you modify Murmure and let users interact with the modified version over a network, the AGPL's source-disclosure terms are designed to reach that deployment. whisper.cpp uses a permissive MIT licence, which does not impose that condition. I am not giving legal advice, and the exact scope depends on how you distribute or host the software, but the two licences are not interchangeable for a commercial product. If you are embedding a dictation engine into a closed-source service, this is the point to involve someone qualified.

Maintenance cost and what the release cadence implies

The release history shows 1.9.0 in late May 2026, 1.10.1 in early July 2026, and 1.11.3 at the end of August 2026, with the last push to main in early September 2026. That is a steady cadence of roughly one to two minor releases per quarter, with patch releases between them. For an application that touches OS-level permissions, global shortcuts and system audio, that cadence is doing real work: the roadmap entries in the supplied material are bug fixes, including the macOS Dock-icon behaviour and the audio stream restore, not new features.

The practical maintenance burden falls on two groups. End users pay at upgrade time, and the macOS 1.6.0 note shows how expensive one upgrade can be when the OS stops recognising the application identity. Administrators pay at deployment time: the `murmure import config.murmure` command with `--strategy merge` is the tool for pushing a standard configuration, and it exists precisely because per-machine setup does not scale. If you manage more than a handful of machines, that command is the difference between a supported rollout and a manual one.

On licensing, the AGPL-3.0 choice is consistent with a privacy-focused desktop tool: it keeps modified hosted versions open. It also means that if your organisation has a blanket policy against AGPL dependencies, Murmure is excluded before any technical evaluation happens. Check that policy first, because it is cheaper than testing an installer you cannot ship. The supplied material does not state whether commercial licensing alternatives are offered, so if you need one, that is a question for the maintainers rather than something you can read off the repository.

Who should adopt Murmure, and what to verify before you do

Murmure fits a specific profile: a single user or a small team on Windows 10 or later, macOS (Apple silicon or Intel), or a Debian-based Linux distribution running KDE Plasma 6, Hyprland or Sway, who dictates into other applications and wants the audio to stay on the machine. It also fits anyone who needs to standardise dictation settings across several machines, because the 1.8.0 CLI import exists for that purpose.

It does not fit GNOME Wayland users who need push-to-talk, since the README states that mode is unavailable there. It does not fit anyone transcribing languages outside the 25 listed. It does not fit a team that needs to embed transcription inside its own service, because Murmure is a desktop application, and the AGPL-3.0 terms would apply to a modified hosted version anyway.

Three checks are worth doing on one machine before you commit. Confirm the Parakeet TDT 0.6B v3 weights are obtained and cached in a way that survives a disconnected restart, since the README's no-network claim describes the running application, not the first run. Confirm your shortcut mode works under your actual compositor, using the Linux installation and shortcut configuration guides the README links rather than assuming the portal path applies to you. And confirm that `murmure import config.murmure --strategy merge` produces the settings you intended on a machine that already has a configuration, because merge semantics are where deployment scripts usually go wrong.

Editorial conclusion

Adopt Murmure if you dictate into local editors or chat windows on Windows 10+, macOS, or a KDE Plasma 6, Hyprland or Sway Wayland session, and you accept AGPL-3.0 terms for any redistribution. Skip it on GNOME Wayland if you need push-to-talk, and skip it if you need languages outside the 25 listed. Before rolling it out, verify three things on one machine: that the Parakeet model weights download and load without a network afterwards, that your shortcut mode works under your compositor, and that the .murmure import with --strategy merge produces the settings you expect.

Official sources

1. Kieirra/murmure on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases