What our run establishes
Our run took place on September 27, 2026, at commit 8f9cf53. Our stored harness summary records a 52-second install and a 20-second build. The matching sandbox record captures command success, exit codes, elapsed time, timeout status, and output tails. Installation and build each returned exit code zero and neither timed out.
The build tail identifies the command as tsc && vite build. That supports a frontend compilation result. It does not establish that a desktop installer was built or that dictation worked. Our run did not launch a graphical desktop, exercise microphone permissions, download a speech model, or measure recognition accuracy, transcription latency, shortcuts, or pasting into another application.
The stored dependency footprint is 432 packages and 254 MB. Bun's output tail instead says "345 packages installed [36.24s]". Likewise, the harness records 20 seconds for the build step while Vite reports 3.62 seconds for its own phase. Keep these reporting scopes separate: the attached stored parser summaries are the figures used here, and their counts have not been reconciled against complete logs. They do not establish exhaustive unique test coverage.
MrKeyoor's testing methodology explains the site's approach to command outcomes and its limits. That page describes the publisher's current procedure; it does not establish which methodology version governed this September run. This correction uses the existing record and includes no new execution.
Tests were skipped despite detected test scripts
The harness recorded a skipped test step with reason "no script". Its own detection data lists test:keyboard, test:playwright, and test:playwright:ui, as well as a tests directory. The supported conclusion is that this harness did not select and execute those commands. There is no passing or failing test result to report.
The detected CI workflows also do not show what passed in this sandbox. Audit data is null, and scan coverage is unknown. This record supplies no dependency-security conclusion.
Local dictation still needs a desktop check
According to the Handy README, you press a shortcut, speak, and receive transcribed text in the active application. The project describes the transcription process as local, using Silero for voice activity detection and Whisper or Parakeet for recognition. This is the capability that makes Handy worth considering for writing email, messages, or documents without sending audio to a hosted transcription service. We did not independently verify network behavior.
A model download is separate from the development dependency footprint. The README lists Whisper and Parakeet files ranging from 487 MB to 1,600 MB and provides manual installation instructions for restricted networks. Those are documented download sizes, not measurements from our sandbox.
After installation, check a short phrase and a longer sentence in each application you rely on. Confirm that the beginning and end of the recording survive and that the correct text reaches the intended field. These are recommended checks, not outcomes from our run.
Linux requires display-server-specific setup
The README recommends xdotool for X11 and wtype or dotool for Wayland text input, with a separate Ubuntu 26.04 note directing users to configured ydotool. It also says Wayland system shortcuts must be configured through the desktop environment or window manager. Choose your setup instructions by session type rather than assuming one Linux installation path covers every desktop.
The recording overlay is disabled by default on Linux because some compositors give it focus, preventing a paste into the original application. Linux also requires the gtk-layer-shell runtime library. These documented constraints matter more to a dictation decision than a successful frontend build.
The README's clipboard troubleshooting explains another receiving-application dependency: Handy can restore the previous clipboard before an application reads the transcription. It documents experimental Reliable Paste on macOS and Windows and separate delay controls for the standard paste path. Test the receiving application before relying on either workaround.
Choose an alternative by the output you need
Buzz supports file transcription, live microphone transcription, and TXT, SRT, and VTT export. Choose it when managing transcripts or subtitle files is the main task. Its microphone support means it should not be described as a file-only tool. It can complement Handy when you need both desktop dictation and a separate transcript workflow; the supplied Buzz extract does not establish an equivalent paste-into-any-application workflow.
nerd-dictation is a Linux dictation utility using VOSK-API with Python configuration. Choose it instead when you want to bind begin and end commands yourself and manipulate recognized text in Python. It is a closer replacement for a Linux dictation workflow, but it still requires recording and input-simulation tools. Its documentation does not justify treating it as a way to avoid all desktop setup.
How to read the ratings
These are editorial assessments, not benchmark results. For each dimension, 1 means substantial documented obstacles, 2 means major gaps, 3 means usable with notable qualifications, 4 means strong documented support with specific limits, and 5 means unusually complete evidence within that dimension's stated scope. Unknown evidence receives no numerical rating.
Setup ease assesses the documented packaged installation route, not a successful desktop installation in our sandbox. Documentation assesses the specificity of setup and troubleshooting instructions. Community assesses visible contribution routes and participation in the supplied release, not user adoption or support response times. Maturity assesses documented release and recovery practices, not proven reliability across hardware.
The retained setup score of 4 reflects packaged installation instructions alongside model, permission, and Linux requirements. Documentation receives 5 for detailed platform, model, paste, and recovery guidance. Community receives 5 within the narrow participation rubric because the supplied v0.9.7 release names multiple contributors and first-time contributors, while the README provides contribution routes. Maturity receives 4 for documented releases and troubleshooting, qualified by platform limitations and the absence of desktop runtime testing here.
Start with the packaged app
The build instructions require Rust, Bun, Tauri prerequisites, and platform-specific tooling. They also explain why a raw Linux binary needs accompanying resources and why Windows release bundling can encounter signing configuration intended for project CI. A source build is useful for development, but it adds work beyond evaluating the app.
The supplied v0.9.7 release lists fixes for lost tail audio and GNOME Wayland clipboard pasting. Those release notes describe changes, not successful checks on your machine. Start with a packaged release and verify the complete recording-to-paste path before using Handy for consequential text.