Sume timeline render costs $0.10 per minute: 30 s vs 61 s cuts

A Sume timeline render is billed at $0.10 per started output minute, which the timeline docs write as $0.10 per ceil(output minute). The reserve is computed from audio.duration_seconds, divided by 60 and rounded up. The job uses no provider inference, only worker ffmpeg, which is why the price is so low.

Rounding up is the whole trick

Because the minute rounds up, a 60-second cut and a 61-second cut differ by a full 10 cents. The audio.duration_seconds field accepts 1 to 1,800, so the largest single render is 30 minutes.

Preview the price for free

POST /v1/timeline-1.0/plan is unbilled. Per the docs it returns billable_minutes and estimated_cost_usd_micros and does not create a job, reserve credits or download media. That makes it the cheapest way to check whether trimming two seconds would drop a render into a cheaper minute.

When the render price matters and when it does not

At $0.10 a minute the render is rounding error next to generated footage. A 30-second Wan 720p clip is $3.75; the render of a one-minute cut is 2.7 percent of that. The place it matters is bulk work: a thousand short renders of 61 seconds cost $200.00, where trimming each to 60 seconds would cost $100.00.

The other trap is output frame rate. The docs say that if you omit output.fps, the render follows the rate of the sources, and a mismatch makes the job repeat or drop frames. That does not change the price, but it is cheaper to set the rate once than to render twice.

Practical tips

• If a cut lands a few seconds over a minute, trim the tail; the saving is the full minute rate.
• Several short renders cost more than one long one: three 20-second renders are $0.30, one 60-second render is $0.10.
• The default output is 1080 by 1920 MP4, so vertical ads need no extra setting. Confirm the live rate in GET /v1/catalog.