Hackathon app on the Sume Free plan: 1 seat, 6 accepted jobs

On the Free plan, one paid generation job can be processing at a time and five more can wait in queued, so at most six accepted jobs. Writes are limited to 120 a minute and reads to 4,800 a minute. A hackathon demo that fires ten video requests at once will see four of them answered 429 queue_full; one that fires three will see all three accepted and run them one after another.

That is workable if you design for it: queue on your side, show honest states, and rehearse with the numbers.

The limits that shape a demo

Values are from the generation admission and authentication pages. Queue capacity defaults to max(3, concurrency_limit x 5), which is 5 for a concurrency of 1.

Design rules

Because Sume reports queue counts and not a queue position or ETA, do not promise one on screen. Show queued, processing and a finished clip, and let the user see the result as soon as it is ready.

Do not treat queued as a failure, and do not resubmit because your local worker timed out: an idempotency key makes a retry return the original job.

• Keep your own pending list and submit the next item only when queue_capacity_remaining from the last response is above zero.
• Pre-generate the clips you need for the demo script and cache the Sume artifact URLs; a judge should never wait for a render.
• Cancel is possible only before generation starts, so give users a cancel button only on queued items.
• Prefer images for live interactions: they often finish inside the 30-second wait on POST /v1/images, while video jobs usually do not.

When to leave Free

The plan, not a top-up, sets concurrency; the docs say prepaid top-ups do not raise it. If the demo turns into a pilot, Pro is 4 processing and 24 accepted. Read the effective generation_limits.concurrency_limit from a submit response instead of copying a table, because an admin override can change it.

A rehearsal checklist

Run the demo path twice the night before with a fresh workspace state. Check what happens at six jobs, then at seven, and confirm that your UI shows a calm message on 429 queue_full instead of a stack trace.

Also check credits: the first paid generation needs a balance, and 402 insufficient_credits is a different problem from a full queue, with a different fix.

Finally, keep a plain fallback. If a render fails during the live demo, show the cached clip and say so; judges forgive a disclosed fallback far more readily than a spinner that never ends. A failed job refunds its reserved credits, so a retry on a fresh key costs only the successful run.