ElevenLabs TTS concurrency limit vs Sume's queued jobs

On Sume, a workspace at its generation concurrency limit does not get a rejected submit: the docs say concurrency is a dispatch limit, not a submit limit, so extra valid jobs are accepted as queued until the queue is full. Sume's limit is per workspace for paid generation jobs, not a separate cap for TTS, music or dubbing.

ElevenLabs facts are from its changelog; Sume facts from Generation admission and the API reference, read 2026-09-30.

What did ElevenLabs add?

The September 28 changelog entry lists enterprise API key concurrency limits named tts_concurrency_limit, music_concurrency_limit and dubbing_concurrency_limit. The entry does not say what happens to a request over a limit.

What happens to a TTS job over the limit on Sume?

Sume's TTS is an asynchronous job with polling or a webhook, per the reference. The job moves from queued to processing when a workspace slot opens. Only when the queue is also full does a submit fail, with 429 queue_full; request volume over an abuse limit returns 429 rate_limited.

How should my client behave?

Do not treat queued as failure. Store the job_id, poll status with backoff, and fetch the result when result_ready is true. Size a batch from generation_limits in the submit response rather than the static table, since admin overrides can raise the effective limit.

Do prepaid top-ups raise the limit?

No. The docs say generation concurrency is plan-only and prepaid top-ups do not raise it. For the same comparison on a different vendor, see Gemini tiers vs Sume plan concurrency.