AI Video FPS: What Frame Rate Settings You Can Actually Change (2026)

TL;DR: Frame rate in AI video is usually fixed, not chosen. Kling, Seedance, Runway, Sora 2, Vidu, Wan and Grok Imagine all generate at a rate the vendor sets internally, most often 24fps, with no fps field anywhere in the request. LTX-2.5 is the documented exception, publishing a real fps enum, and picking a higher one shrinks how long a clip you can generate.

Is frame rate something you actually set in AI video?

For most of the current major vendors, no. Ask for a specific AI video fps and you'll find there's nowhere to put the number. Kling's 3.0 and 3.0 Omni text-to-video request body takes a prompt plus settings for multi-shot, audio, resolution, aspect ratio and duration. No fps field exists in that spec at all, confirmed directly against Kling's own API reference. Seedance's request schema is built around duration and, on its older models, an exact frames count, but never a frame-rate field. Runway's public schema fans out into thirteen model branches across text-to-video and image-to-video, and not one of them accepts a frame-rate parameter. Sora 2's official request schema restricts the seconds field to a closed set, and defines no fps field anywhere in the video resource. Vidu's four generation endpoints (text-to-video, image-to-video, start-end-to-video, reference-to-video) publish no fps field either.

That's five major vendors with zero user-facing frame-rate control between them. The one documented exception among the vendors checked here is LTX-2.5, which is worth understanding in detail because it shows exactly what a real fps parameter looks like when a vendor commits to one.

Which vendors publish an fps field, and what's the documented rate where they don't?

The pattern across five of these six is consistent: no field, no published number, and no way to know the exact rate short of measuring an exported file yourself. Two vendors in this table are the exceptions worth walking through slowly, because each one clears up a real misconception.

Does Kling 3.0 generate video at 60fps?

This claim circulates, and it's wrong as usually stated. Kling's Omni Video Generation API reference does mention both 24 and 60 in the same sentence, but not as a choice between two output rates. The note sits under the constraints for a reference or base video you upload into that endpoint, not under anything you generate. Kling's own documentation states it directly: "The video frame rate is based on 24fps to 60fps" for that uploaded input, and the same sentence's parenthetical clarifies that the frame rate the model actually uses when generating the video is 24. In other words: your reference clip can arrive at anywhere from 24 to 60fps, and Kling accepts it either way, but what comes out of the generator is 24fps regardless of what you fed in.

Nowhere in Kling's 3.0 or 3.0 Omni text-to-video specification does an fps or frame rate field exist for the video you're asking it to create. Frame rate for the output is not published as a setting; the 24fps figure above is the closest thing to a documented number, and it describes a rate the model uses, not a rate you request.

Which vendors let you actually pick a number?

LTX-2.5, from Lightricks, is the clean answer. Both its variants, ltx-2-5-fast and ltx-2-5-pro, accept fps as a request field, and the documentation publishes the exact support matrix rather than leaving you to test it:

Read the table as a genuine tradeoff, not a menu where every option costs the same. On ltx-2-5-fast at 720p or 1080p, staying at 24 or 25fps buys you up to 20 seconds of footage. Ask for 48 or 50fps at those same resolutions and the ceiling drops to 10 seconds. The doubled frame count at the higher rates isn't free; the vendor caps duration to keep render cost and time bounded, and it's stated plainly in the spec rather than discovered by a failed request.

A minimal request against this model looks like:

curl -X POST https://api.ltx.io/v2/text-to-video \
  -H "Authorization: Bearer $LTX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ltx-2-5-fast",
    "prompt": "A lighthouse keeper climbs the stairs, then the beam sweeps out over the water",
    "resolution": "1280x720",
    "duration": 10,
    "fps": 24
  }'

Every other vendor checked for this post (Kling, Seedance, Runway, Sora 2, Vidu, Wan 2.7 and Grok Imagine) has no equivalent field. If you're porting a request body between vendors, dropping an fps key isn't an oversight to fix; it's the correct move everywhere except LTX.

Why does frame rate change how motion feels?

