Submit 20 music takes at once: queued is normal, queue_full is not

Submitting twenty music takes at once works on Sume only if your workspace can accept twenty paid jobs; queued is a normal accepted state, but a full queue returns 429 queue_full. The generation admission docs, read 2026-10-03, list default accepted job capacity of 6 on Free, 24 on Pro, 48 on Startup and 120 on Scale and Enterprise, so twenty at once fits Pro and above but not Free.

What does each plan accept?

Concurrency is a dispatch limit, not a submit limit: a workspace at its processing cap still accepts jobs as queued while queue capacity remains. The docs say to prefer the effective generation_limits.concurrency_limit field over the static table, because overrides exist.

What do I do on queue_full?

Wait for jobs to finish or cancel queued ones, then retry with the same Idempotency-Key, as the docs advise. Keep a counter of jobs you have in flight and submit the next take when one reaches completed, failed or canceled. A different error, 429 rate_limited, is abuse protection on request volume, and the docs say to back off using retry-after when present.

What does this not tell you?

• How long a queued music job waits depends on your plan's processing concurrency and on engine speed; the docs give no figure.
• Each take is billed once accepted, so queueing twenty is a $2.50 commitment at the fixed $0.125 price.
• The table is defaults. Admin overrides can raise a limit, so read your own workspace's limits.