Gpt-4o-mini-tts-2025-12-15 still truncates final sentences; 2025-03-20 is being deprecated

API Bugs
1

We rely on the OpenAI audio/speech endpoint for production text-to-speech.

The current gpt-4o-mini-tts model, with current snapshot gpt-4o-mini-tts-2025-12-15, still appears to have a serious truncation issue: generated audio often cuts off the final sentence or the end of the final sentence.

This is not an API error response. The request succeeds and returns audio, but the returned audio is incomplete. Retrying the same input sometimes produces complete audio, which makes this difficult to safely detect without post-generation validation.

Because of this, we have had to keep using gpt-4o-mini-tts-2025-03-20, which has been much more reliable for this failure mode in our usage. The problem is that the deprecation docs now list gpt-4o-mini-tts-2025-03-20 for shutdown on 2026-07-23.

That leaves us without a viable migration path for this use case. Current gpt-4o-mini-tts still truncates final sentences. The 2025-03-20 snapshot is the only reliable option we have found, but it is being deprecated. tts-1 and tts-1-hd are not equivalent replacements for promptable voice control and quality. The deprecation table suggests gpt-realtime, but that is not a drop-in replacement for existing audio/speech generation workflows.

Please fix the truncation bug in the current gpt-4o-mini-tts model, or keep/provide at least one stable audio/speech model or snapshot that can reliably generate complete audio. At minimum, please confirm the recommended migration path for developers who need non-realtime TTS and cannot accept final-sentence truncation.

Happy to provide concrete request IDs or audio samples via a private support channel if useful.

2

gpt-4o-mini-tts-2025-12-15 also ignores TTS instructions. So it is a worse model than gpt-4o-mini-tts-2025-03-20.

3

There a has been a few threads about this prior but I think the issue lost attention once people realized you can still use gpt-4o-mini-tts-2025-03-20. Now OpenAI is removing this version and this is very bad.

The newer version, gpt-4o-mini-tts-2025-12-15, is TERRIBLE at acting and its not usable for me. If gpt-4o-mini-tts-2025-12-15 is not fixed, and gpt-4o-mini-tts-2025-03-20 goes away, I will not be able to use OpenAI TTS anymore.

To illustrate the issue, go into the OpenAI playground and use these instructions for each model:

“Speak in an exaggerated, theatrical tone, reminiscent of a Shakespearean stage actor from the Elizabethan era. Emphasize every syllable with dramatic flair, rolling R’s and elongating vowels. Your cadence should rise and fall as if declaiming poetry Occasionally add chuckles, groans, or grunts of faux embarrassment.”

You’ll see that gpt-4o-mini-tts-2025-03-20 plays along and acts aa directed while gpt-4o-mini-tts-2025-12-15 ignores instructions and just speaks in a plain monotone style.

Please OpenAI, fix this issue BEFORE depreciating gpt-4o-mini-tts-2025-03-20.

I want to illustrate the issue. Here are two TTS generated audio files. The first is the 2025-03-20 and the second is the latest model.

TTS instcutions used:
Speak in an exaggerated, theatrical tone, reminiscent of a Shakespearean stage actor from the Elizabethan era. Emphasize every syllable with dramatic flair, rolling R’s and elongating vowels. Your cadence should rise and fall as if declaiming poetry Occasionally add chuckles, groans, or grunts of faux embarrassment.

4

We’re hitting this too. Tested 16 multi-sentence inputs (~80–180 chars, en/es/fr/de) through gpt-4o-mini-tts (default snapshot, voice=alloy, response_format=pcm) — 3 of 16 came back with the final sentence missing. ~19% on this input shape.

This is a real production blocker: a ~20% silent failure where the request returns 200 with truncated audio (no error, no retry signal) is very hard to ship around without building duration-vs-text sanity checks on every call. Any ETA on a fix in the current snapshot?

5

We have the same issue - TTS cuts off or says only part of the response (typically the part in speech marks). Switching to the old model is a lot better but still seeing maybe a 5% error rate. It’s closer to 20% with the newer snapshot. It’s impacting our users. Let’s hope OpenAI puts some effort into fixing this.

6

Same issue here, final sentence truncated…
Any feedback from OpenAI ?

7

We also use, and really like, 2025-03-20. Our product is used in K-12 education. We’d prefer to keep 2025-03-20, but it seems that’s not going to be possible.

We’ve looked at this truncation issue on 2025-12-15 ourselves. On 50 samples, 5 are truncated. In all cases, the truncation is tolerable. In our sample, it only occurs where there is a very short question at the end of the sample, such as:

