16 AI shots in one Sume Timeline render: the 8-fade cap

Sixteen shots fit in one Timeline render, but you cannot put a fade between every pair: Sume refuses more than 8 adjacent fades and asks you to insert a hard cut. A render with more than 12 slots is also chunked by default.

This matters when you rebuild a 16-keyframe sequence, like the one Luma lists for Ray 3.2, out of 16 separate clips.

The limits that apply

From the Timeline 1.0 docs: video[] takes 1 to 200 slots, audio.duration_seconds is 1 to 1800, video[0].start must be 0, and later starts must increase. A transition is allowed only on slots after the first. Duration is at most 1 second, at most 50% of the shorter neighbor, and at least one output frame.

Plan 16 slots with 15 joins

Sixteen slots make 15 joins. If every join were a fade, 15 adjacent fades would break the 8 limit. Insert a hard cut after at most 8 fades. One workable layout is 8 fades, one cut, then 6 fades, and one cut, which uses 14 fades across 15 joins with the cuts as natural scene boundaries.

Hard cuts are not a downgrade. Group the shots into scenes, fade inside a scene, and cut between scenes.

Leave the strategy on auto

With 16 slots you are above 12, so render.strategy: single is refused with render_strategy_unsafe. Leave the field out (default auto), or send chunked. The docs say auto chunks past 12 segments, so you do not need to split the job yourself.

Check it before you pay

POST /v1/timeline-1.0/plan is unbilled. It returns duration_seconds, segment_count, billable_minutes, estimated_cost_usd_micros and a filtergraph_summary, and it does not create a job. The render itself is priced at $0.10 per ceil(output minute). A plan cannot predict warnings about short sources that are padded or looped.

Every source_url must already be a media.sume.com artifact or asset in your workspace, and render needs an Idempotency-Key. Import generated clips first with POST /v1/media-imports.

curl -X POST https://api.sume.com/v1/timeline-1.0/plan \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"audio":{"mode":"silence","duration_seconds":48},
       "video":[{"source_url":"https://media.sume.com/artifacts/artf_demo/s01.mp4","start":0,"duration":3},
                {"source_url":"https://media.sume.com/artifacts/artf_demo/s02.mp4","start":3,"duration":3,
                 "transition":{"type":"fade","duration":0.25}}]}'

What a 16-shot cut costs

A 16-shot cut of 48 seconds bills one ceil(48/60) = 1 minute, so $0.10 for the render. The clips themselves are separate video jobs. Mixed frame rates across clips are the usual trouble: if you omit output.fps the job follows the sources, and a mismatch warns with output_fps_resamples_sources.

A layout you can paste

Index the 16 slots 1 to 16. Slot 1 has no transition. Give slots 2 to 9 a 0.25 second fade (8 fades in a row, the maximum). Slot 10 has no transition field, which makes a hard cut. Give slots 11 to 15 a fade, and slot 16 a hard cut or a fade of your choice, since the chain was already broken at slot 10. Keep each fade at or under 1 second and under half the shorter neighbor, so a 0.25 second fade between two 3-second slots is safe.

If a render is refused with too_many_chained_transitions, count the adjacent fades and break the run with one cut. If it is refused with transition_too_long, shorten the fade, not the slot.

Timing arithmetic

Starts are authoritative: you declare each video[].start, and the compiler compensates for the crossfade overlap without pre-shifting. For 16 slots of 3 seconds the starts are 0, 3, 6 and so on up to 45, and audio.duration_seconds is 48. The last slot must end within 0.5 seconds of the spine end, which here it does exactly.

A slot shorter than 0.2 seconds is refused, so very fast cutting at 24 fps needs at least 5 frames per slot. The docs also state that a transition must last at least one output frame.