Luma Ray 3.2 extend with a generation id vs Sume per-clip jobs

Luma's Ray 3.2 extends a video by taking exactly one prior generation id in video.start_frame.generation_id or video.end_frame.generation_id. The Sume video docs describe no extend-by-id field: you submit each clip as its own job, and frame_images entries take a frame_type of first_frame or last_frame.

How does Luma's extend request work?

Luma's model guide, read 2026-10-01, lists "Video extend" as type: "video" with exactly one prior generation id in either the start or end frame. Text-to-video and image-to-video use the same video object with an ImageRef instead.

What is the Sume equivalent?

Per the video docs, frame_images specifies first or last frame images for image-to-video, each with frame_type first_frame or last_frame. To continue a clip, you take a frame from the finished video and submit it as the next job's first_frame; the steps are in extend an AI video past 30 seconds. Whether a given model accepts both frame types is shown in its catalog entry.

How do I keep retries safe and know the cost?

Each Sume clip is a separate paid job. Send an Idempotency-Key so a retry returns the original job, and note that cost is reserved on submit at provider list × 1.25. When a job completes, unsigned_urls lists its content, and /v1/videos/{jobId}/content downloads it with your key.

Will the join look continuous?

The docs do not promise it. A last frame carries composition, not motion or sound, so review the seam and regenerate the next clip if it jumps. For a comparison with another vendor's extend feature, see Veo 3.1 extend versus chaining clips.