The longest single Timeline render: 30 minutes, 200 slots, $3.00

One Timeline 1.0 render can run up to 1,800 seconds (30 minutes) with up to 200 video slots, so the most a single render costs is 30 x $0.10 = $3.00. With 200 slots over 1,800 seconds, each slot averages 9 seconds.

Ceilings

From the Timeline docs and catalog, read 2026-10-09.

Render strategy

render.strategy defaults to auto, which chunks past 12 segments. single is refused above 12 slots with render_strategy_unsafe. So a 200-slot job is rendered in chunks without you asking.

Pitfalls on a long timeline

• video[0].start must be 0, and later starts must increase.
• More than 8 adjacent fades returns too_many_chained_transitions; insert a hard cut.
• Mixed source frame rates cause output_fps_resamples_sources; set output.fps to 24, 25, 30 or 60.
• Every URL must be on media.sume.com; import files first.

curl -X POST https://api.sume.com/v1/timeline-1.0/render \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: long-001" \
  -d '{"audio":{"url":"https://media.sume.com/artifacts/artf_demo/spine.wav","duration_seconds":1800},"video":[{"source_url":"https://media.sume.com/artifacts/artf_demo/a.mp4","start":0,"duration":9}],"render":{"strategy":"auto"}}'

Cost versus splitting

Rendering 30 minutes as three 10-minute files costs the same 3 x $1.00 = $3.00, since billing is per minute. Split only when you want separate deliverables. Use the free plan call to see billable_minutes first.

Planning a long cut

A 30-minute render with 200 slots is a heavy job, so use plan to confirm segment_count and billable_minutes first. If a render fails because of a source problem, you can fix that one slot and re-submit with a new idempotency key. For cost, the maximum is predictable: it can never exceed $3.00 per single render at the public rate, so 10 such renders cap at $30.00. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.