200 video slots in a 180 s Short: 0.9 s each on Sume Timeline

Timeline 1.0 accepts 1 to 200 video[] slots in one render, and each slot must be at least 0.2 seconds long. In a 180-second Short, 200 slots average 0.9 seconds each (180 / 200). The render bills ceil(180 / 60) = 3 minutes at $0.10, so $0.30, no matter how many slots there are. The slot cap, not the 0.2-second minimum, is the limit: 180 / 0.2 would allow 900 slots, and the API stops at 200.

Slot count against average length

The YouTube Shorts page (read 2026-10-08) sets a limit of three minutes, and Timeline's audio spine accepts 1-1,800 seconds. These are the average slot lengths in a 180-second render.

Transitions limit how fast you can cut

A transition must last at most 1 second, at most 50 percent of the shorter neighbouring slot, and at least one output frame. With 0.9-second slots, the longest fade is 0.45 seconds. The render also refuses more than 8 chained transitions in a row (too_many_chained_transitions); insert a hard cut between runs of fades. A 200-slot montage is therefore mostly hard cuts, with a fade now and then.

• video[0].start must be 0, and later starts must increase.
• The last slot may stop at most 0.5 seconds before the end of the spine.
• render.strategy: "single" is refused above 12 slots (render_strategy_unsafe); auto chunks past 12.
• Stills are static holds, so a 0.9-second still is a freeze frame.

Is a 0.9-second average a good idea

It is an extreme setting, and the rule that matters here is the viewer's. Very fast cuts suit a recap or a trailer, and a story with spoken lines needs longer slots. The cap of 200 is a ceiling for the program, not a target. If you generate the slots, each generated clip has its own price and a minimum length (4 seconds for Seedance 2.5, 3 seconds for Gemini Omni Flash 1.1), so 200 generated clips for 180 seconds is not possible; fast cuts come from trimming a longer clip with source_in and a short duration, which is cheap.

Plan before you render

POST /v1/timeline-1.0/plan is unbilled. It checks the schema and the Sume-host URLs, compiles the program and returns duration_seconds, segment_count, billable_minutes and estimated_cost_usd_micros without creating a job. For this render you should see segment_count: 200 and billable_minutes: 3, which is 300,000 micros ($0.30). A plan cannot predict warnings for short sources that get padded or looped, so keep every slot's source at least as long as its duration.