How many Sume jobs can one key poll at once? Reads per minute by plan

Divide your plan's read budget by the reads one job costs per minute. A poller that checks each job every 2 seconds spends 60 / 2 = 30 reads per job per minute. That gives about 160 jobs on Free, 400 on Pro, 800 on Startup and 1600 on Scale, before you leave any room for other reads. The numbers are a ceiling for the status poller alone, so plan for a fraction of them.

The budget by plan

Sume counts every GET and HEAD as a read. Reads have their own budget, which is 40 times the write budget, so polling does not eat into the writes that submit new jobs. Enterprise uses the Scale row until your limits are provisioned.

Run the arithmetic

The script divides each plan's read budget by the reads per job. Change pollSeconds to see the effect: at 5 seconds a job costs 12 reads per minute and the Free ceiling rises to 400.

// Reads per minute per plan, from the Sume docs read 2026-10-08
const readsPerMinute = { Free: 4800, Pro: 12000, Startup: 24000, Scale: 48000 };
const pollSeconds = 2; // waitForJob floor
const perJob = 60 / pollSeconds; // reads per job per minute
for (const [plan, reads] of Object.entries(readsPerMinute)) {
  console.log(`${plan}: ${reads} / ${perJob} = ${Math.floor(reads / perJob)} jobs`);
}

Why the real number is lower

For big batches, the better fix is fewer reads: use webhooks as the main signal and keep a slow poll as a backstop. The webhooks docs list the job.completed, job.failed and job.canceled events. With a webhook per job, a batch of 1000 jobs needs no steady polling at all. Poll once at a slow interval, such as every 30 seconds, to catch a delivery that failed, and each job then costs 2 reads per minute instead of 30. At that rate the Free ceiling would be 4800 / 2 = 2400 jobs.

• The Node SDK waitForJob polls no faster than every 2 seconds, and when the job record carries a longer next_poll_after_seconds, that longer wait wins. Long video jobs usually sit well under the ceiling.
• Your dashboards, list calls and balance checks are reads too. They share the same per-minute budget.
• A 429 names the budget in error.details.scope, read or write. Check it before you decide which budget ran out.
• Sleep until ratelimit-reset or retry-after when you get a 429. Do not retry in a tight loop.
• Pace by the ratelimit-remaining header too. It tells you how much of the current window is left after each response.