Pacing and Timing in Video Prompts

TL;DR: Duration is a real, documented parameter on every video model checked. The number and length of shots inside that duration has real syntax on exactly one vendor, Kling. Slow motion, speed ramps and "beats per second" are not parameters anywhere: they are prompt language, and Google and BytePlus both document them as exactly that.

Prompt Architects writes the prompt, not the video. Nothing on this page renders a clip; it is a working reference for the field you set and the words you choose when pacing is the thing you are trying to control.

"Pacing" gets used for at least three different things when people ask how to prompt for it: the total length of the clip, how many distinct beats happen inside that length, and how fast any one action inside a beat appears to move. Only the first two have anything resembling a documented parameter on the models checked for this page. The third, everything from a slow-motion close-up to a whip-fast speed ramp, has no dedicated field on any vendor's own specification, Veo, Kling, Runway, Luma, Seedance and Vidu included. It is written, not set.

That split matters because it changes what a bad result tells you. If your clip runs the wrong length, you sent the wrong duration value, and the fix is in the request body. If it feels rushed or slack at the right length, the fix is in the words, and no amount of parameter-hunting in a vendor's docs will find a dial that was never built.

What Part of Pacing Is Actually a Parameter?

Total clip length is a parameter everywhere in this survey, and it is the one part of pacing a bad guess breaks the request over, not just the feel of the result. Google's Gemini API documents Veo 3.1's durationSeconds as "4", "6" or "8", and adds that it must be "8" "when using extension, reference images or with 1080p and 4k resolutions" (ai.google.dev/gemini-api/docs/veo, read September 3, 2026). Kling 3.0 Omni's settings.duration takes any integer from 3 to 15. Runway's gen4.5 branch requires an integer duration from 2 to 10 seconds. None of these read a length out of your prose; the field is the whole story, and post 234 covers the full duration table across eleven surfaces, with every resolution and frame-rate coupling that breaks it, if you need more than the headline number.

Frame rate is a parameter too, on the handful of vendors that publish one, but it is not a pacing control in the sense most people mean. Veo 3.1 documents 24fps across every current variant, and Kling's own Omni Video Generation reference says "The video frame rate is based on 24fps to 60fps (the frame rate for generating videos is 24fps)" (kling.ai/document-api/api/video/3-0-omni/video-omni.md, read September 3, 2026), a clause about accepted reference-video inputs, not an output setting you can raise for a faster feel. Treat 24 as the documented output figure on both.

Can You Set the Number of Beats Inside One Clip?

On one vendor, yes, with real syntax. Kling 3.0's request-body notes describe a multi-shot prompt format directly: "Multi-shot video format: "shot n, m, words; shot n, m, words;" (separated by standard semicolons), where:" the shot number "n: shot sequence number (1–6 shots supported)" and the per-shot length "m: shot duration in seconds (each shot ≥ 1s; sum of all shot durations must equal the total video duration)" (kling.ai/document-api/api/video/3-0-omni/text-to-video.md, read September 3, 2026). That is the closest thing to a documented "beats per second" control anywhere in this survey: hold settings.duration fixed and raise the shot count, and you have packed more distinct beats into the same total time, entirely through prompt syntax rather than a numeric field.

Nobody else in this survey exposes anything comparable. Wan 2.7 follows a looser version of the same idea entirely in prose: prompts embed a timestamp label per shot directly in the text, a convention post 234 documents in full, with nothing in the request body enforcing the split; only the total duration field is real. Seedance's own prompt guide gets close from the transition side rather than the shot-count side: "For transition shots, clearly specify both the trigger point and the transition method", with a worked example reading "At the 5-second mark, the camera quickly transitions leftward using a left wipe combined with a natural dissolve" (BytePlus ModelArk doc 2607689, read September 3, 2026). That is timing placed inside a single continuous shot, useful for the transition work post 322 covers in full, not a second shot with its own field.

Does Any Vendor Document a Slow-Motion or Speed-Ramp Parameter?

No. This survey checked Veo, Kling, Runway, Luma, Seedance and Vidu for anything resembling a speed dial, a time-remap field or a playback-rate setting, and none exist. What both Google and BytePlus publish instead is a list of words to use.

Google's Gemini Enterprise Agent Platform prompt guide has a section called Temporal elements, and inside it, a heading literally named Pacing: "Pacing: "slow-motion", "fast-paced action", "time-lapse"" sits beside "Rhythm: "pulsating light", "rhythmic movement"" (docs.cloud.google.com/gemini-enterprise-agent-platform/models/video/video-gen-prompt-guide, read September 3, 2026). The same page's Cinematic terms section lists edit-style vocabulary for a single generation, "match cut", "jump cut", "establishing shot sequence", "montage", "split diopter effect", and its worked jump-cut example describes outfit changes with "sharp jump cuts between each outfit change", aiming for "creating a fast-paced, rhythmic jump cut effect." Every one of those is a phrase inside the prompt string. None is a field name.

BytePlus's own Seedance prompt guide reaches for the same kind of vocabulary from the camera-technique side. It says cinematography terms can be written directly into the prompt, among them one-shot/long take and Hitchcock zoom/dolly zoom, closing the list with "aerial perspective, FPV, bullet time, handheld shot, and speed ramp" (doc 2607689, read September 3, 2026). Speed ramp, named exactly like that, sits in the same bucket as bullet time and handheld shot: something you describe, not something you configure.

How Do You Actually Write a Slow-Motion Prompt?

