OpenLess: hold a hotkey, speak, and get AI-polished text at your cursor

The coordination tax OpenLess is trying to remove

Most dictation tools stop at the transcript. You speak, words appear, and you still spend the next minute fixing tone, spelling names, and deciding where the text should go. OpenLess targets that second half. The project describes itself as a cross-platform voice-input application and positions the AI-prompt mode as its headline capability: you speak freely and the app adds structure, captures your constraints, and produces a prompt you can paste into ChatGPT, Claude, or Cursor.

The README frames this as eliminating coordination between a thought and clean text, and lists four things it turns into defaults: tone becomes a named style pack, proper nouns become dictionary hotwords, insertion becomes a single hold-speak-release protocol with a clipboard fallback, and model credentials become an OS vault entry authorized once at launch. That framing is more marketing than mechanism, but the underlying list is concrete. The intended user is someone who already dictates into several apps and is tired of re-deciding tone and re-correcting the same names every session.

Hold, speak, release: what happens between the hotkey and the cursor

The documented flow is short. You place the cursor in any text field, press a single global hotkey, speak, and release. OpenLess records the audio, transcribes it, polishes the text in the mode you selected, and inserts the result at the cursor. If insertion is blocked, the text goes to the clipboard instead, so nothing you said is lost.

The README does not spell out the audio pipeline, the ASR engine, or which model performs the polish. What it does say is that dictionary hotwords are recognized by the ASR and hinted to the polish model, which implies two stages that both receive the hotword list. Credentials live in the OS vault and are authorized once at launch, alongside microphone and accessibility permissions. So the architecture is a desktop shell over a local recorder plus at least one cloud call. The repository layout is consistent with that: openless-all/ holds the app, with a src-tauri/ directory for the Tauri 2 backend written in Rust, and docs/, USAGE.md, and Examples/ sit alongside it. There is also an Examples/polish-reference-examples.sample.jsonl file, which suggests the polish step is steered by example pairs rather than only by a system prompt. The README does not document the format of that file.

Installing OpenLess and getting one polished sentence into a field

The README points to the releases page for downloads and to openless.top as the official site. There are no build-from-source instructions in the README, so the path below is the packaged one.

First, download the release asset for your platform. The badges list macOS 12+ and Windows 10+, and the recent releases carry a -tauri suffix, so pick the current v1.3.18 line rather than an older artifact.

# open the releases page and pick the asset for your OS
# macOS 12+ or Windows 10+
https://github.com/Open-Less/openless/releases/latest

On first run the app asks for microphone, accessibility, and cloud credentials, which the README describes as authorizing the infrastructure once at launch. Grant the microphone and accessibility permissions, then enter the model credentials the app requests. Nothing in the README lists the exact provider names, so treat this as the step where the app tells you what it needs.

Then open any text field, hold the global hotkey, say a sentence, and release. The polished text should appear at the cursor; if the field blocks insertion, the same text lands on the clipboard. Before you judge the output, set up the two things the README treats as defaults: a style pack for the tone you want, and dictionary hotwords for the names you keep re-correcting. The README does not document the exact UI path for either, so check USAGE.md in the repository.

Where OpenLess gets in the way

The beta branch is the default branch, and the most recent releases are labeled Beta. If you want a channel that does not change under you, that is a reason to wait rather than a reason to avoid the project entirely.

The polish step is the bigger constraint. Because credentials are authorized at launch and stored in the OS vault, the pipeline is not offline: your speech leaves the machine for transcription and again for polishing. The README does not document a local-only mode, and it does not document rollback, so an upgrade that changes the polish behavior is not something you can undo from the app. That matters most for people dictating into regulated or client-confidential documents, where a cloud polish step is a policy problem rather than a latency problem.

Insertion is the third failure mode. The clipboard fallback is a reasonable design, but it is a fallback, not a fix: in applications that block synthetic input, every dictation ends with a manual paste, which removes most of the speed advantage. The README does not list which applications fall into that category, so you have to test your own set.

How OpenLess differs from Whisper-based dictation tools

Superwhisper and similar tools are built around a speech-recognition model and a transcript. You speak, the model emits text, and any rewriting is a separate step you configure or perform yourself. OpenLess inverts the emphasis: transcription is the input to a polish stage, and the project's own framing is that this is the difference between a word-for-word transcript and a context-rich prompt.

The practical consequence is where your configuration effort goes. With a Whisper-style tool you tune the recognizer: model size, language, punctuation. With OpenLess you tune the style pack and the hotword dictionary, because those are what the polish stage consumes. The trade is control for consistency. A recognizer-level tool gives you raw output you can trust or correct; OpenLess gives you output that has already been rewritten, which is faster when the style matches and harder to debug when it does not. The README does not publish accuracy or latency comparisons, so the only honest way to choose is to run both on your own vocabulary.

Licence, maintenance, and what an upgrade costs

OpenLess is licensed under AGPL-3.0. That is a copyleft licence with a network clause, and it is more restrictive than the MIT or Apache-2.0 terms typical of desktop utilities. If you fork the app and offer it as a service, the AGPL's source-availability obligation is the part to read closely. If you only run the packaged binary for personal dictation, the licence mostly does not change your day. This is not legal advice; check the LICENSE file and your own counsel for anything commercial.

The repository is not archived, and the last push was on 2026-09-09, so the project is being worked on. The release cadence in the repository is dense: v1.3.18-tauri on 2026-08-21, two Beta.6 and Beta.7 builds the same week and shortly after, and the most recent tag is v1.3.18-Beta.7-tauri from 2026-08-24. That cadence is the upgrade cost. There is a RELEASING.md in the repository for maintainers, but the README does not document a downgrade path or a pinning mechanism for users, so the realistic upgrade policy is to install a tagged release and keep the previous installer until the new one has survived a week of your own dictation.

Editorial conclusion

Adopt OpenLess if you dictate into many different apps and want the polish step and the insertion step handled by one hotkey, and if you are willing to build a style pack and a hotword dictionary before judging output quality. Do not adopt it if you need a stable channel rather than a beta branch, or if you want a fully offline pipeline, because the polish step depends on cloud credentials. Before installing, check the release notes for the build matching your OS, confirm which ASR and model providers the app authorizes at launch, and read USAGE.md for the hotkey and insertion behavior.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Open-Less/openless on GitHub
3. Project website
4. README
5. Releases