Recast a 2-minute video: four 30 s jobs, $45 at 768p on Sume

A 2-minute video needs four H3 Max Recast jobs of 30 seconds each, because one job accepts 5 to 30 seconds of source. At 768p that is 120 seconds x $0.375 = $45.00; at 1080p it is 120 x $0.5625 = $67.50 before any per-job rounding.

The per-second prices come from the fal list of $0.30 (768p) and $0.45 (1080p) per second (read in the Sume docs 2026-10-05), times Sume's 1.25 multiple. Recast bills the source length rounded up to a whole second, and the output keeps the source motion, camera, cuts and sound.

The rules that shape the split

The Video Router catalog row for h3-max-recast takes one video_url plus 1 to 4 reference_image_urls, one photo for each new person. The duration is the length of the source video, rounded up, between 5 and 30 seconds, and no shot may be longer than 15 seconds. The prompt is optional, with a limit of 2000 characters. The default resolution is 768p, and 1080p is the other option.

That means your cut points matter twice: they keep each part under 30 seconds, and they must not hide a single continuous shot longer than 15 seconds inside a part. Cut on existing shot changes where you can. The Sume video trim API cuts a [start, end) range from a Sume-hosted clip into a new MP4, and the job is polled through the normal jobs routes.

The cost table

Here is the arithmetic for common lengths. Each row assumes the source is split into 30-second parts, with the last part rounded up to a whole second.

What to do to keep the bill down

Because a Recast bills by source seconds, trimming dead air before you submit is the only lever that lowers the price. A 2-minute video with 12 seconds of title cards and black frames costs $4.50 less at 768p if you swap only the people-bearing 108 seconds. Keep the cards out of the Recast source and re-join them later.

A second lever is resolution. Run the whole video at 768p, check the swap on a few scenes, and only take the final cut to 1080p if the delivery needs it. Moving from 768p to 1080p multiplies the price by 1.5, from $0.375 to $0.5625 per second.

• Trim non-person segments out first; they do not need a swap.
• Check one 30-second part at 768p before you queue the other three.
• Use an Idempotency-Key per part so a retry after a timeout does not bill twice.

Waiting for four jobs

The jobs docs say a sync submit waits at most 30 seconds, and that a non-terminal job should be polled rather than resubmitted. A 30-second source will usually outlast that wait, so submit with async or webhook, store the four job ids, and poll GET /v1/jobs/:id/status or let the signed webhook tell you. Each submit response carries usage.billable_amount_usd_micros, so you can add the four amounts and compare them to the table before the first frame renders.

A practical split plan

Start by listing the shot changes in the finished video. Many ads have a cut every two to five seconds, so the 15-second shot rule rarely bites; it matters for talking-head and interview footage, where one take can run for a minute. For those, cut inside the take at a natural pause, and expect a visible seam where two Recast outputs meet because each job is generated on its own.

Plan the four parts at 30 seconds, but keep a margin: a part of 29.4 seconds rounds up to 30 and bills for 30, so a part of exactly 30.0 and a part of 29.4 cost the same. If the video is 118 seconds, three parts of 30 and one of 28 bill 118 seconds, which is $44.25 at 768p.

Joining the outputs

Each Recast output keeps the source sound, so the audio in each part is the original audio for that range. When you join the four parts, cut at the same points where you split and the soundtrack stays continuous. Sume has a Timeline API for assembling clips, and the docs say the audio spine lives there; if you want to replace the music, that is the place to do it, not inside the Recast job.