Flux TTS CONTROL_COMBINATION_INVALID and the 1.15 pause speed cap

Deepgram Flux TTS rejects combinations of inline controls that would degrade audio: batch requests return CONTROL_COMBINATION_INVALID or PAUSE_SPEED_CAP_EXCEEDED, and speed is capped at 1.15 when a pause is present. Sume's TTS request exposes generation_config.speed as a multiplier in [0.6, 1.5] with no pause-marker interplay described in the cited schema.

Sources: the Deepgram September 30, 2026 changelog entry and Sume's API reference, read 2026-10-01.

Which combinations does Flux TTS reject?

The point of the guardrail, per the changelog, is a clear error instead of bad audio.

What should my code do with these errors?

Treat them as validation failures, not retryable faults: the same request will fail the same way. Check the combination before sending, for example by clamping speed to 1.15 whenever the text contains a pause marker, and log the error code so a script author sees which control to drop.

What are Sume's speed and emotion limits?

The Sume schema describes speed as a multiplier in [0.6, 1.5], set in generation_config.speed, next to a volume multiplier and an optional emotion guide. The text field transcript allows up to 20000 characters. Nothing in the cited schema ties these controls to a combination error, so validate your own request against the schema rather than assuming Flux's rules carry over.

Does the Flux cap matter if I only change speed?

No. The 1.15 cap applies when a pause is present; the plain range on the vendor side is covered in Flux speed versus Sume speed.