Voice Dictation for Claude Code Without a Plugin

Superwhisper shipped a Claude Code integration in April. You install it from inside the app, it creates an agent hook, and Superwhisper becomes Claude Code-aware. It's in the v2.13.0 changelog.

VoizerFlow has been Claude Code-aware since the first time you opened both apps together.

The difference isn't a missing feature. It's an architecture decision made early.

What the Plugin Actually Does

Superwhisper's Claude Code plugin gives the app an explicit connection to the Claude Code agent. When you're in Claude Code, Superwhisper can adapt — different voice modes, different processing, different output formatting tuned for the agent context.

That's useful. The reason it requires a plugin is that Superwhisper's default mode detection doesn't know which app is active. It needs the hook to find out.

This is also why the v2.13.2 changelog added a Pi coding agent and v2.14.0 added a direct plugin installation flow. Each new app context is a new integration. Each one has to be built, shipped, and maintained.

How VoizerFlow Detects Claude Code

macOS exposes a system-level API called NSWorkspace. Among other things, it reports which bundle ID is currently in the foreground — the unique identifier for every installed app on the system.

VoizerFlow listens to NSWorkspace notifications. When Claude Code comes to the foreground, VoizerFlow sees the bundle ID change and switches to whichever voice mode you've configured for that app. When you move to your browser, it switches again. When you open Slack, it switches again.

No plugin install. No per-app integration to download. The OS provides the context.

Claude Code's bundle ID is just another bundle ID. So is Cursor's, Linear's, Slack's, and every other app on your machine. Configure a voice mode for any of them, and the switch happens the moment that app comes to the front.

What This Looks Like in Practice

A real Claude Code session doesn't stay in Claude Code. You're in Claude Code, then you tab to a browser doc, then you're in Slack answering a question, then back to Claude Code to continue the prompt.

Each context switch is a mode switch. If you're dictating across all of these (and the whole point of voice dictation in a dev session is keeping your hands off the keyboard), the tool needs to follow you across context switches without you having to manage it.

With Superwhisper's plugin approach, you have Claude Code coverage and whatever other integrations are on the release schedule. Everything else gets the default mode.

With NSWorkspace-based detection, you have per-app voice modes for every application on your system. You configure each one once. After that, the switching is automatic.

The workflow difference is small when you're locked in a single app for two hours. It shows when your session looks like actual work: browser, terminal, IDE, chat, back to IDE.

The Maintenance Problem

Plugin integrations require upkeep. If Claude Code changes its agent API, the plugin may need updating. If a new coding tool emerges, a new plugin has to be built. The integration list in any app's changelog is a maintenance surface.

NSWorkspace bundle ID detection doesn't care what an application does internally. The bundle ID for Claude Code doesn't change when the app updates. The mode switch still happens. VoizerFlow doesn't know or care about Claude Code's internals — it only knows that bundle ID is in the foreground, and what mode you told it to use for that bundle ID.

This is the practical difference between a feature you maintain and an architectural property that holds across updates. Superwhisper is shipping integrations because their architecture requires it. VoizerFlow skipped that step because NSWorkspace already provides what the integrations are trying to replicate.

Setting This Up

In VoizerFlow's preferences, there's a per-app mode section. You pick the app from a list of installed applications, assign a voice mode, and you're done.

Claude Code, Cursor, Linear, your email client, your notes app — any installed app gets its own mode. The configuration takes a few minutes once. From that point on, it runs silently.

There's no external install step. No connection to an external agent service. The detection runs at the OS level, which means it works for any app, not just the ones VoizerFlow has specifically integrated.

Where the Plugin Approach Has an Edge

It's worth being clear about where Superwhisper's integration approach wins.

Deeper agent context is one place. A Claude Code plugin can pass information back to the agent, not just detect that it's in the foreground. If the integration is doing something more than mode switching — actively hooking into the agent's state — NSWorkspace detection doesn't replicate that.

Superwhisper's S1 proprietary model is another thing NSWorkspace doesn't touch. If the voice model itself matters to you, that's a separate evaluation.

The claim here is specific: if what you want is per-app voice mode switching that works with Claude Code and every other app you use, without plugin installs, the NSWorkspace approach gives you that out of the box.

The Parakeet Model Question

Both VoizerFlow and older Superwhisper configurations run Parakeet (NVIDIA NeMo's open-weight English transcription model) for local inference. If you see the name in either changelog, it's the same model.

VoizerFlow runs Parakeet on the Apple Neural Engine, not the GPU. The ANE is a dedicated inference chip built into Apple Silicon — it doesn't compete with your IDE, your build processes, or anything else running on the GPU. Transcription runs in parallel with your development tools, not alongside them fighting for the same compute.

The audio stays on the ANE. Nothing leaves the Mac during transcription.

VoizerFlow is a macOS voice dictation app for Apple Silicon. Per-app auto mode-switching happens through NSWorkspace — it detects Claude Code, Cursor, or any other app the moment it comes to the foreground, no plugin required. Transcription runs on the Apple Neural Engine. $49.99, one-time.