# Realtime voice, in order
## The steps
1. Mint an ephemeral client secret on your server for each session. The browser or device connects with that short-lived secret; your long-lived API key never leaves the server.
2. Create the session from the client over WebRTC (browser) or WebSocket (server). Configure the session up front: voice, input audio transcription, and the tools the agent may call.
3. Handle turns as events, not requests. The model emits audio deltas, transcriptions, and tool calls as a stream of session events; your code reacts to each event type and keeps local state in sync.
4. Implement interruption: when the user starts speaking over the agent, stop playback and truncate the conversation at the interruption point so the model does not keep answering a stale turn.
5. Wire tool calls through the session: when the model requests a function, run it in your backend and send the result back into the session as a conversation item. Voice latency budgets are tight, so keep tool execution fast or acknowledge the delay in speech.
6. Decide the architecture deliberately. Use the Realtime API when the interaction must feel conversational with barge-in and low first-audio latency. For non-interactive audio, a chained pipeline (transcribe, respond, synthesize) is simpler and cheaper.
## The trap
Shipping the API key in the client to skip the ephemeral-key step, or treating the session like a chat completion and polling for a final answer. Both break the moment real users talk over the agent.
## Checklist
- Ephemeral secrets minted server-side per session.
- Session configured before the first audio turn.
- Interruption handling implemented and tested with real overlap.
- Tool calls round-trip through the session with latency budgets.
- Architecture choice (realtime vs chained pipeline) is explicit.