This part isn't vendor-specific; it's how motion perception works regardless of which model rendered the clip. At 24 frames per second, the standard cinema rate for a century of film, each frame captures slightly more motion blur and a slightly larger jump between positions than a higher rate does. That's the texture most people associate with "cinematic" footage — a small amount of judder that reads as intentional rather than broken. Doubling to 48 or 50fps halves the gap between frames, and the same motion looks smoother, sometimes uncannily so on footage that wasn't shot for it — the effect TV engineers nicknamed the soap-opera look decades before AI video existed.

None of this is a vendor claim; it's the same physical relationship that applies to any moving image, generated or captured. It matters here only because LTX is the one vendor in this comparison where you can actually choose which side of that tradeoff you land on, for a given shot.

Frame rate and file size: the arithmetic underneath

Total frame count is duration multiplied by frame rate, and every byte of an uncompressed frame has to go somewhere. BytePlus makes this explicit for Seedance rather than leaving it implicit. Its API documentation states the calculation directly: "Calculation formula: Number of frames = duration × frame rate (24)." A separate note on the same page, describing how a job's returned duration is computed after generation, reads "Calculation: returned duration = actual total frames / 24, rounded down." Both formulas fix the frame rate at 24 as a constant, which is BytePlus's own confirmation that Seedance's internal generation rate isn't 60, isn't 30, and isn't user-adjustable. It's 24, used as the divisor in both directions.

Seedance also exposes a frames integer field, on its older 1.0 pro and 1.0 pro fast models only, that lets you request an exact frame count instead of a whole-second duration — useful for a fractional-second clip, but still built on the same fixed 24fps arithmetic, not a way to change the rate itself.

LTX's duration ceiling in the table above is the same arithmetic showing up as a hard limit instead of a formula: more frames per second at the same resolution means more total frames for the same number of seconds, so the vendor caps the seconds to keep the frame count, and the compute behind it, bounded.

Generation fps versus delivery fps: the distinction that actually matters

This is where most confusion about "does model X support 60fps" comes from — conflating what a model generates with what you end up holding after any post-processing step. Runway's public API is a clean illustration of the two being entirely separate surfaces. None of its thirteen text-to-video and image-to-video model branches (including gen4.5, whose documented parameters are promptText, ratio, duration, seed, contentModeration, outputFormat and proresProfile) accept any frame-rate field. The only place "frame rate" appears anywhere in Runway's entire public schema is a completely different endpoint, /v1/video_upscale, where a model called magnific_video_upscaler_creative accepts a boolean field named fpsBoost, described only as: "Whether to increase the output frame rate."

That's frame interpolation run on a video that already exists, as a separate paid operation, not a choice you make while generating. If a vendor's marketing mentions a higher output frame rate anywhere near an upscaler, an "enhance" feature, or a "smooth motion" toggle, assume it's this kind of delivery-side step rather than a change to how the underlying model renders frames. The generation rate and the file you eventually download are not guaranteed to be the same number, and only LTX's table above tells you both at once without a separate step.

Working with a fixed frame rate

Since a fixed rate is the norm rather than the exception across this comparison, the practical move is planning around it rather than looking for a setting that mostly doesn't exist:

1. Assume 24fps unless a vendor's own docs say otherwise. It's the figure Kling and Seedance both confirm in their own text, and it's the rate every other vendor here leaves undocumented rather than contradicts.
2. Reach for LTX specifically when the fps itself is the requirement — a client asking for footage at a named broadcast or delivery rate, or a shot meant to sit inside footage already cut at 48 or 50. Every other vendor here hands you whatever its internal rate is.
3. Don't port an fps key between vendors. It's a real field on LTX and a rejected or silently ignored one everywhere else in this comparison.
4. Treat a "smoother" or "higher frame rate" marketing claim as a delivery-side feature until proven otherwise, the way Runway's fpsBoost actually works. Ask what stage of the pipeline it touches before assuming it changes generation itself.
5. For duration limits at a given resolution, check our duration parameters by model reference rather than re-deriving them — this post covers fps specifically, that one owns the full duration matrix.

For everything else (the shot's pacing, how much happens per second of runtime, whether a cut reads as fast or slow), that's a prompt-writing question, not a parameter one. Our guide to directing AI video like a filmmaker covers the framing, lens and movement side of that; our breakdown of why AI video sometimes has no motion at all covers the separate failure mode of a technically fine frame rate producing a clip that barely moves.