“… now try converting 2500 millilitres into litres using the same method. What do you get?”

" … read the first paragraph again slowly and see if you can find both ages. What does it say?"

" … counting up is often easier than taking away when the numbers cross a thousand. Now try 3000 − 700 using the same method—what do you get?"

“…you need to find out how old she was when she was sent to France. Scan the second paragraph of the sheet—the answer is in there. What does it say?”

“…they stay green all year because the climate is hot and wet, with just a wet season and a dry season instead of four seasons. Does that make sense?”

In all these cases ‘what do you get/what does it say/does that make sense’ is missing in 2025-12-15 but not in 2025-03-20. This is odd and a bit frustrating, but not disastrous.

Sharing our findings in case they are useful for others. And if OpenAI are still working on this model, then would be wonderful if it could be fixed.

8

Summary

On the non-realtime Speech endpoint (POST /v1/audio/speech, model alias gpt-4o-mini-tts, which currently resolves to the 2025-12-15 snapshot), the model intermittently returns HTTP 200 with a well-formed audio/mpeg MP3 that is silent or has a whole sentence missing, with no error signal of any kind. I’ve characterized it across 220 controlled calls with PCM amplitude analysis. Filed as support case 11763173 but it keeps getting routed as a consumer UI issue, so posting here where the API/audio folks can see it.

What happens

The request succeeds, the payload is a valid MP3, but the decoded audio is empty or missing content. Only PCM decoding reveals it — a healthy sample peaks in the tens of percent of full scale (median ~63%, range 37–87% over 150 calls); a silent one peaks below 0.25%. Across 172 measured samples there were zero in between. Four distinct manifestations, all on HTTP 200:

  1. Total collapse (short inputs): a fixed 5,760-byte buffer = 15 MPEG2-L3 frames = 0.360s, silent.
  2. Full-size silence: e.g. a ~31 KB / ~2s buffer entirely silent (peak 0.01% FS) — normal size, zero content.
  3. Tail truncation (long inputs): near-normal-size buffer with the final sentence simply absent from the audio.
  4. Mid-sentence drop: one sample dropped both the 2nd and 5th sentence of a 5-sentence input, rendered fluidly over full duration.

Key point: buffer size is not a reliable indicator of content. Only mode 1 is catchable by a size threshold; modes 2–4 carry the byte count of healthy audio.

Non-determinism

Same input, identical parameters, different outputs — including different content among the fixed-size silent clips themselves. This points to the failure originating in generation, not a fixed fallback asset. I confirmed it’s not the MP3 encoder: requesting response_format: pcm shows the same silent rate as mp3 (12.0% vs 12.0% on a short input, paired A/B) — one input pair returned silent audio in both formats simultaneously.

Rates (pooled over 220 calls, PCM-measured)

Silent-collapse rate scales inversely with input length:

  • 1 sentence: ~14%
  • 3 sentences (57 chars): ~7%
  • 5 sentences: ~1–2%

Sentence-drop appears on the longest inputs. Retrying usually returns valid audio, so it’s transient — but undetectable without post-generation validation.

Reproduction

Send "Ciao!" to gpt-4o-mini-tts (voice=echo, speed=1.0) ~30–60 times, decode each MP3 to PCM, measure peak amplitude. Roughly 1 in 7 short-input calls returns silence, most exactly 5,760 bytes. For truncation, use a 5-sentence input.

Context

The previous snapshot 2025-03-20 is reported not to have the truncation failure, but it’s scheduled for shutdown 2026-07-23 with 2025-12-15 as the substitute. Has anyone else seen this on the December snapshot? And is there a recommended stable path for non-realtime TTS that doesn’t exhibit it?

Happy to share the full CSV (200 calls, all request IDs, peak amplitudes) and sample audio.

9

Consolidating what’s stated in this thread:

~19% truncation across 16 multi-sentence inputs (@duerr.simon),

~20% on 12-15 vs ~5% on 03-20 (@alexred20),

5/50 tolerable (@Bruce-Greig), and Vincenzo’s silent-200s.

that’s not hearsay anymore, it’s a measured regression across independent stacks. and silent HTTP 200 is the worst failure mode of the bunch: nothing alerts, the failure ships to users invisibly.

On the “any feedback from OpenAI” question: file structured reports like Vincenzo’s as regressions, and volume before the cutoff matters. A forced migration onto a measurably worse snapshot is exactly what the notice period exists to catch. One more lever most people miss: the deprecations page mentions dedicated capacity for continued access after shutdown, via their sales team. for K-12 or health production loads, that ask is worth making while the regression gets sorted.