Realtime api session doesn't have one default conversation

API Feedback
1

According to the documentation under response.create calls theres a field “conversation” in the response object that can only be set to “auto“ or “none”.
When left on “auto” it appears to add messages to a conversation with a separate conversation_id from the conversation_id used for the audio/vad_detection_turned_on.

This makes sending side channeled messages intended to be relevant/related to the current realtime audio conversation’s context useless. There ends up being two separate conversations with different contexts one for text based messages one for audio based.

Is this a known bug or am I missing something?
Also it would be awesome if we could specify the conversation_id manually instead of having to trust the “auto“ option.

2

Ok it seems to be related to using the VAD feature.
All responses generated via VAD will contain one conversation_id while all responses generated via a manually created response event will contain a different default conversation_id.

3

Update it’s not related to VAD. We swapped out for push to talk and are still randomly seeing different conversation_id’s showing up when conversation is set to “auto“.

If this is read by the realtime api team a feature request would be to have the ability to manually or explicitly provide an ID for the conversation we want the responses to become associated with instead of having to trust the auto vs none option currently.