The word "slow-motion" alone does some of the work, but it reads stronger paired with a specific physical detail the model can hold onto: the exact thing that slows, and what a slowed version of it looks like.

A single drop of water hitting the surface of a still pond, in slow-motion. The impact
creates a perfect circular crown of droplets that hang visibly in the air before falling
back, ripples spreading outward in concentric rings. Soft overhead light, macro lens,
static camera, no other motion in frame.

A sprinter's foot striking the track at the moment of a starting gun, in slow-motion.
Dust kicks up from the track surface in a visible cloud, the shoelace and shorts fabric
rippling from the impact. Shallow depth of field, side-on tracking shot matching the
runner's speed exactly, stadium lights soft in the background.

A paper lantern catching fire from a dropped match, in slow-motion. Flame spreads along
the paper's edge in a visible creeping line, embers lifting and drifting upward as the
structure begins to collapse inward. Dark background, warm firelight as the only light
source, static camera.

The pattern across all three: name the moment worth slowing, then describe what a slowed version of that specific motion looks like, rather than leaving "slow-motion" to carry the whole sentence alone.

How Do You Write a Speed-Ramp Prompt?

A speed ramp needs the opposite kind of specificity: where the change happens and what it changes from and to, since nothing in the API marks a midpoint.

A cyclist pedaling down a quiet street, beginning at a normal walking pace. Partway
through the shot, the action speed-ramps into a blur of motion, the background streaking
into motion trails as the cyclist accelerates hard, then settles back to a normal pace for
the final beat as they coast to a stop. Handheld camera, natural daylight.

A chef's knife chopping vegetables on a cutting board, cutting at a slow, deliberate pace
for the opening beat. The motion speed-ramps into a rapid, blurred chopping rhythm at the
midpoint, then eases back to a normal pace as the last few cuts land cleanly. Overhead
shot, warm kitchen light, shallow depth of field.

Both examples do the same three-part job: establish a baseline speed, name the ramp and where it happens, then land back at a normal pace so the model has a clear "after" state rather than an open-ended acceleration. Google's own cinematic-terms vocabulary, "match cut", "jump cut" and "montage", sits in the same family for anyone building an edit-style beat rather than a literal speed change inside one continuous shot.

Does Frame Rate Control How Fast Things Look?

No, and this is the confusion most likely to send someone down a dead end. Frame rate is how many frames are captured per second of the output video; both Veo 3.1 and Kling 3.0 publish 24fps, and neither vendor's frame-rate field changes the speed of the action inside the clip. Post 299 covers the closely related question of why a clip might have too little motion at all, which is a different failure than pacing feeling wrong at the right amount of motion, and both trace back to the same root cause: video models read motion and speed out of the words, not out of a numeric setting most people assume exists.

LTX is the one partial exception on frame rate itself, exposing 24, 25, 48 and 50 fps as a real choice, though the higher rates cut the available duration rather than changing the perceived speed of the subject; post 234 documents that coupling in full. A higher frame rate produces a smoother, not faster, result. Speed remains a prompt problem in every case checked.

A Few Full Prompts That Combine Duration, Shots and Pacing Language

These stack the two real parameters, duration and, on Kling, shot count, with the pacing vocabulary from the sections above.

Kling 3.0 Omni, settings.duration = 15, settings.multi_shot = true

shot 1, 4, wide shot of a runner at the starting line, tense and still, holding position;
shot 2, 3, close on the starting gun firing, sharp cut to motion; shot 3, 8, in slow-motion,
the runner's foot striking the track, dust kicking up in a visible cloud, fabric rippling
from the impact, camera tracking alongside at matched speed

Veo 3.1, durationSeconds = "8", resolution = "1080p"

A barista pulling an espresso shot, beginning at a normal working pace. Partway through
the pour, the action speed-ramps into a blurred, rapid motion as the crema forms, then
settles back to a normal pace as the cup is set down on the counter. Warm cafe lighting,
handheld camera, natural ambient sound.

Neither prompt asks the API to do anything the field names above don't already document: the shot math in the first sums to 15, matching settings.duration, and the second stays inside Veo's 8-second ceiling for a 1080p request. The pacing itself, the slow-motion foot strike and the speed-ramped pour, is carried entirely by the sentence.

Which of These Numbers Will Go Stale First?

The Sora row, on a short clock. OpenAI has scheduled the Sora API, sora-2 and sora-2-pro included, for shutdown on September 24, 2026, per its own deprecation notice, about three weeks from this page's publish date. Any pacing habit built around Sora's shot or duration behaviour needs a home on another model before then; post 141 covers the shutdown and where to move and post 192 walks the migration itself.

Veo 3.1's status is the second thing worth watching. Google's Gemini API page marks veo-3.1-generate-preview as Preview, so its durationSeconds coupling could still change before it reaches general availability on that surface. Kling's multi-shot syntax is the most stable of the parameters covered here: it is documented in the same API reference as the core request body, not a separate guide page, which tends to mean it moves at the same pace as the endpoint itself rather than drifting ahead of it.

If you take one thing from this page, take the split, not the vocabulary lists. Duration and, on Kling, shot count are settings you send in a request body and get wrong in a way the API will tell you about. Slow motion, speed ramps and everything people mean by "pacing" past those two are sentences you write and get wrong in a way only the rendered clip will tell you about. Treat them differently, and stop looking for a field that was never built. If you need short, purpose-built clips to practise this on, the B-roll prompt library in the sibling post is a reasonable place to start, since establishing and cutaway shots are short enough to iterate on quickly.