How To Make Longer AI Videos

Longer AI videos are built by chaining generations, and LTX documents three ways to do it: extend a clip forward, bridge two segments with keyframes, or regenerate one bad region without touching the rest.

The instinct to reach for a single enormous call is the wrong one. Every path past a single generation's runtime runs through the same frame-count rule, and that rule decides which durations are reachable at all.

This post covers the ceiling, the three continuation methods, which surface each one runs on, the arithmetic that governs segment length, and why concatenating clips in an editor produces the seam problems it does.

What you need first

Requirements differ by surface.

The hosted LTX API needs an API key from the developer console at console.ltx.video, passed as a Bearer token in the Authorization header.

The open-source pipelines need Linux, Python 3.12 or newer, CUDA 12.7 or newer with 13 or newer recommended, and an NVIDIA GPU, with 80GB or more of VRAM as the target and distilled variants supported on 32GB using quantization. If that rules you out, the hosted API is the lower-barrier path, referenced in our documentation.

One surface distinction shapes everything below. On the API, text-to-video, image-to-video and audio-to-video run on LTX-2.5, but the continuation endpoints, extend and retake, run on ltx-2-3-pro only. In the open-source pipelines every method runs locally against the checkpoint you load. So a fully LTX-2.5 chain is an open-source workflow; an API chain mixes 2.5 generation with 2.3 continuation.

How long can one run be?

One run's length is set by the surface and the tier, not by a universal number.

On the API, duration is a request field in seconds, but it is a fixed set rather than a free range: ltx-2-5-fast offers 6 through 20 seconds in even steps at 720p and 1080p on 24 or 25fps, and 6, 8 or 10 seconds everywhere else, while ltx-2-5-pro offers 6, 8 or 10 across the board. The ceiling is 20 seconds, not a minute.

In the open-source pipelines there is no tier ceiling. Length is set by --num-frames, bounded by memory and by the constraint below. The useful question is not "how long can one call be" but "how do I compose runs."

The frame-count rule

Frame count must satisfy (F-1) % 8 == 0. The Video VAE encodes pixels [B, 3, F, H, W] into latents [B, 128, F', H/32, W/32], where F' = 1 + (F-1)/8, and the documentation states the constraint explicitly. A request for 30 frames does not round up to 33. It is invalid input.

Valid frame counts include 9, 17, 25, 33, 41, 49, 57, 65, 73, 81, 89, 97 and 121. At 25fps that puts 49 frames at 1.96 seconds and 57 frames at 2.28 seconds. Spatial dimensions follow the same logic one axis over: the encoder compresses by 32 in each dimension, so width and height are chosen in multiples of 32.

Every segment in a chain has to be a valid count on its own, so a target runtime has to decompose into valid counts before you generate anything.

Method 1: extend forward

Extending forward is the most direct method and it exists as a dedicated endpoint, POST /v1/extend, which takes an existing video and a continuation prompt. Note two constraints before you build on it: it runs on ltx-2-3-pro, and it is 1080p only.

bash

curl -X POST https://api.ltx.video/v1/extend \
 -H "Authorization: Bearer API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
   "video_uri": "https://example.com/input-video.mp4",
   "prompt": "continue the motion smoothly",
   "duration": 5,
   "mode": "end",
   "model": "ltx-2-3-pro"
 }' \
 -o extended-video.mp4

Three fields do the work: video_uri is the clip you are continuing, mode says which side to grow (end or start), and duration is the new material's length in seconds, from 2 to 20. Audio is not a flag here — the extension generates audio automatically when the input video has audio. Extend needs an input of at least 73 frames and caps the total at 505 frames including context. The extend capability page covers the feature.

Extend is right when the continuation is a continuation: same shot, same subject, motion carrying on. It is wrong when you need a specific end state, which is what Method 2 handles.

Method 2: bridge with keyframes

Bridging with keyframes solves the problem extend cannot: getting from a known first image to a known last image. KeyframeInterpolationPipeline interpolates between keyframe images, which turns a multi-segment sequence into a series of controlled hand-offs rather than hopeful continuations. This one is open-source only; there is no API endpoint for it.

The pattern is straightforward. Decide the frames where you know what the picture must be, generate or supply those as images, then interpolate each gap as its own segment. Each segment still has to satisfy (F-1) % 8 == 0, so a hand-off every 49 frames and one every 57 frames are both legal while every 50 is not.

ltx-core also documents VideoGeneratedKeyframeSlots, which places extra model-generated frames at interior positions and requires a checkpoint whose transformer config sets use_keyframes_abs_pos_embedding. That is a checkpoint-level requirement, not a flag, so confirm it before designing a workflow around it. The image-to-video page covers how still inputs condition a generation.

