Runway Enhance Frame Rate Ships on the Dev API: 24 to 120 fps, NTSC Included

Runway put a new frame interpolation model on its developer API on September 17, 2026, and the detail that actually matters is not the top of the range — it is the fractional rates. Runway Enhance Frame Rate retimes footage you already have to a target of 24, 25, 30, 48, 50, 60 or 120 fps, and it also accepts the three rates that broadcast and cinema genuinely deliver on: 23.98, 29.97 and 59.94. Runway's own developer changelog documents the model as enhance_frame_rate, invoked through the same POST /v1/video_upscale endpoint the company already uses for its creative upscaler, capped at 300 seconds of input per job and billed at 1 credit per 2 seconds.

That billing line is the second surprise. Frame interpolation is usually priced by output — Runway's own Magnific Video Upscaler on that same endpoint charges 0.7 credits per output frame at 720p/1K — which means a 24 fps to 120 fps conversion costs five times what a 24 to 25 conversion costs. enhance_frame_rate is charged per second of input. A 5× frame multiplication and a 1.05× one cost exactly the same. If your job is delivering one piece of footage at several frame rates, that single line in the pricing table inverts the usual arithmetic.

The timing is also pointed. Runway's standalone Frame Interpolation tool sits on the company's official deprecated-tools list, with the Animate Keyframes app named as its replacement. Enhance Frame Rate is not a revival of that web tool — it is frame interpolation rebuilt as an API model, aimed at pipelines rather than at someone clicking through a timeline.

What Enhance Frame Rate actually does

This is a retiming model, not a generative one. There is no prompt, no image, no reference clip. You hand it a video that already exists — anything from a camera, an edit, or another Runway model — and it synthesises the intermediate frames needed to land on the target rate. Runway's announcement on its own X account frames it the same way: "converts any footage to the specs you need."

Mechanically it is an asynchronous task on the video upscale endpoint. You POST a video URI, set model: "enhance_frame_rate", get a task id back, and poll for the result. Because it shares an endpoint with Runway's upscaler, a pipeline that already talks to /v1/video_upscale needs a parameter change rather than a new integration.

Runway's changelog lists the following as the current, vendor-stated specification. None of it has been independently verified — there is no third-party benchmark of this model, and it is a day old at the time of writing.

• Target rates — 24, 25, 30, 48, 50, 60 and 120 fps, plus 23.98, 29.97 and 59.94 fps (written in the API as 23_98, 29_97 and 59_94)

• Input limit — 300 seconds per job

• Price — 1 credit per 2 seconds of input; Runway API credits are $0.01 each

• Access — POST /v1/video_upscale with model: "enhance_frame_rate", on Runway Dev

• Prior art at Runway — a frame_interpolation_v1 task type existed under the 2024-11-06 API version; the standalone web Frame Interpolation tool is deprecated

• Independent evaluation — none published

The frame-rate ladder, and why 23.98 is the real headline

Every consumer interpolation tool offers integer rates. The interesting column here is the fractional one, because fractional rates are what the delivery specs actually say:

• 23.98 (23.976) — the NTSC-film rate. Nearly every cinema and streaming master, and the rate DVD and Blu-ray were authored against.

• 24 — true film rate, still used for DCP and many festival deliverables.

• 25 — PAL and EBU territories: the UK, most of Europe, Australia, large parts of Asia and Africa.

• 29.97 — NTSC broadcast, the fractional sibling of 30.

• 30 — integer rate for screen capture, web and game footage.

• 48 — high-frame-rate cinema (the rate the Hobbit films were shot and projected at).

• 50 — PAL high frame rate, exactly 2× 25.

• 59.94 — NTSC high frame rate, the 60 Hz broadcast delivery rate in the US and Japan.

• 60 — integer 60 Hz, the common target for smooth web playback.

• 120 — slow motion, and high-refresh delivery.

The gap between 24 and 23.976 looks trivial and is not. Over one hour of runtime the two drift apart by roughly 3.6 seconds. Feed a 24.000 master into a 23.98 delivery chain and you get audio sync drift and cadence errors that broadcast QC will fail — which is why post houses historically ran a separate conform step to resample rates, or refused the job. A tool that emits the fractional rate directly removes a stage from that chain. That is a much narrower, much more boring claim than "120 fps", and for anyone delivering to a broadcaster it is the reason to care.

The 48 and 120 targets are the ones to be sceptical of in practice. Interpolating 24 fps material up to 120 fps means inventing four frames for every real one, and on fast motion, occlusion, or heavy motion blur, interpolators of every kind produce ghosting and warping. Runway publishes no artefact analysis, no comparison against any other interpolator, and no per-shot quality guidance — so the honest position is that the spec supports 120, and what 120 looks like on your footage is untested.

What it costs, worked through

The arithmetic is unusually clean because the unit is input seconds. At 1 credit per 2 seconds, and $0.01 per credit on Runway's developer API (prepaid, $10 minimum for 1,000 credits):

• A 10-second clip, at any target rate — 5 credits, about $0.05

• A 30-second clip — 15 credits, about $0.15

• A 60-second clip — 30 credits, about $0.30

• A 5-minute clip, the 300-second ceiling — 150 credits, about $1.50

• A 90-second clip, 24 → 25 fps — 45 credits, about $0.45

