One Speech Core, Many Clients

VoiceStudio exposes the same local speech capabilities to a desktop user, a browser or editor extension, a script, an OpenAI-compatible application, an AI agent, and an approved remote worker. The important question is not which interface sounds most modern; it is which part of the interaction the client needs to own and what crosses the boundary when it uses it. That distinction lets you choose a transport without accidentally giving a client microphone control, unrestricted file access, or authority to change the voice identity of a job.

Choose the interface by the job you own

A desktop user who presses a global dictation shortcut needs two different services. They need the speech backend to recognize audio, but they also need a native process to remember the focused destination and insert text into another application. VoiceStudio's Rust control sidecar handles the second job. It can start, stop, or toggle capture, reserve an output session for the target, and deliver the final text through a platform-specific paste path. The Python backend remains responsible for ASR and partial/final transcript events.

This split matters because a browser page cannot safely promise the same native behavior. A web-based editor or a custom graphical application can own its microphone and send PCM or WebM frames to the backend's versioned transcription WebSocket. It receives partial and final text but does not receive arbitrary desktop-window privileges. If it also wants native insertion, it can use an explicit output session through the control sidecar. The client chooses whether it owns capture, insertion, or both; VoiceStudio does not silently grant all three.

A script or an existing audio SDK usually wants a batch contract. The OpenAI-compatible HTTP surface accepts speech synthesis and transcription requests in familiar shapes, and a client can often change its audio base URL rather than replace its integration. This path is appropriate when the caller already has files, text, and its own application logic. It does not provide the desktop meaning of “paste into the window that was active when I pressed the shortcut,” so it should not be treated as a replacement for native dictation control.

An AI agent can use the same HTTP surface, but MCP provides a more direct tool contract. The mounted server can generate speech, transcribe audio, create a voice profile, list voices, and expose profile or history resources. The agent runtime still owns the conversation, tool-selection policy, and any higher-level behavior. VoiceStudio is the provider that turns accepted text or audio into speech services; it is not the agent's planner or a guarantee that an agent will make a safe decision.

The right interface follows ownership:

• Use native control when the important result is a safe action in the desktop environment.
• Use the live WebSocket when the client owns the microphone or needs partial speech events.
• Use OpenAI-compatible HTTP for files, scripts, SDKs, and batch calls.
• Use MCP when an agent needs speech tools, voice resources, or explicit per-client voice binding.
• Use a remote-worker path only when the user has chosen to send a supported rendering task to another machine.

These options overlap in capability, but they do not have the same authority. A transcription result is data. A dictation toggle is a native action. A voice-profile binding is an identity choice. A worker task is a data-transfer decision. Treating them as interchangeable endpoints would erase the very boundaries that make local-first operation meaningful.

Native dictation is a control problem as well as an ASR problem

The focused-target example shows why VoiceStudio keeps a control plane beside its data plane. At shortcut-down, the desktop captures the process or window that should receive the result. During recording, the backend can emit partial text, but those partials must not be pasted into an arbitrary target. At the end, the session ID connects the final transcript to the original destination.