Changelog

Requests that ask for MP3 without naming a bitrate now receive 128 kbps instead of 64 kbps. That is audio_format: "mp3" on POST /v1/audio/speech and POST /v1/audio/dialogue, and Accept: audio/mpeg on POST /v1/audio/stream and POST /v1/audio/stream/with-timestamps. The sample rate, channel count, duration and container are unchanged: 24 kHz mono MP3, as before.

At 24 kHz mono, 64 kbps left compression noise only about 12-14 dB below the signal across the 2-11 kHz band, which is audible on sibilants and on the quiet tail of a phrase. 128 kbps puts that noise about 30 dB down, which is where the quality curve stops paying for itself - 160 kbps measures roughly 1 dB better again for 25% more bytes.

What this means for your integration:

• Responses are about twice as large for the same text. Time-to-first-byte is unchanged: the encoder emits its first frame after a fixed amount of audio regardless of bitrate.
• Nothing in the response shape changes. audio_format still reads mp3, and output_format is still echoed only when you set it.
• On /v1/audio/speech and the two stream routes, keep the previous output by sending output_format: "mp3_24000_64". Any request that already names an output_format is unaffected - this changes only what an unspecified bitrate resolves to.
• POST /v1/audio/dialogue has no output_format field, so it has no per-request bitrate control and never did: audio_format: "mp3" there simply encodes at 128 kbps now instead of 64. Use wav or pcm if you need the unencoded audio.

The set of output_format values you can ask for is unchanged. As the audio_format field has always documented, the resolved default is not part of the contract: name the output_format you want if your pipeline depends on it.