opentypeless: an open source alternative to Wispr Flow and Superwhisper

Voice input that rewrites, not just transcribes

OpenTypeless is described as an open source alternative to Wispr Flow and Superwhisper for AI voice input, rewriting and voice Q&A on macOS, Windows and Linux. The workflow it promises is a hotkey press, natural speech, and clean text in the application you are already in, with the alternative of asking a one-shot voice question and getting a concise answer without opening a chat application.

The stack explains a lot about what kind of application this is. The repository has src-tauri/ for the Rust side, which means a native shell with a web view rather than an Electron bundle, and src/ with a package.json whose dependencies are React 19, the Tauri API and plugins, framer-motion, lucide-react, zustand for state, i18next for translations, better-auth for the account layer and Tailwind 4 through the Vite plugin. The frontend is a normal web app, and the shell handles the global hotkeys, the clipboard and the system integration that a browser page cannot.

The scripts in package.json are the developer entry points, and they are conventional.

    "dev": "vite",
    "build": "tsc && vite build",
    "test": "vitest run",
    "test:watch": "vitest"

So the development loop is vite for the frontend, tsc for the type check, vitest for the tests and eslint for linting, with a separate tauri script for the shell side.

The project is MIT licensed, the homepage is opentypeless.com, the last push was on 2026-10-13, and the release list shows v1.1.64 on 2026-10-11 with v1.1.63 and v1.1.62 the same day on 2026-10-08, so the cadence is a project shipping often. There is no homepage npm package, since the package.json is marked private, which means you install a release build or build from source.

App-aware polish sends a category, not your document

The feature that distinguishes this from a plain speech to text utility is app-aware writing, which detects the active application locally and adapts the structure and tone for email, chat, documents, issue trackers and coding tools. The visual tour in the README shows it across Gmail, Slack, Google Docs, Cursor, Zendesk and LinkedIn.

That detection is local, and the README is precise about what leaves the machine. All application detection, mappings, dictionary entries and correction rules are stored locally. App-aware polish sends only the internal app category and approved style metadata to the configured LLM path, and raw window titles and document contents are not sent to the LLM or stored in history.

That distinction is the whole privacy argument, and it is a narrow one. The application identity is reduced to a category, Gmail is email, Cursor is a coding tool, and the model receives the category and the style metadata rather than the title of the window or the text of the document. You can also override the built-in category per application with per-app style mappings, so a tool the detector classifies wrongly can be corrected without disabling the feature.

Two consequences follow. The polish step still requires a network call to a model, so this is not an offline tool, and the guarantee is about what the app sends rather than about what the chosen provider retains. A reader who wants to check the claim should look at the code path that builds the request, not only at the privacy statement in the README.

Four voice intents, and shortcuts that differ per platform

The voice intent routing distinguishes dictation, selected-text editing, translation, Ask Anything and supported voice actions, and the README says the routing works in English, Simplified Chinese and Traditional Chinese. Multiple shortcuts per workflow can be assigned and reordered, so Dictation, Ask Anything and Translation each get their own binding, and the translation target is switchable rather than fixed to one output language.

The default bindings differ by platform, and the reason is stated.

| Platform | Dictation | Ask Anything | Translate selected text | | -------- | --------- | ------------ | ----------------------- | | macOS | `Fn` | `Fn+Space` | `Fn+LeftShift` | | Windows | `Right Alt` | `Right Alt+Space` | `Right Alt+LeftShift` | | Linux | `Ctrl+/` | `Ctrl+.` | configurable |

The Linux row is the interesting one. The README says Linux keeps conservative Ctrl based defaults because global Right Alt handling is less reliable across desktop environments, especially on Wayland. That is a real constraint rather than a preference, and it means the Linux experience starts with different keys from the macOS and Windows ones.

The recent release notes mention Wayland direct typing with compositor-specific helpers and safer Windows modifier-key output, which suggests both of those are still areas where the behaviour is being tuned rather than settled.

Ask Anything is a hotkey, not a chat tab

Ask Anything is described as a shortcut-first voice Q&A flow, explicitly not a chat tab. The sequence is: press the Ask Anything hotkey, speak a question, stop recording, and OpenTypeless transcribes it, sends a one-shot request to the LLM, and then shows only the final answer in a small floating note.

The stated design goal is quick answers with no chat history, no input box and no extra send step. If selected-text context is enabled, Ask can also answer questions about the text currently selected in another application, which is the interesting combination, since it turns the selection into a question context without you having to paste anything.

