Developers

How long does AI video generation take? Sume jobs, runs, and limits

Sume's docs put one video job at 30 seconds to several minutes and a long-form Format run at 15 to 30 minutes. Here are the phases, stall signs, and limits.

5 min readSume
All posts

On Sume, a single video generation job typically takes 30 seconds to several minutes, depending on the model and its parameters, and a Format run that makes long-form host video typically finishes in 15 to 30 minutes. Because video takes that long, Sume runs it asynchronously: you submit, keep the id, and poll or take a webhook.

These figures are the ones Sume's docs state, mainly Video Generation, the Format API, and Runs and results, read on 2026-09-26. Sume publishes no per-job ETA, and this post adds no benchmarks.

How long does each kind of video job take?

The docs describe typical ranges, not promises. They are times to make a video, not its length: avatar scripts and multi-scene plans must come to an estimated 4 to 60 seconds of video, and per-model clip lengths are in AI video length limits by model.

From Video Generation, Generate avatar video, Jobs and results, Waiting for runs and jobs, and the Format API, read 2026-09-26.
WorkWhat the docs say
Video job, POST /v1/videosTypically 30 seconds to several minutes, depending on the model and parameters.
Avatar video jobRoutinely runs minutes and does not finish inside the 30-second sync wait. The avatar docs list quality: "max" as "Highest quality tier; slower turnaround."
Video Format runRoutinely 10 to 20 minutes, per the SDK docs, whose subscribeFormatRun waits 20 minutes by default.
Long-form host video, Format runTypically 15 to 30 minutes.

What makes a video job take longer?

The docs name these factors:

  • The model and its settings. Higher resolutions take longer to generate and cost more.
  • Server load. A /v1/videos job that stays pending can take several minutes depending on the model, resolution, and server load. The advice is to keep polling at regular intervals.
  • Your workspace queue. queued is a normal accepted state, and concurrency limits apply when workers move jobs into processing, so a job may wait for a slot first.
  • Not the mode. How you learn the outcome never changes what a job costs or how long it takes to run.

Where does the time go in a Format run?

A Format run's events_url, GET /v1/format-runs/{run_id}/events, returns a phase timeline. Each entry has an at timestamp, a phase, a status (pending, running, done, warning, error, or skipped), and a duration_ms when the phase measured itself. There are three phases:

  • preparing: everything before the agent has the run in hand.
  • running: the agent working the recipe, which the docs call where the time goes.
  • finalizing: teardown and output harvest.
{
  "data": [
    { "at": "2026-08-23T23:23:41.000Z", "phase": "preparing", "status": "done", "duration_ms": 1840 },
    { "at": "2026-08-23T23:31:12.000Z", "phase": "running", "status": "running", "duration_ms": null },
    { "at": "2026-08-23T23:40:57.000Z", "phase": "finalizing", "status": "done", "duration_ms": 620 }
  ]
}

How do I tell a slow run from a stalled one?

Read the last timeline entry. Consecutive entries with the same phase and status collapse into one whose at keeps advancing, so at on the last entry is the run's progress clock. If it stops moving for several minutes, the docs say the run is stalled, not slow, and it will be finalized at the limits below. Showing progress covers the UI side.

A run stuck in queued has its own signal: queue.state turns runtime_unavailable once the run has waited past the normal pickup window with nothing claiming it. One that lasts more than a few minutes is worth a support ticket with the request_id.

What are the time limits?

These are the limits the docs publish:

  • Format run ceiling. A run still going past the expires_at on its receipt is force-finalized as failed. That deadline is at most 90 minutes after created_at; the Format run lifecycle has the full rule.
  • Unfinished work at the limit. A run that reaches its time limit with generation jobs still unfinished fails with incomplete_assembly, and details.pending_jobs[] names them. Continue it with previous_run_id; the finished clips are on the thread and are not regenerated.
  • The 30-second wait. wait_timeout_seconds on a sync or subscribe submit is clamped to 0–30. It bounds the HTTP request, not the job, and a wait that runs out still returns the job id.
  • Job timeouts. A failed job's error category can be generation_timeout or worker_timeout; for both, the docs say to poll status or retry later.

How long should my client wait before it gives up?

Size your deadline from the ranges above:

  • Jobs: the docs call a 20-minute client-side deadline reasonable for video, and waitForJob in @sume-com/sdk defaults to 20 minutes. The video docs suggest polling about every 30 seconds.
  • Format runs: subscribeFormatRun defaults to 20 minutes and waitForRun to 10. Long-form host video can outlast both, so the cookbook raises the timeout for long-form video (its example uses 45 minutes) and treats expires_at as the honest ceiling.
  • A client timeout cancels nothing. The job or run keeps running and still bills; keep the id and read it back later.

Sources

Related posts

Written by Sume