• The same 90-second clip, 24 → 120 fps — 45 credits, about $0.45

Those last two lines are the whole pricing argument. On a per-output-frame model, the second job would be a 5× frame count and therefore roughly 5× the bill. Here it is free.

The comparison against the neighbour on the same endpoint makes the point concrete. Magnific Video Upscaler bills per output frame — 0.7 credits at 720p/1K, 0.9 at 2K, 1.2 at 4K, with a one-credit floor per generation. A 10-second, 30 fps clip is 300 output frames, so the 720p/1K rate lands at 210 credits, or about $2.10. The identical clip through enhance_frame_rate is 5 credits, about $0.05. If you want a higher frame rate and not a bigger picture, reaching for the upscaler costs roughly forty times more. Note also that enabling the upscaler's optional fps boost changes the output frame count and therefore raises that bill further — Runway's pricing docs say so explicitly.

One cost caveat worth flagging: Runway's developer pricing page is the authority here, not this article, and the credit price has been reported as under review toward custom pricing since August 2026. Check the portal before you budget a large batch.

The 300-second cap, and how to work around it

Every job is limited to 300 seconds of input. That is generous for a shot and short for a reel, so anything longer has to be segmented — and how you segment matters more than the cap itself.

Cut at scene boundaries, not on a fixed clock. Interpolators infer motion between adjacent frames; at a hard cut, the last frame of shot A and the first frame of shot B have no motion relationship at all, and a model that does not detect the cut will happily invent a morph between them. Runway's changelog does not document automatic scene detection for this model, so the safe assumption is that there isn't any. Chunk at cuts, interpolate each chunk, reassemble on a timeline at the new rate.

That advice is not specific to Runway — it is the standard caveat on AI retiming everywhere. A 2025 SMPTE paper on AI-assisted post-production, describing a TensorRT-optimised interpolation pipeline for conversions like 23.976 → 25 and 29.97 → 23.976, makes the same point: frame-converted content needs frame breaks at scene cuts, and QC afterwards, or the model hallucinates across the splice. Expect the first pass to need manual frame replacement around difficult transitions.

Where it sits against the alternatives

Frame interpolation has been a solved-ish problem for a while, in two forms that both look different from this one.

• Desktop suites — Topaz Video AI's Apollo and Chronos models are the reference point for quality-focused retiming. A perpetual licence, your own GPU, no per-second meter, and a tuning pass that rewards someone who knows what they are looking at.

• Open-source interpolators — RIFE and similar models, self-hosted, effectively free at the margin once you own the hardware, and the basis of most of the custom pipelines post houses built themselves.

• Runway Enhance Frame Rate — no local compute, an API call, per-input-second billing, and the fractional NTSC rates that the other two have historically left you to conform around by hand.

The trade is legible. For a one-off shot on a workstation you already own, a local interpolator will be cheaper and gives you knobs Runway does not expose. For footage that arrives inside an automated pipeline, or a deliverable matrix where the same clip has to come out at 23.98 for one territory and 25 for another, an API that returns the fractional rate directly removes a conform step — and the per-input-second price means the multi-rate output costs nothing extra.

The routing layer around it

Retiming is one stage in a pipeline that has a language-model step somewhere near it. The shot list and the conform notes, the subtitle and caption pass that has to be re-timed to the new frame rate, the per-territory delivery metadata, the QC log — that is text work, and it is the part of a video pipeline nobody budgets for.

That layer runs on one key across the 200 models in the OrcaRouter catalogue, with provider list prices passed through at 0% markup and automatic failover between providers, so a newer or cheaper model can be tried on live traffic without betting a production path on it. To be precise about scope: Runway Enhance Frame Rate is a Runway Dev API model, called on Runway's own endpoint, and OrcaRouter does not serve it. What we cover is everything around it.

What is not known yet

Almost nothing about quality. This model is roughly a day old at the time of writing, and everything above about its behaviour comes from Runway's own changelog and announcement. Specifically unverified:

• Artefact behaviour on fast motion, occlusion, motion blur and low-bitrate sources — no published tests by anyone

• Whether it detects scene cuts automatically, or blends across them

• Whether audio is carried through, resampled, or dropped when the frame rate changes

• How it compares on quality to RIFE, Apollo or Chronos — no head-to-head exists

• Whether the per-input-second price holds as target rate rises, or gets re-tiered later

Treat the 120 fps and 48 fps targets as claims until you have run your own footage through them, and check the cut handling on the first clip you send.

Who should move now

Move now if you deliver to broadcast or multi-territory specs and currently pay for a conform step, if your footage already flows through an automated pipeline that can absorb one more API call, or if you want slow motion from a camera that never shot high speed and you would rather not run a GPU.

Wait if you need more than five minutes in a single job and cannot segment at cuts, if you need the resolution raised as well — that is the upscaler, at per-frame prices — or if you already own a desktop interpolator and this is a one-off shot. And wait if quality is the deciding factor rather than convenience: nobody outside Runway has published a number, and the first independent comparison is the thing worth waiting for.

The pattern to watch is whether Runway keeps extending this endpoint model by model. It already carries a creative upscaler and now a retimer, both on POST /v1/video_upscale, both priced on entirely different units. For anyone building delivery pipelines, the unit — input seconds rather than output frames — is the part worth designing around.