Extend, chain, or first-last-frame continuations
Three ways to carry a shot past a model's duration ceiling, compared on look-hold, camera continuity, credit cost, and what a bad segment costs to fix.
Every video model stops at a duration ceiling, and every shot longer than that ceiling has to be assembled from more than one generation. There are three mechanisms for doing it, and most people pick one on vibes — extend because it's the button that says "longer," first-last-frame because someone said it was more controllable. That's the wrong basis. The three differ on four axes that actually matter in production, and only one of those axes gets discussed: how well the look holds. The one that decides your week is the fourth — what a bad segment costs you.
The three mechanisms, mechanically
Native extend feeds a finished clip back to a model and asks for more of it. Versely's extend_video tool takes a video_url plus an optional continuation prompt, model and duration; the catalog carries a dedicated extend-video family for it, including Flux 3 Extend Video and VEO 3.1 Extend Video, both of which take a video as a required input and will not run from a still. Grok Imagine Extend is the variant worth reading the listing on: it continues an existing Grok Imagine video from a chosen timestamp, in 6- or 10-second increments, rather than accepting arbitrary footage. The video extend glossary entry covers the mechanic itself.
Keyframe chaining takes the last frame of segment N and uses it as the first frame of segment N+1. You can do this by hand with extract_video_frames, or let a movie project do it: create_ai_movie exposes previous_scene_image_to_video and previous_scene_first_last_frame as scene generation types, and the backend pulls the last frame from each completed scene automatically and hands it to the next one. Scenes run in order, each dependent scene waiting on its predecessor.
First-last-frame bracketing is the odd one out. Instead of continuing from something, you define both ends of a segment as stills you own and ask the model to solve only the motion between them. generate_video_from_image takes first_frame_url and last_frame_url in place of image_url; the catalog side of this is Flux 3 First Last Frame to Video, plus the VEO First Last Frame and Pixverse Transition variants. The first-last-frame entry has the fuller explanation, and there's a dedicated walkthrough of keyframe chaining for longer scenes if you want the technique rather than the comparison.
The decision table
| Native extend | Keyframe chaining | First-last-frame bracketing | |
|---|---|---|---|
| What it inherits | Rendered pixels and motion state | One still frame | Two stills you control |
| Look-hold over 3 segments | Degrades — errors compound | Degrades more slowly | Holds, because both ends are fixed |
| Camera continuity | Best. Motion vector survives the join | Weakest. Camera restarts from a static frame | Controlled, but you have to imply the move in the two stills |
| Credit cost | One generation per segment | One generation per segment, plus a frame extraction | One generation per segment, plus authoring two stills |
| Bad segment 3 of 5 | Segments 4 and 5 are also dead | Segments 4 and 5 are also dead | Reroll segment 3 alone |
| Best at | Holding a moving camera through a long take | Long scenes where each beat differs | Anything you'll iterate on |
The row that changes plans is the second-to-last one. Extend and chaining are both sequential dependencies: each segment is derived from the rendered output of the one before it. Reject segment 3 and everything downstream of it was built on a frame that no longer exists. First-last-frame bracketing is the only one of the three where segments are independent — the boundaries are stills sitting in your library, so segment 3 can be rerolled twenty times without segments 4 and 5 noticing.
Why extend holds the camera and chaining doesn't
Native extend passes the model more than a picture. It gets the tail of an actual clip, which encodes velocity: the direction the camera was travelling, how fast, whether it was easing. A push-in that was mid-move at the cut keeps pushing. That is the single thing extend is genuinely better at, and it's why a slow dolly or a continuous orbit is an extend job and not a chaining job.
Keyframe chaining throws that away by construction. A single still has no velocity. The model receives a frame with no information about whether the camera was moving when it was captured, so segment 2 opens from a standing start and then invents its own move. On a locked-off shot this is invisible. On a moving shot it reads as a hitch at every join — the camera stops, thinks, and starts again. If you're chaining and the joins feel stuttery, that's the cause, and no amount of prompt rewriting fixes it because the input genuinely doesn't contain the missing information.
The flip side is temporal consistency over distance. Extend inherits everything, including the drift. Whatever the model got slightly wrong in segment 1 becomes segment 2's ground truth, and by segment 4 you're looking at a compounding error the model has been treating as correct the whole time. Chaining resets that partially — a still frame carries the drift that existed at that instant, but not the momentum of the drift. Bracketing resets it entirely at every boundary, because the boundary is a frame you chose.
Credit cost is a red herring; reroll cost isn't
All three mechanisms bill the same way at the core: one video generation per segment, at whatever the model charges for that length and resolution. The differences are at the edges. Chaining by hand adds a frame extraction step with extract_video_frames. Bracketing adds an image generation per boundary, because the end-frame stills have to come from somewhere. Neither edge cost is on the scale of a video generation, and neither changes the shape of the decision.
That difference is trivial next to the reroll asymmetry. Model it with your own hit rate. If a five-segment sequence needs a reroll in the middle:
- Extend or chaining: reroll segment 3, then regenerate 4 and 5 because their inputs changed. Three video generations, plus whatever it takes to get segment 3 right.
- Bracketing: reroll segment 3. One generation per attempt. Segments 4 and 5 are untouched and already paid for.
At a 70% per-segment hit rate, the expected number of generations to land a clean five-segment sequence is materially higher on the dependent paths, and the gap widens with every segment you add. This is the same structural point as budgeting credits against the shots you throw away: the cost of a workflow is not the cost of one successful pass through it.
When to combine two
The mechanisms are not exclusive, and the two combinations worth knowing are both about buying extend's camera continuity without inheriting its compounding drift.
Bracket the arc, extend inside it. Define stills at each beat change — the moments the shot's intent shifts — and bracket between them. Where a single bracketed segment needs to run longer than the model's ceiling, use extend to carry it, not chaining, so the camera move survives. You get independent, rerollable beats with continuous camera inside each one.
Chain the scene, extend the hero shot. In a multi-scene piece where each scene is its own space, chaining via previous_scene_image_to_video is enough for the cuts — a still is a fine handoff when the camera was going to restart anyway. Reserve extend for the one shot that has to breathe, and accept that the shot is a single dependent run you may have to redo whole.
What you should not do is chain a moving camera and then try to prompt the hitch away, or extend six times in a row and expect segment 6 to still look like segment 1. Both are the mechanism working exactly as designed, being asked to do the other one's job. If you want a starting point in the catalog, the best video extender models ranks the extend family, and the Flux 3 Extend Video vs VEO 3.1 Extend Video comparison puts the two most-used endpoints side by side.
FAQ
Can I extend a clip that itself came from an extend?
Yes, and it's the normal way people hit the drift ceiling. Each pass inherits the previous pass's output as truth, so errors accumulate rather than reset. Watch specifically for wardrobe detail, background geometry and skin tone — those drift first and are the earliest reliable signal that the next extend won't be usable.
Does first-last-frame bracketing need a model that names the feature?
It needs an endpoint that accepts two frames. In Versely that means passing first_frame_url and last_frame_url to generate_video_from_image against a first-last-frame variant — when first_frame_url is set, image_url can be omitted. An ordinary image-to-video endpoint is not a bracketing endpoint, so check the model's own input schema before assuming a second frame will be honoured — get_model_input_schema returns the exact accepted fields per provider route.
Which one should I default to if I don't know yet?
Bracketing, unless the camera is moving. It's the only one of the three that lets you fix a segment without paying for its neighbours, which is the property you want during the phase where you don't yet know what the sequence should look like. Switch to extend once the shot is locked and the remaining problem is length rather than content.
Is stitching the segments together an extra charge per clip?
No. The editor is EDL-based — one timeline, re-renderable — and the final export is charged once regardless of how many clips are on it. You can also render a 480p preview pass first at no credit cost to check the joins, subject to a short per-user cooldown. Extending video length walks through the assembly side.