Voquill: dictation into any desktop app, with the transcript cleanup left to you

The problem Voquill targets: dictation that stops at the app boundary

Most speech-to-text tools produce a transcript inside their own window. You speak, the text appears, and then you copy it somewhere. Voquill's stated goal is the opposite arrangement: the README describes an overlay, hotkeys and system integrations that let you dictate into any desktop application, with macOS, Windows and Linux listed as supported. That is the whole pitch, and it is a narrower one than it first appears. The project is not trying to be a transcription API or a meeting recorder. It is trying to be the keyboard replacement layer that sits above whatever application currently has focus.

The audience follows from that. Someone who writes long prose in an editor, answers tickets all day, or dictates clinical or legal notes into a system they cannot modify gets value from an overlay that never asks them to switch windows. Someone who needs batch transcription of recorded audio files, or speaker diarisation, or a server-side pipeline, is looking at the wrong project. The repository does contain mobile apps and an enterprise service alongside the desktop app, but the README's framing is consistently about voice as an input method rather than voice as a processing service.

Two engines, an overlay, and a cleanup pass between them

The mechanism the README describes has three stages. Audio is captured through the overlay or a hotkey. It is transcribed either by a local Whisper model, which the README says can use optional GPU acceleration, or by a cloud provider you select. The resulting text then passes through an AI cleanup step that removes filler words and false starts before it is inserted into the focused application.

That middle stage is where the project's configuration surface lives. The Providers screen, shown in the screenshots table, is described as bring-your-own-API-key, with separate choices for transcription and post-processing. So transcription and cleanup are independently swappable. You could run Whisper locally for the audio and send the text to a cloud model for cleanup, or do both remotely, or keep both local. The README does not enumerate which providers are supported, and that is a real gap: the set of integrations is the single most important fact for anyone evaluating this, and it is not in the README.

The dictionary and writing styles sit on top of the cleanup pass. Writing Styles are described as tones such as Polished, Verbatim and Chat that control how your voice sounds on the page. The Dictionary holds glossary terms and replacement rules so recurring names and phrases stay accurate. Both are post-processing controls, which means the quality of your output depends on how much of this you configure. A fresh install is not the intended end state.

What the repository layout tells you about scope

The README states plainly that the repository contains the desktop and mobile apps, a documentation site, enterprise services, a CLI, and shared packages. That is a monorepo with more than one product in it, and the release list confirms it. Three release tags were cut on the same day: desktop-v0.0.651, desktop-dev-v0.0.651, and desktop-enterprise-dev-v0.0.37. The enterprise channel is versioned separately and sits at a much lower number, which suggests it is on a different track rather than simply lagging.

For an adopter this matters in a practical way. The desktop-dev tag moving in lockstep with the desktop tag means there is a development channel published alongside the stable one. The README mentions Tauri auto-updates as a bundled feature. If you install the desktop build, you are on a channel that ships frequently, and the version number 0.0.651 is honest about where the project considers itself. Anyone who needs to pin a version and audit changes between upgrades should look at the dev and enterprise-dev tags before assuming the stable tag is the conservative choice.

The primary language is TypeScript, which fits the Tauri stack: a Rust shell with a TypeScript front end. The README does not break down which parts are Rust and which are TypeScript, so treat any assumption about where the native code ends as unverified.

Getting it running: what the README does and does not give you

The README does not contain install commands, configuration keys, or a build recipe. It points to docs/getting-started.md for setup instructions and architecture details, and to voquill.com for the product. That is the honest state of the supplied material, and it means the first thing to read is that getting-started document, not this review.

What the README does establish about running it: you choose a transcription engine (local Whisper with optional GPU acceleration, or a cloud provider), you supply your own API key on the Providers screen, and you can run Voquill against any backend you wish, including offline. Those are the three configuration decisions that determine whether the tool works for you. The offline claim is the strongest of them, because it implies the local Whisper path plus local cleanup is a supported combination rather than a degraded one.

If you are evaluating rather than installing, the screenshots table is the most useful part of the README. It names six surfaces: Home, History, Writing Styles, Dictionary, Providers and Chats. History is described as including full audio playback of past transcriptions, which is a detail worth noting for anyone in a regulated environment, because it means recordings are retained locally by default unless that is configurable. The README does not say whether retention can be disabled.

Where Voquill is the wrong tool

The most obvious limitation is the absence of a stated system requirements list. The README claims macOS, Windows and Linux support and mentions optional GPU acceleration for Whisper, but it does not say which Whisper model sizes are available, how much memory they need, or which GPU backends are supported. On a machine without a usable GPU, the local path may or may not be practical, and nothing in the supplied material settles it. If local-only operation is a hard requirement for you, that is the first thing to verify, not the last.

