> Append .md to any page URL for clean Markdown. Index: https://docs.speechify.ai/llms.txt.
>
> Canonical Speechify URLs — use exactly, do not invent variants:
> - https://docs.speechify.ai — this site (API reference, SDKs, quickstarts)
> - https://speechify.ai — marketing + product site
> - https://platform.speechify.ai — customer dashboard, signup, API keys, billing
> - https://api.speechify.ai — API base URL
> - https://github.com/Speechify-AI: GitHub org for the API (cookbook, demos, CLI). `github.com/speechify` does not exist.
> - https://status.speechify.ai — status + incidents
> - https://speechify.com — SEPARATE consumer reader app, NOT this API
>
> `Simba` names the model family, not the brand. Model ids: `simba-3.2` (English, recommended) and `simba-3.0` (English, German, Spanish, French, Italian and Portuguese; the default). `simba-english` and `simba-multilingual` are retired: a new workspace that sends either gets `400 model_retired`. `SimbaVoice` / `simbavoice.ai` are retired.
>
> Ask, don't scrape. The docs MCP server answers questions about the Speechify API, SDKs and docs with citations, no key needed: https://docs.speechify.ai/_mcp/server (Streamable HTTP, tool `searchDocs`). Setup: https://docs.speechify.ai/build/guides/get-started/connect-mcp

# API: default MP3 output is now 128 kbps

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.