Voice overview

Voice is a preview product family for speech generation, transcription, dubbing, conversational agents, phone-oriented setup, session inspection, consent, usage, and local-runtime exploration. Use this overview to choose the right surface and to understand why a visible card does not necessarily mean that its provider or runtime is ready. The current implementation mixes mock-ready, setup-required, preview, coming-soon, fallback, and local-unavailable states, so availability must be read at the capability level.

What Voice includes

The Voice hub brings several audio workflows into one product family without pretending that they all share the same implementation status. Speech generation has the strongest directly verified path: the application accepts text, resolves a provider route, calls a server-side adapter, and returns audio plus routing metadata. Other surfaces expose transcription, dubbing, agents, sessions, phone setup, consent, usage, marketplace preview, settings, and Local Voice.

Those surfaces serve different jobs:

• Voice Studio is the speech-generation workbench.
• Transcription is the speech-to-text surface.
• Dubbing is a preview for alternate-language or alternate-voice media.
• Voice agents combine instructions, voice configuration, safety settings, and a browser test experience.
• Phone agents describe telephony setup and architecture rather than a functioning calling service.
• Sessions provide a place to inspect interaction records or attempts, while durable event and retention behavior remains under review.
• Consent records a user declaration before cloning-related work.
• Local Voice depends on a compatible local speech runtime that is installed and detected.

The hub is therefore a map, not a single end-to-end runtime. Open the surface that matches the intended output and then check its current provider and readiness state.

Voice groups several audio and conversational tasks under one preview hub, while each task retains its own readiness state. The Voice hub links to Studio, sessions, agents, phone setup, transcription, the internal API reference, usage, marketplace preview, Local Voice, dubbing, consent, and settings. POST /api/voice/speech is the directly verified generation endpoint. Equally complete API contracts are not available for every Voice surface. Provider metadata includes mock, OpenAI, ElevenLabs, Cartesia, and local entries, but static catalog state is not a live provider-health check.

Core surfaces

The approved Voice routes separate generation, operations, configuration, and governance. /voice/studio is the best starting point for a first text-to-speech result. /voice/transcribe and /voice/dub cover different media transformations and should not be treated as interchangeable. /voice/agents and /voice/phone focus on conversational configuration and telephony-oriented readiness. /voice/usage, /voice/settings, and /voice/consent address operating state and responsibility rather than producing audio directly.

A surface can be present while its execution path is incomplete. For example, Phone Agents is a setup and architecture preview; the route does not prove number provisioning, inbound calls, outbound calls, transfers, callbacks, or recording. The marketplace is a controlled preview rather than a live transaction system. Local Voice can show setup guidance even when no local STT or TTS runtime is detected.

Use the route label and the current state together. A card marked Preview means the product surface is visible but not necessarily complete. Setup required means the route exists but a provider or runtime dependency is missing. Coming soon means the capability should not be described as available. Mock ready indicates that test output may be produced without a configured hosted provider.

The hub routes readers to task-specific workbenches instead of implementing every workflow on the overview page. Private routing remains unavailable until a local speech runtime is installed and detected. Automatic routing may use the mock adapter when hosted providers are not configured, and generated output must disclose that fallback. Open the task-specific route instead of assuming the hub card itself performs the work.

Providers

Provider metadata currently includes mock, OpenAI, ElevenLabs, Cartesia, and local entries. The catalog also defines example models, voices, default voice settings, hosted-provider base URLs, and routing modes. This metadata helps the interface present choices, but it is not a live health check and does not prove that server-side credentials are configured.

Routing modes include balanced, best quality, fastest, lowest cost, private, fallback, and manual selection. The route selected at request time may depend on configuration and availability. Automatic routing can fall back to the mock adapter, and private routing reports unavailable when a local runtime is not installed. A response that contains audio should therefore be read together with provider, model, fallbackUsed, and routeReason.

Do not equate a configured provider with permanent availability. Provider health can change independently of static catalog data. No universal status contract applies across every Voice surface.

Provider entries describe possible adapters and configuration posture, not a guaranteed live service check. Consent declarations are supplied by the user and are not independently verified by Ethen. Usage logging from the speech route is best effort, while displayed cost values are estimates rather than billing records. Check provider configuration and output metadata before treating a result as hosted, local, or mock.

Sessions

A Voice session is an interaction record or live-session attempt, not automatically a durable production conversation. The hub links to a session viewer, and the agent and phone surfaces refer to browser or telephony interactions. No single contract currently defines the complete event schema, retention policy, replay behavior, and persistence guarantees for those records.

For basic speech generation, a separate session object is not required by the verified POST /api/voice/speech handler. The request can return generated audio directly. Agent testing and live interaction may create more state, but browser connection reliability, interruption handling, reconnection, event ordering, and transcript persistence require runtime-specific verification.

When a session entry is available, use it to inspect what the interface recorded, not to infer unobserved behavior. A missing entry does not necessarily mean that generation failed because usage logging is best effort. Conversely, a visible session does not establish that audio, transcripts, or events will remain available for a fixed period.

Session surfaces help inspect interaction attempts, but durable lifecycle and event semantics remain under review. Use the consent surface before any voice-cloning workflow, while recognizing that cloning availability remains unverified. Identify the task first: generate speech, transcribe audio, inspect a session, configure an agent, or review consent. Keep the product maturity at preview and describe the narrower state shown by each surface.

Consent

Voice consent is a user-declared control that must be considered before cloning-related activity. The consent surface states that declarations are supplied by the user and are not independently verified by Ethen. Recording a declaration is therefore not identity proof, provider authorization, or evidence that a cloning model is available.

Consent also does not resolve every data-handling question. Provider and consent contracts do not establish zero retention, zero training, automatic deletion, watermarking, revocation propagation, or universal cloning controls. Those boundaries matter whenever source audio or generated speech represents a real person or contains confidential information.

Use the consent route to document the user’s declaration, then separately confirm the permitted purpose, the provider’s current requirements, the intended distribution, and the organization’s privacy and safety obligations. If consent is disputed or withdrawn, stop the workflow and follow the organization’s incident process rather than assuming that a declaration automatically controls downstream copies.

Consent is a user responsibility that precedes cloning-related work and remains separate from provider availability. Do not infer phone deployment, live marketplace transactions, durable sessions, or local availability from navigation alone.

Where to begin

Choose the first route by outcome:

1. Open Voice Studio for text-to-speech generation.
2. Open Transcription when the goal is speech-to-text, while recognizing that its exact API contract still requires review.
3. Open Voice agents to configure instructions, a voice, and browser testing within the preview boundary.
4. Open Phone agents only to assess telephony setup and architecture readiness.
5. Open Voice consent before cloning-related work.
6. Open Voice settings when a hosted provider reports setup required.
7. Use Local Voice only after a compatible local runtime is installed and detected.

A useful operating habit is to record the route, provider state, routing mode, and fallback result whenever a Voice capability is tested. That small record prevents a mock-ready demonstration from being confused with a configured hosted path and makes later troubleshooting more precise.

For a first supported result, continue to the Voice quickstart. It follows the directly verified speech-generation route and shows how to distinguish a configured hosted response, a mock fallback, validation failure, and local-runtime unavailability.

The best starting route follows the intended output and the dependencies already configured in the environment.