Video generation API timeouts: Sume's wait caps, SDK defaults, expiry

On Sume, a client-side timeout on a video generation call ends your wait, never the job: a sync submit blocks for at most 30 seconds, and a job you stop watching keeps running and billing. Set your own deadline in minutes (the docs call 20 minutes reasonable for video), then poll or take a webhook, and do not resubmit the paid request.

The limits below come from Sume's Jobs and results, Waiting for runs and jobs, Runs and results, and Webhooks docs, read on 2026-09-26.

Which timeouts apply to video jobs and runs?

Seven limits are in play. Of these, only Format run expiry ends the work itself; the others end a wait or a delivery attempt.

What deadline should I set on my side?

The overall deadline belongs in your client. It is not wait_timeout_seconds, which never exceeds 30 seconds; sync vs async video generation explains that cap.

• Generation jobs: the docs call 20 minutes reasonable for video. On POST /v1/videos, generation typically takes 30 seconds to several minutes, depending on the model and parameters.
• Format runs: long-form video is 15 to 30 minutes of work. Use the receipt's expires_at as your ceiling rather than inventing one; it is null once the run is terminal.
• Keep polling until terminal is true or your own application deadline passes, honoring next_poll_after_seconds between reads.

What do the SDK timeouts do?

All three helpers poll every 2 seconds by default; for waitForJob that interval is a floor that next_poll_after_seconds can lengthen. The docs note that video Formats routinely run 10–20 minutes. waitForRun checks its deadline before sleeping, not after, and a signal aborts any of the waits and the in-flight request. Waiting in the Sume SDK covers the helpers in full.

A transient read failure does not end a wait at once: createSumeClient retries 408, 429, 5xx, and transport failures twice with exponential backoff and jitter, honoring retry-after, and waitForRun tolerates 6 consecutive transient read failures. For long-form video, raise the timeout:

import { SumeRunTimeoutError, waitForRun } from "@sume-com/sdk";

try {
  const run = await waitForRun(runId, {
    client,
    family: "format",
    timeout: 45 * 60_000, // raise the 10-minute default for long-form video
  });
} catch (error) {
  if (error instanceof SumeRunTimeoutError) {
    // The run is still going. Nothing was lost — read it later from `result_url`.
    await markPending(error.runId, error.lastStatus);
  } else {
    throw error;
  }
}

When does Sume end a job or run on its own?

A Format run is force-finalized as failed at the expires_at bounds in the table. On its phase timeline, if at on the last entry stops moving for several minutes, the run is stalled, not slow, and will be finalized at those bounds.

A run that reaches its time limit with generation jobs still unfinished fails as incomplete_assembly, and details.pending_jobs[] names them. Continue it with previous_run_id; the finished clips are not regenerated.

Generation jobs have no public queue expiration option today. A failed job's error.category can be generation_timeout or worker_timeout; the docs' typical next action for both is to poll status or retry later. Why did my AI video job fail? shows how to read that error.

What happens when my timeout fires?

Nothing changes on Sume's side: the job or run keeps running and billing. Idempotency keys for AI video APIs covers picking it back up without paying twice. In the SDK, the timeout error carries what you need to resume: SumeJobTimeoutError carries jobId, and SumeRunTimeoutError carries runId and lastStatus. Read the work back later with getApiJob or getFormatRun, or cancel it explicitly.

How do MCP and webhook timeouts differ?

A hosted MCP jobs_wait call is one HTTP request held open with nothing transferring, and every edge closes such a request eventually, so the server bounds each slice: timeout_seconds defaults to 50 and is capped at 55, larger values are clamped rather than rejected, and the response says so in wait_slice_clamped. Wait for a ten-minute render by repeating the wait; MCP jobs_wait for long video jobs covers retries and batch waits.

A job webhook receiver gets 10 seconds per attempt, with a fixed delay between attempts (30 seconds by default). Return any 2xx after durably storing the event, and do slow work afterwards.