The choice of a floating note rather than a panel is the same design decision as the dictation flow, in which the output is written straight into the focused application. There is no transcript retained, no thread to scroll back through and no place to refine a prompt after the fact.

That is a clear trade. A conversation interface gives you a second chance at a bad question and a place to keep context, and this design gives you speed and zero residue. For a tool whose purpose is a question you want answered while you keep working, that is the right side of the trade, and for anything longer it is the wrong one.

Bring your own keys, and keep your own vocabulary

The headline list ends with a phrase that decides the cost of the whole thing: bring your own keys or use managed cloud words. The topics confirm it with a byok tag, and the release notes describe Stripe checkout for new purchases with existing Creem subscriptions kept valid, so there is a managed path as well as a self provisioned one.

On the transcription side the notes describe more reliable providers through connection reuse and warm-up, complete Deepgram and AssemblyAI final transcripts, and preserved Custom Whisper URL queries, plus more STT choices including regional Qwen3 ASR Realtime, provider-aware duration controls and preserved audio while providers connect. On the model side there is support for GPT-5 and the o-series requests and for the native Anthropic Claude Messages API, with Claude through OpenRouter still supported.

The local dictionary is the other half. The README describes a stronger local dictionary that adds correction rules plus dictionary import and export, so recurring names, terminology and transcription mistakes stay under your control, and the dictionary entries and correction rules are stored locally along with the app detection data.

That combination, a BYOK transcription provider plus a local dictionary of the words your domain keeps mangling, is the most defensible part of the design. A speech recogniser will always get your product names wrong, and a correction layer that you can edit and export is a better answer than any model prompt.

The shell plugins tell you what the app actually does

The dependency list in package.json is a compact description of the integration surface, and it is more informative than the marketing summary.

The Tauri plugins are the clipboard manager, the deep link handler, the global shortcut plugin, the opener for external links, the process plugin, the store for application state, and the updater. That is the whole shape of a global hotkey utility: it registers a system wide shortcut, reads the focused application, writes the result through the clipboard, and can update itself.

The rest of the front end stack is ordinary and modern. React 19 with react-dom, zustand for state, framer-motion for animation, lucide-react for icons, i18next and react-i18next for the interface, better-auth for authentication, and Tailwind 4 through the Vite plugin for styling. The dev dependencies add vitest with the React testing library, eslint 10, and the Tailwind and React Vite plugins.

That tells you the application is a web front end in a native shell, which is the standard modern desktop shape and the reason it can be cross platform without three separate code bases. The Rust side lives in src-tauri/, with the icons under src-tauri/icons.

The repository also carries the files a serious project carries: a SECURITY.md, a SUPPORT.md, a THIRD_PARTY_NOTICES.md, a VISION.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a CHANGELOG.md and nineteen README translations covering everything from Japanese to Polish, with the English one first.

What to check before you rely on it

Three things decide whether this tool fits your setup, and none of them is the feature list.

The first is the model and provider dependency. The polishing step and, in the managed case, the transcription both happen through services you either pay for or bring keys to, so the privacy claim and the cost claim are two different statements. If your requirement is that nothing you dictate leaves the machine, this project does not meet it, and the honest alternative is a local transcription engine with no rewriting stage, where the editing is yours to do in the target application.

The second is the platform shortcut behaviour. On Linux the defaults are deliberately different from macOS and Windows, and the release notes point at Wayland direct typing with compositor specific helpers, which is a sign that this is a solved-in-progress area rather than a solved one. On Windows the notes mention safer modifier key output, which is the same category of problem. Test the hotkey on your own desktop before you evaluate anything else.

The third is the release train. The version numbers move quickly, with three releases in the four days around 2026-10-08, and the README points at the latest release page for the complete notes and the verified installers. That is good practice for a project that ships often, and it also means the specific behaviour you read about may not be the behaviour in the build you install.

The licence is MIT, with a LICENSE file at the top of the repository, so the code can be read, changed and redistributed, and the third party notices file records the licences of what it bundles. The project also has a Discord link and a discussions board, and a SUPPORT.md, so there is a place to ask when the behaviour is not what the documentation says.

Editorial conclusion

opentypeless fits a developer or writer who wants a hotkey driven voice workflow with rewriting that adapts to the app in front of them, and it does not fit someone who needs transcription to stay entirely on their own machine, since the polish step and the managed speech providers are cloud calls. Before adopting it, decide whether you will bring your own keys or use the managed cloud words, and check the shortcut defaults for your platform, because the Linux bindings are deliberately conservative.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tover0314-w/opentypeless on GitHub