Hello Dear team
Summary
When gpt-realtime-1.5 speaks a numeric ID containing a run of repeated digits, the generated audio occasionally omits one of the repeated digits, while the text transcript emitted on the same turn is correct. This produces a silent mismatch between what the caller hears and what the system logs/displays.
Environment
-
Model:
gpt-realtime-1.5 -
Endpoint:
POST /v1/realtime/calls(WebRTC) -
Voice:
alloy -
Input transcription:
whisper-1 -
Negotiated audio codec: PCMU 8 kHz (G.711 μ-law, narrowband telephony)
-
Turn detection:
server_vad
Reproduction
-
Start a realtime session over WebRTC with PCMU/8000 as the negotiated codec.
-
Have the assistant read aloud a 6-digit ID containing four consecutive zeros, e.g.
100007. -
Compare the
response.output_audio(what the caller hears) to theresponse.content_part.donetranscript for the sameitem_id.
Observed
-
Transcript (correct): "The code 100007 corresponds to the Beixinqiao Subdistrict within the Dongcheng District of Beijing." -
Audio (incorrect): assistant pronounces "10007"— one zero dropped.
Both belong to the same assistant item (item_DXM5QOn44mZwT09RQqkpG), same response (resp_DXM5QaL3R7PfYT4IJS6cH), so the audio and text heads diverged on the same generation.
Expected
Audio output matches the transcript; all six digits of 100007 are pronounced.
Notes / hypotheses
-
Failure mode appears specific to runs of identical digits (the four consecutive zeros). Shorter or non-repeating numbers in the same session were spoken correctly.
-
Narrowband PCMU likely aggravates but does not cause the issue: the transcript head produces the correct token sequence, so the omission happens in audio generation, not in reasoning.
-
No pronunciation hints were given in the system prompt; the model chose its own reading of the number.
Impact
For telephony / receptionist use cases, this silently corrupts IDs, phone numbers, confirmation codes, and extensions that callers write down or repeat back. The bug is hard to detect in production because server-side transcripts look correct.
My Next steps
-
I will check later if this is mono syllable related or if it affects numbers with > 1 syllable - example Seven… What if I put 5 7’s in the middle? Where does it break?
-
Anyway - I hit a wall here because the samples I need are all with a bunch of ZERO’s in the middle
-
for realtime devs: Verify parity between text-head and audio-head token sequences for numeric strings, especially under narrowband output sample rates. They should be supposedly saying the same thing.
Thanks so much
God bless