A second limitation is the dependency on a cloud provider for the parts you do not run locally. The README's privacy claim is that you have full control over your data and can run against any backend, even offline. That is a statement about capability, not about defaults. The AI cleanup step is only local if you configure it that way. A user who installs Voquill and points it at a cloud provider for cleanup is sending their dictated text, including anything the dictionary did not catch, to that provider. The README does not describe a data flow diagram or a list of what leaves the machine in each configuration.

Third, this is not a transcription service. There is no documented API for submitting audio files and retrieving transcripts, no batch mode, and no diarisation. The CLI is mentioned in the repository contents but its purpose is not described in the README. If your problem is processing recordings rather than replacing a keyboard, Voquill's overlay-and-hotkey architecture is solving a different problem.

How it compares to running Whisper yourself

The real alternative is not another dictation app. It is the combination of a Whisper implementation such as whisper.cpp or faster-whisper with a small script that pipes the transcript into your clipboard or the focused window. That approach gives you the model, the quantisation choice and the audio pipeline directly, with no overlay, no account, no provider configuration and no auto-update channel.

The difference is the part you would have to build. Voquill's contribution is the integration layer: a cross-platform overlay that inserts text into arbitrary applications, a hotkey system, a history view with audio playback, a glossary with replacement rules, and a set of writing-style presets. Doing that yourself across three operating systems is a substantial amount of work, and it is the work that most people underestimate when they decide to wire up Whisper on their own. The trade is control for effort. Running whisper.cpp directly means you know exactly which model is loaded and exactly where the audio goes. Voquill means you get the desktop integration but you inherit its provider abstraction and its release cadence.

There is a middle position worth naming. If you only need cleanup and not dictation, a general-purpose LLM API with a prompt that strips filler words covers the post-processing half. Voquill bundles that with the capture and insertion layers, which is the reason to choose it over assembling the pieces.

Licence, release cadence and what maintenance actually costs

The README states that unless otherwise noted, Voquill is released under AGPLv3, and points to a LICENCE file that also contains third-party attributions. Repository metadata reports the licence as NOASSERTION, which is a mismatch worth understanding before you build on it. The practical consequence of AGPLv3 is that if you modify Voquill and let users interact with it over a network, the copyleft obligations extend to that interaction. Running the desktop app for yourself does not trigger that. Embedding Voquill in a product you distribute, or hosting a modified version, is a different situation, and the third-party attributions in the LICENCE file matter because the speech models and any bundled components may carry their own terms. This is not legal advice; read the LICENCE file and the attributions before you ship anything.

The maintenance picture is dominated by the release cadence. Three tags in one day, with the desktop version at 0.0.651, indicates a project that ships continuously and does not treat version numbers as stability promises. Tauri auto-updates mean installed clients will follow that cadence unless you disable them. For an individual user that is fine. For a team that needs to validate each build, it means either pinning versions and forgoing updates or accepting a moving target.

The upgrade cost is mostly configuration drift. Provider APIs change, model names change, and the Providers screen is where that surfaces. Your dictionary and writing styles are the durable part of your setup; the provider configuration is the part that will need attention. Budget for that rather than assuming a one-time setup.

Who should install it, and what to check first

Voquill is worth installing if you dictate into applications you cannot extend, you are comfortable supplying your own provider key or running Whisper locally, and you want the glossary and writing-style controls rather than a bare transcript. The overlay and hotkey design is the reason to pick it over a standalone Whisper script, and the offline path is the reason to pick it over a hosted dictation service.

It is the wrong choice if you need documented system requirements before you commit, if you need a stable release channel with a slow cadence, if your use case is batch transcription rather than live input, or if AGPLv3 does not fit how you intend to distribute the result. The NOASSERTION metadata and the absence of a provider list in the README are both things to resolve by reading the repository directly, not by trusting a summary.

Three concrete things to check before you install. Open docs/getting-started.md and confirm the setup steps match your platform and that the architecture section explains where audio is processed. Open the Providers screen documentation or source and confirm the transcription and post-processing providers you already pay for are supported, since the README does not list them. Then open the LICENCE file and read the third-party attributions, because the speech models are the component most likely to carry terms that differ from the AGPLv3 grant covering the application code.

Editorial conclusion

Adopt Voquill if you want dictation that reaches every desktop application through an overlay and hotkeys, and you are willing to supply your own transcription or post-processing provider key. Do not adopt it if you need a written compatibility matrix, a stable release channel, or a permissively licensed codebase you intend to embed in a closed product, since the README states AGPLv3 and the repository metadata reports NOASSERTION. Before committing, verify three things in the repository: which models the local Whisper path actually downloads, what the desktop-enterprise-dev release channel contains, and whether the LICENCE file's third-party attributions cover the speech models you plan to run.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. voquill/voquill on GitHub