Timeline refuses more than 8 chained fades: countdown cut fix

More than 8 adjacent fades in a Sume Timeline 1.0 request are refused with too_many_chained_transitions. For a countdown with 12 or more clips, put a hard cut between every second fade, or use a hard cut everywhere and one fade at the end.

Rules related to transitions

From the Timeline docs, as of 2026-10-08.

• More than 8 adjacent fades: too_many_chained_transitions.
• A transition longer than the neighbors: transition_too_long.
• A transition not aligned to the frame rate: transition_not_frame_aligned.
• Single strategy: 12 segments or fewer.

Pattern for 14 clips

Fourteen clips have 13 joins. Fading all 13 breaks the limit. Alternate: fade, cut, fade, cut gives 7 fades with no adjacency, which is well under 8.

Frame alignment

Pick transition lengths that are whole frames at your output.fps. At 30 fps, 0.5 seconds is 15 frames and 0.2 seconds is 6 frames; at 24 fps, 0.25 seconds is 6 frames. Run the plan endpoint, which is not billed, to find any alignment errors before the paid render, as the docs recommend.

Why the limit exists

The docs refuse long fade runs at validation time instead of letting the render fail late. The practical effect is simple: validate with the plan endpoint, which is free, and fix the pattern before you pay for the render.

For a countdown the cut is itself a good device: a hard cut on the number change reads as a tick, and the fade is kept for the end card.

• Use the plan endpoint for every new template.
• Keep fades under half the clip length.
• Re-run the plan after you change fps.

Before you scale

Validate the transition length too. A transition that is longer than a neighboring segment is refused as transition_too_long, and one that does not land on a frame boundary is refused as transition_not_frame_aligned. For a quick countdown with one-second numerals, a 0.2 second fade is safe at 24, 25 and 30 fps only if it lands on whole frames, so test at your real fps.