A 12-minute video job costs 24 status reads at 30 s and 360 at 2 s

A 12-minute video job takes 24 status reads if you poll every 30 seconds, and 360 reads if you poll every 2 seconds. Sume's video guide recommends a moderate interval such as 30 seconds, and the TypeScript SDK uses 2 seconds as a floor that a longer next_poll_after_seconds overrides. The difference is a factor of fifteen in read traffic for the same job.

That factor matters on the days a new model launches and everyone resubmits at once. Read endpoints can be rate limited separately from submits, and Sume describes those limits as poll backpressure, so a tight loop across many jobs spends your read budget on nothing.

The numbers

The arithmetic is 720 / 30 = 24 and 720 / 2 = 360, then 1,200 / 30 = 40 and 1,200 / 2 = 600.

Run it

The check below prints the same figures, so you can change the minutes and the intervals for your own jobs.

minutes = 12
for label, seconds in (("30 s docs interval", 30), ("2 s SDK floor", 2)):
    print(label, minutes * 60 // seconds, "status reads")
print("20 min deadline at 30 s:", 20 * 60 // 30)

What the docs say to do instead of a fixed sleep

Video, avatar-video, and face-swap jobs usually outlast the 30-second sync wait, so use async for them and keep the loop in your client.

• Obey next_poll_after_seconds from the submit envelope when it is present, and use exponential backoff when it is not.
• Stop on terminal: true, then fetch the result when result_ready is true.
• Set the overall deadline in your client. The 20 minutes used by waitForJob and subscribeFormatRun is a client default, and wait_timeout_seconds never exceeds 30.
• A client timeout does not cancel the job. The job still runs and still bills, so store the job id.

When to skip polling

Use a webhook if your server can receive one. Send mode: "webhook" with a public HTTPS webhook_url, verify the signature, and keep one slow poll as a backstop for deliveries that never arrive. Webhooks are an optimization, not the only recovery path, so keep the status URL stored with the job id.

Why the wait is not the job

The wait_timeout_seconds field clamps to 0 through 30 and limits how long the submit request blocks, not how long the job takes. Image jobs often finish inside that wait. Video jobs usually do not, so a response with sync.timed_out: true is normal, and the right move is to poll the same job id, never to submit again.

Queued time counts too. On a plan with one processing slot, a job can sit in queued while an earlier job renders, and queued is a normal accepted state. If you size your deadline from render time alone, jobs that waited in line will hit the deadline while still healthy. Add the expected wait to the deadline, or read generation_limits on the submit response to see how much is ahead of you.

Finally, remember that these figures are reads for one job. Multiply by the number of jobs in flight to get your request rate. Twenty jobs at a 2-second interval is ten reads per second, and the same twenty jobs at 30 seconds is less than one read per second.