Runware Adds LTX-2.3 Video Extension: API Controls and Limits

Runware added video extension for LTX-2.3 on October 22. Developers can supply an existing clip and generate two to 20 additional seconds at its beginning or end, rather than regenerate the whole shot. This is a new platform feature for an existing model, not a new LTX release.

That is useful when the shot is already close to what you need. A product reveal might end just before the camera settles, or an opening might need more room before the action starts. Extension gives an application another editing operation before it asks the user to start again.

How LTX-2.3 video extension works

Runware's dated changelog says the output retains the complete source clip. Landscape output is 1920×1080; a source taller than it is wide produces 1080×1920. The input must be MP4 or MOV, at least three seconds and 73 frames, no larger than 3840×2160 or 100 MB.

The model reference identifies the model as lightricks:ltx@2.3. Supply the source through inputs.video. Here, duration means the footage to add, not the total length of the returned video.

Set settings.extend.mode to end or start; end is the default. The separate settings.extend.context field selects one to 20 seconds of source footage for the model to use, and cannot exceed the source's length.

Keeping the complete clip and reading the complete clip are different things. The output can preserve the original footage while the generation uses only the selected context. For an editing tool, it is worth showing those as separate controls rather than hiding both behind a single duration slider.

The 505-frame budget

Context and added duration must fit together within 505 frames at the source frame rate. At 24 fps, that is approximately 21 seconds shared between the two.

For example, ten seconds of context plus ten seconds of new footage uses 480 frames at 24 fps, within the documented budget. Twenty seconds of context plus ten seconds of extension uses 720 frames and exceeds it. These are arithmetic examples of the limit, not tested generation results.

That creates a practical tradeoff. More source context leaves less room for new footage. A request builder should calculate the combined frame count before submission and tell the user which setting needs to change, rather than offer two apparently independent maximums.

Use an extension request, not a generation preset

The extension path does not accept custom width, height or fps, and it cannot combine the source video with frame images or a separate audio input. Controls including seed, steps, CFG scale and LoRA are also excluded.

Runware's extension example demonstrates a five-second continuation using three seconds of context, a source video and an instruction describing how the action should continue. It is a useful request pattern, not evidence that every shot will preserve motion or identity equally well.

For teams building video editors, the immediate engineering task is to separate extension from ordinary generation. Reusing every setting from a text-to-video form can produce an invalid request, even though both operations use the same model.

What still needs evaluation

The announcement does not provide a controlled comparison of continuation quality or a separate extension-pricing breakdown. I would not estimate a production budget from the headline duration alone without checking the applicable quote and retries.

The useful test is the join: does camera motion continue naturally, does the subject stay consistent, and does the extra footage give the editor something usable? A longer file is only valuable if it saves an edit.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI founders turn technical launches and product updates into clear stories that developers and founders read and share.

Book a 30-minute call.