From 2aa7b8af8e32f08acdf0a1aa27f1a1e2101a22ee Mon Sep 17 00:00:00 2001 From: mrchatam Date: Fri, 11 Sep 2026 23:14:42 +0000 Subject: [PATCH] docs: fix 'rather then' typo in ADR 0065 --- docs/decisions/0065-realtime-api-clients.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0065-realtime-api-clients.md b/docs/decisions/0065-realtime-api-clients.md index 3a746035641d..0e1e08f50138 100644 --- a/docs/decisions/0065-realtime-api-clients.md +++ b/docs/decisions/0065-realtime-api-clients.md @@ -413,7 +413,7 @@ audio = AudioContent(...) await client.send(ServiceEvent(service_event_type='input_audio_buffer.append', service_event=audio)) ``` -The first version allows one to have the exact same code for all services, while the second version is also correct and should be handled correctly as well, this once again allows for flexibility and simplicity, when audio needs to be sent to with a different event type, that is still possible in the second way, while the first uses the "default" event type for that particular service, this can for instance be used to seed the conversation with completed audio snippets from a previous session, rather then just the transcripts, the completed audio, needs to be of event type 'conversation.item.create' for OpenAI, while a streamed 'frame' of audio would be 'input_audio_buffer.append' and that would be the default to use. +The first version allows one to have the exact same code for all services, while the second version is also correct and should be handled correctly as well, this once again allows for flexibility and simplicity, when audio needs to be sent to with a different event type, that is still possible in the second way, while the first uses the "default" event type for that particular service, this can for instance be used to seed the conversation with completed audio snippets from a previous session, rather than just the transcripts, the completed audio, needs to be of event type 'conversation.item.create' for OpenAI, while a streamed 'frame' of audio would be 'input_audio_buffer.append' and that would be the default to use. The developer should document which service event types are used by default for the non-ServiceEvents.