Connection
Client → Server Messages
Server → Client Messages
The optional
usage object on context_closed is present for organization-
backed requests:
Voice Settings
When creating a context, pass voice settings as a nested object:Session-Level Config
These options can be set on any message and apply to the entire session:
Reuse the same
context_id across turns to keep one context alive
(recommended for a single conversation), or open new ids for parallel
speakers:
Updating Settings
Change the session’s generation parameters mid-connection with anupdate_settings message (no context_id — it is session-scoped). The server
replies with settings_updated:
voice_id, model_id,
sample_rate, output_format, project_id, dictionary_ids) are rejected
inside update_settings with a VALIDATION_ERROR frame. Ordinary context
messages use the session-level fields in the table above.
Applies to contexts started after the update. A context’s generation
parameters are bound when its backend session opens, so an
already-streaming context keeps its settings; the update affects contexts
created after it. With the common one-context-per-turn pattern that means it
takes effect on the next turn. (Per-context
cfg_scale / max_new_tokens set
in a context’s voice_settings still win for that context.)Example
Limits
- Maximum 20 concurrent contexts per connection
- Contexts auto-close after 20 seconds of inactivity (send the empty-text keep-alive to reset)
- Opening a context beyond the limit returns a per-context error (
error_code: "TOO_MANY_CONTEXTS",code: 429) without closing the connection — close an existing context, or wait for an idle one to be released, then retry.