OpenAI GPT-Live Integration

GPT-Live is OpenAI's full-duplex voice model: it listens while it speaks, and it decides for itself when to take a turn and when to stop. Like the other realtime providers it handles speech recognition, the conversation and speech synthesis in one model, so separate STT and TTS settings do not apply.

What sets it apart is delegation. GPT-Live holds the conversation. Whenever something needs reasoning or a tool, it hands that to a backend model through the OpenAI Responses API, and speaks the result in its own words when it comes back.

Setup

GPT-Live runs on VoiceDock's platform keys by default, so you can select it without adding an API key first.

1. (Optional) Add your own OpenAI API key

Only needed to run GPT-Live on your own OpenAI account. It uses the same OpenAI key as the OpenAI text models. Add it under Integrations → API Keys.

2. Configure the assistant

{
  "llm_config": {
    "provider": "openai_live",
    "model": "gpt-live-1",
    "voice": "marin",
    "messages": [
      { "role": "system", "content": "You are the receptionist of Acme. Keep your answers short." }
    ],
    "delegation": {
      "model": "gpt-5.6-luna",
      "instructions": "Check availability with check_availability before you offer a time slot."
    }
  }
}

Choosing a voice. marin is the least reliable of the five voices: now and then it opens a call with a sentence that is not part of the greeting. For an assistant that has to open with a fixed greeting, choose beacon, cinder, stone or vesper.

Two sets of instructions

GPT-Live works best when each model gets its own instructions. The system prompt in messages goes to the voice model: who the assistant is, how it sounds and how it talks. delegation.instructions goes to the backend model: business rules, which tool to use when, and how to handle a request.

Leave delegation.instructions out and the backend model receives the same system prompt as the voice model. That is the easiest start and works for most assistants. Split them when a long prompt full of rules makes the conversation feel slow or stiff.

GPT-Live is also the only provider where the prompt steers the conversational behaviour itself: whether the assistant makes listening sounds, when it yields, and what it does with a voice in the background. Prompting per model has the blocks to write for that, and the trap to avoid.

Tools

Your tools in llm_config.tools work on this provider too: webhooks, end_call, transfer_call and the tools of an MCP server. They run on the backend model. The voice model never calls a tool itself: it hands the request to the backend model, the backend model calls the tool, and the voice model tells the caller what happened.

The voice model hands off when your prompt tells it to. Questions that need a lookup are usually obvious to it; ending the call and transferring it are not. Say it explicitly, because an assistant that only says goodbye has not ended the call. Put a short delegation block at the top of the system prompt:

Delegation policy
Backend capabilities:
- End the call.
- Transfer the call to a colleague.
Delegate to the backend when:
- You have just said goodbye, or the caller wants to end the call.
  Delegate right after your goodbye.
- The caller asks to be transferred.
Saying that you end the call does not end it. Only delegating does.

Name what the backend can do, not the names of your tools, and leave out what your assistant does not have. The tools of an MCP server count too: for a mailbox server, add a line such as "Search the caller's mailbox." Which tool to use when belongs in delegation.instructions, or in the rest of the prompt if you do not split the instructions.

How it behaves differently

• The model owns the turn-taking. It decides when the caller is done and when to stop talking. speech_config.turn_taking does not apply, as on every realtime provider.
• Lines you give it are instructions, not scripts. The first message, silence prompts and the outbound opening line are passed to the model as something to say, and it says them in its own words. It can decline one that does not fit the conversation at that moment.
• Voice and instructions are fixed for a session. In a workflow, a step with different instructions or a different voice starts a new connection to OpenAI. The conversation so far is sent along (up to 128 messages and 8,192 tokens), so the model picks up where it was, but the switch takes a moment.
• There is no text-to-speech step. Pronunciation replacements and a fixed closing line (end_call_message) are pipeline-only and are refused on this provider, as on the other realtime providers.

Pricing

• Platform keys (default): OpenAI usage at cost + €0,07/min orchestration. The voice session is $0.05 per minute, and the backend model's tokens are billed at cost on top of that, at OpenAI's token prices for that model.
• Bring Your Own Key (optional): €0,07/min orchestration. Both parts are billed to your own OpenAI account.

How much the backend model adds depends on how often the assistant needs it. An assistant that mostly talks uses little; one that calls a tool on nearly every turn uses more.

Data processing

OpenAI processes this model outside the EEA by default. If your assistants need EU data residency, use Gemini Live on Vertex AI or the Google pipeline in the EU instead. The sub-processor list on the Trust Hub has the details.

Limitations

• Languages outside OpenAI's strongest set may sound less natural than English. Test with real callers before you move a live number.
• gpt-5.6-luna is the only backend model for now. Others follow once we have measured them on GPT-Live.
• GPT-Live cannot speak a line word for word. If a sentence has to be exact, a pipeline assistant is the better fit.

API Reference

See BYOK API Reference for managing your OpenAI API key.