Superwhisper Added a Local Model. What \"Experimental\" Tells You About the Architecture.
Superwhisper v2.16.0 added an experimental S1-Mini local model. Here's what \"experimental\" means in practice, and why starting local is different from adding local as a feature.
Superwhisper Added a Local Model. What "Experimental" Tells You About the Architecture.
Superwhisper shipped v2.16.0 on June 9, 2026. Near the top of the changelog, under "Features & Improvements": "Experimental access to S1-Mini local model."
That word, experimental, is doing real work.
This post is about what it means when a voice dictation tool adds local processing as a feature, versus when local processing is the only architecture the tool has ever had. They're not the same thing. If you're evaluating your options right now, the difference is worth understanding before you choose.
What the Changelog Actually Shows
Superwhisper has shipped six releases since April. That's a healthy pace for a Mac app, and the feature list shows it.
Scroll through those releases and a pattern emerges. v2.13.0 in April: "Integrated Claude Code and Open Code agents." v2.16.0 in June: "Experimental access to S1-Mini local model."
Then v2.16.1, one week later: "Fixed issues with the Claude Code integration." That's the third release in a row touching Claude Code integration fixes.
Plugin integrations break. That's not a knock on Superwhisper specifically. It's what happens when the architecture requires a plugin to bridge two separate apps, and those apps update on independent schedules.
The local model has a similar dynamic. The changelog for v2.16.0 adds local processing as a new path. The changelog for v2.16.1 includes "Massive improvements to the local language model output quality." That's what early-stage local looks like — you ship it, then you iterate on it, then you iterate on it again.
Local as a Feature vs. Local as an Architecture
When a tool adds local processing as a new capability, you're seeing a feature built on top of an existing cloud architecture. The primary transcription stack stays cloud-first. The local model is an alternative path, marked experimental, with stabilisation still happening release over release.
VoizerFlow has never had a cloud path for transcription. There isn't a cloud stack that predates the local one. The architecture starts on the Apple Neural Engine (ANE), and the product is built from that constraint outward.
This shapes what reliability means in practice. You can't reevaluate vendors when there are no vendors. You can't ship a cloud-related accuracy fix when there's no cloud in the transcription pipeline.
Both of those scenarios came up for Wispr Flow this spring — they publicly acknowledged two waves of accuracy issues and said they were "reevaluating our vendors." That language makes sense when your transcription runs on infrastructure someone else owns. It has no equivalent in an on-device architecture.
What the ANE Actually Is
The Apple Neural Engine is a dedicated chip for neural network inference. It's physically separate from the GPU and the CPU, with its own memory bandwidth and execution environment. It has no connection to your networking hardware.
When VoizerFlow runs Parakeet (NVIDIA NeMo's English transcription model, compiled to CoreML for the ANE), the computation happens on that chip. Open Activity Monitor during a dictation session and click the Network tab. The outbound counter doesn't move during transcription.
That's not a promise in a privacy policy. It's observable behaviour you can verify in thirty seconds.
The integration with other apps doesn't use a plugin. VoizerFlow reads the active application's bundle ID via NSWorkspace and switches modes automatically. There's no hook that talks to Claude Code's internal API, and nothing that breaks when Claude Code ships an update.
Per-app mode switching has been stable since v1.0. It doesn't have a fix log, because there's nothing to fix.
When the Category Converges
Something worth noting about where voice dictation is heading. Superwhisper is adding local processing. Fonos appeared on Hacker News recently, an open-source tool with BYOK or local processing and no subscription.
The direction the whole category is moving is toward the architecture VoizerFlow already has. That's genuinely good for developers who want local-first tools. More options in that space means more people will get to try it.
But the question worth asking when evaluating tools is no longer whether a local option exists. It's what local actually means in the architecture. Is the local model an experimental add-on to a cloud product, or does the whole stack assume no network?
That answer shapes what you experience daily. It shapes whether IDE integrations need patching when the IDE updates. It shapes whether vendor accuracy issues are even a category of thing that can happen to your setup.
What This Means If You're Evaluating
If you're looking at Superwhisper's S1-Mini local model and waiting for it to leave experimental, consider the practical comparison. VoizerFlow runs Parakeet on the ANE right now, fully stable, and costs $49.99 once. That's meaningfully different from a subscription product while you wait for a local mode to mature.
If you're on Superwhisper's Claude Code plugin and you've watched those fix entries appear across three consecutive releases, the NSWorkspace-based mode switching in VoizerFlow has nothing to break. There's no plugin installation, no hook configuration, and no patch required when Claude Code updates. The switching logic reads the active app's bundle ID and that's it.
Superwhisper is a capable product with a large feature surface, and this comparison is meant to be honest. One is a cloud product adding local capability as a feature. One started local and hasn't needed to add it.
For the developer who wants transcription that has never touched cloud infrastructure, who wants the IDE integration to work without a plugin that needs patching, and who wants to pay once, the architecture that started local is the right fit.