Voice runs the same code everywhere. The only question is whose infrastructure it runs on. Pick a deployment model based on three factors:
  • Where your call audio and customer data are permitted to live.
  • Whether you want to operate GPUs.
  • How much of the stack you want to manage yourself.
There are three models. Most teams start on managed cloud. A regulated few move media or inference into their own environment later. Your agent config, SDK code, and dialplan do not change when you switch. Those are portable across all three models.

​
The three pieces

Before you choose, know what actually runs. Every ClutchCall Voice deployment is three planes:

Control plane

The control plane is the console at agent.clutchcall.dev, the tenant-scoped control-plane API at engine.clutchcall.dev, the Postgres-backed config database, and the columnar analytics store behind your reports. It holds agent configs, trunk definitions, call records, and recordings metadata.

Voice engine

The engine is the QUIC/HTTP-3 endpoint on :443, the SIP gateway/B2BUA, the RTP media plane, and the embedded agent runtime. Call audio flows here. PSTN trunks, browser MoQT tracks, and the WebRTC fallback leg all terminate here.

Inference

Inference is the speech models. This is either a self-hosted speech-to-speech model on your GPUs, or a hosted provider endpoint (OpenAI Realtime, Gemini Live, Deepgram, ElevenLabs, and others) that the runtime dials out to. Transcripts and generated audio are produced here.
The models below differ only in which of these three you host and which we host.

​
Choose a model

We run all three planes. You bring an API key and an agent config. You operate no infrastructure.
  • You host: nothing. We host: the control plane, the engine, and (for the default runtime) inference.
  • Media path: call audio lands on our engine. PSTN trunks point at your per-tenant SIP host <workspace-id>.sip.clutchcall.dev. Browsers connect to the QUIC endpoint on :443.
  • Best for: fast shipping, variable call volume, and teams that do not want to operate real-time media or GPUs.
There is intentionally no sandbox environment. Managed cloud is a single production plane. Use a separate workspace for staging. Do not expect a sandbox toggle. See Managed Cloud quickstart.

​
Where data lives

The location of the engine decides data residency, because the engine is the only plane that touches raw call audio. Two levers narrow the media footprint further, in any model:
  • Direct media. Per-trunk media_mode: direct terminates RTP on the shard where the agent runs. Audio then crosses no extra hop. Use proxy only for hostile-NAT carriers. See Sessions, Calls, Tracks & Streams.
  • Sealed credentials. Every provider key and SIP secret is encrypted at rest under your key-encryption-key, regardless of where the control plane lives.

​
When to self-host inference

Self-hosting the models is the most common reason to leave pure managed cloud. Use it when:
1

Transcripts cannot leave your boundary

Your audio is regulated (health, finance, government), and you cannot send speech to a third-party API. A self-hosted speech-to-speech model keeps every transcript and generated token inside your GPUs.
2

You want model control

You need a specific fine-tune, a pinned model version, or a model that no hosted provider offers. You serve it yourself, and the runtime routes to it.
3

GPU economics beat per-minute pricing

At sustained concurrency, amortized GPUs can undercut metered realtime API minutes. Self-hosting turns a variable per-minute cost into fixed capacity.
The runtime reaches your models through an inference control plane. That plane discovers GPU pods, scrapes their load, and routes requests over QUIC. You supply the GPUs (your own cluster, or a rented GPU host). We supply the routing and the duplex audio adapter.
The text-generation routing tier of the inference control plane is shipped. The single speech-to-speech model path is not yet verified end-to-end in production. If you plan a self-hosted-inference rollout, validate against your own traffic before cutover. Details are in Self-Hosted Models.
If you do not need any of the above, stay on managed inference. Point the runtime at a hosted realtime or ASR/LLM/TTS provider, and use no GPUs at all. See Runtime overview.

​
Next steps

Managed cloud quickstart

Ship a voice agent with zero infrastructure.

On-prem quickstart

Run the full stack in your own environment.

Self-hosted models

Serve your own speech models on your GPUs.

Voice architecture

Follow the end-to-end signalling, media, and runtime path.