Method 3: retake one segment

Retake regenerates a specific time region of an existing video, which makes it the repair tool rather than a lengthening tool. RetakePipeline provides it in the open-source pipelines, and POST /v1/retake provides it on the API, again on ltx-2-3-pro only.

Retake matters for long-form work because of how chains fail. When segment four of six is wrong, rerunning from there forward changes everything downstream, while retaking the bad region leaves the surrounding material intact. In the open-source pipeline the source video's frame count must satisfy the 8k+1 format and its resolution be a multiple of 32. Regenerating specific video segments covers the workflow, and the video editing page covers the wider set.

How do you plan segments?

Segment planning starts from the target runtime and works backward through valid frame counts. A worked example at 25fps:

1. Set the target. Say 30 seconds of finished runtime.
2. Pick a segment length in valid frames. 121 frames is 4.84 seconds at 25fps and is the count the repository quick start uses.
3. Divide. 30 seconds needs seven segments at 121 frames, landing at 33.9 seconds. Overshoot and trim in the edit rather than undershoot and regenerate.
4. Decide the hand-offs. Six joins for seven segments, each either an extend continuation or a keyframe bridge, chosen per join rather than per project.
5. Reserve retake capacity. Assume at least one segment needs regenerating.

The join type is the decision that matters most. Use extend where the shot continues and a keyframe bridge where the picture has to arrive somewhere specific.

If the sequence needs actual cuts rather than continuous motion, LTX-2.5's native multishot generates multiple coherent shots inside a single generation, holding character, environment, lighting and voice across the cuts. For a cut-driven sequence that is often a better answer than chaining at all, and it stays on 2.5 rather than dropping to 2.3 for the joins.

Why do stitched clips fail?

Stitched clips fail at the joins, and each failure mode points at a different cause. Concatenating independently generated clips in an editor produces the most visible seams, because nothing in the second generation knew about the first.

• A visible cut at the join. The segments were generated independently. This is what extend and keyframe bridging prevent.
• Drifting appearance across segments. Subject or colour identity was never pinned. Supply a keyframe image at the join rather than re-describing the subject in prompt text.
• An invalid segment that never rendered. The frame count failed (F-1) % 8 == 0. Recheck every segment length, not just the first.
• A join that lands mid-motion. Put joins at rest points where you can, so the bridge has less to reconcile.

Keeping audio continuous

Audio is generated jointly with video in LTX-2.5, not added afterward, which changes how segment boundaries behave. ltx-core documents separate audio and video VAEs, with audio latents decoded to a mel spectrogram and the spectrogram converted by a HiFi-GAN-based vocoder to a 24 kHz stereo waveform. Because both modalities are produced together, a segment boundary is an audio boundary too.

If the soundtrack has to run continuously across a chain, generating audio per segment and cross-fading in post is more predictable than hoping several independent generations agree. Where audio drives the picture instead, A2VidPipelineTwoStage generates video conditioned on an input audio file, which is covered on the audio and video page.

What each segment costs

Cost scales linearly with segments on the API, because pricing is per second of video generated, by SKU, combining endpoint, model, resolution and output type. The live schedule lists text-to-video-ltx-2-5-fast-1920X1080 at 13 cents per second, available unauthenticated at GET https://api.ltx.video/pricing, so read the rate for your exact SKU there rather than from a guide. Bear in mind the continuation endpoints price against 2.3, not 2.5.

One billing behaviour matters for chained work: prepaid organizations reserve credits before generation, commit on success and release on failure, so a failed segment is not billed. An insufficient balance returns insufficient_funds_error. LTX API pricing explained covers the model in full.

Local runs have no per-second charge. The cost there is wall-clock time and VRAM, which is why the distilled path and its 8 predefined sigmas matter more for chained work than for single clips.

Summary

Longer AI videos are composed from multiple generations rather than requested in one call. LTX documents three continuation methods: extend grows a clip forward with a continuation prompt and a mode, KeyframeInterpolationPipeline bridges between known keyframe images, and retake regenerates one bad time region without disturbing the rest.

Surface matters. In the open-source pipelines all three run against LTX-2.5. On the API, extend and retake run on ltx-2-3-pro only, while generation runs on 2.5, so a fully-2.5 chain is a local workflow.

Every segment must satisfy (F-1) % 8 == 0, so valid counts include 49 frames at 1.96 seconds and 121 at 4.84 seconds at 25fps. API cost scales linearly at per-second SKU rates, with a reserve-then-charge flow that does not bill failed segments. Audio is generated jointly with video, so every segment boundary is an audio boundary.

Plan the joins before you generate the first segment, and if the sequence is really a series of cuts, try native multishot before you chain anything.