Motion Strength in AI Video: What's Left of the Parameter (2026)

TL;DR: A dedicated motion-strength or motion-amount parameter mostly doesn't exist on current major AI video models. It started with Stable Video Diffusion's motion_bucket_id in 2023. Today, Vidu is the only current vendor checked here that still lists a field like it, and its own docs say the field is inert on Vidu's current models. Everyone else has moved motion control into the prompt itself.

Is there still a motion strength parameter in AI video?

Rarely, and it's worth being precise about what "rarely" means here. Across the vendors checked for this post (Kling 3.0 and 3.0 Omni, Runway's thirteen generation model branches, Seedance 2.5 and the 2.0 series, Vidu's Q3 family, Wan 2.7 and Grok Imagine Video 1.5), exactly one publishes a field whose name and description match "how much does this move": Vidu's movement_amplitude. And Vidu's own documentation states that on its current flagship models, the field doesn't do anything.

That's the honest state of "motion strength" in AI video in September 2026: a concept with a real technical history, one vendor still listing a vestigial field for it, and everyone else handling it through the words you write rather than a number you set.

Where did "motion strength" come from?

Stable Video Diffusion, Stability AI's 2023 image-to-video model, is the direct ancestor of the idea, and it's still documented today in Hugging Face's diffusers library. Its pipeline accepts what the documentation calls micro-conditioning parameters alongside the input image, and two of them are explicitly about motion amount. The first is fps, described simply as the frames per second of the generated video. The second is the one that matters here: "motion_bucket_id: the motion bucket id to use for the generated video. This can be used to control the motion of the generated video. Increasing the motion bucket id increases the motion of the generated video."

A third parameter, noise_aug_strength, has the same effect through a different mechanism. It's documented as "the amount of noise added to the conditioning image. The higher the values the less the video resembles the conditioning image. Increasing this value also increases the motion of the generated video." Two knobs, two different technical routes, one shared outcome: more of either number produces a video that moves more.

That's a genuine motion-strength parameter, by name and by documented behavior. It's also from a research pipeline you run yourself through diffusers, or through the small number of hosted wrappers still built on it, not from any of the mainstream commercial video vendors people mean when they ask "does my model have a motion strength setting" in 2026.

Vidu's movement_amplitude: the field that's still there, and mostly isn't

Vidu documents movement_amplitude on all four of its main generation endpoints (text-to-video, image-to-video, start-end-to-video and reference-to-video) as an optional string, default auto, accepting auto, small, medium or large.

Two things about it are worth knowing before you set it. First, Vidu's own docs can't agree on what it measures. The request-body description on its text-to-video page reads: "The movement amplitude of objects in the frame" (subject motion). The response table on that same page describes the same field as: "The camera movement amplitude parameter used for this call" (camera motion). Those are different things, and Vidu's documentation states both, about the identical field, on the identical page.

Second, and more important if you're actually building a request: Vidu's current flagship models don't honor it. The text-to-video and start-end-to-video pages both state, word for word: "This parameter does not take effect when using the q2 & q3 model". The image-to-video page says the same thing differently: "Note: Modifying this parameter is ineffective for q2, q3 models". Two separate phrasings of the identical rule, on two separate pages, which is its own small warning about trusting one vendor page over another for the exact wording of a limitation.

So if you inherited a request body with movement_amplitude: "large" set against a Q3 call and the clip still looks calm, that setting isn't your problem. Q2 and Q3 are Vidu's current models; the value is accepted, stored, and ignored.

The one real numeric "intensity" dial left, and it's not what it sounds like

Runway is the closest thing to a counter-example in this comparison, and it's worth being exact about why it doesn't actually count. None of Runway's thirteen text-to-video and image-to-video model branches accept a motion field. Its gen4.5 branch takes promptText, ratio, duration, seed, contentModeration, outputFormat and proresProfile. Nothing there adjusts how much anything moves. Two other branches describe the prompt field itself as: "A string up to 2500 characters (measured in UTF-16 code units) describing motion or changes in the output video." Motion is prose there, same as everywhere else in this comparison.

But Runway does publish a genuine integer intensity field, expressionIntensity, documented in full as: "An integer between 1 and 5 (inclusive). A larger value increases the intensity of the character's expression." It sits on a completely different endpoint: Act-Two, Runway's character-performance-transfer feature, alongside a boolean bodyControl field that, when enabled, means "non-facial movements and gestures will be applied to the character in addition to facial expressions."

That's a real, working, numeric motion-adjacent dial. It's also scoped to transferring a performer's face and body movements onto a character from a reference performance, not to making a text-to-video or image-to-video subject move more or less in general. If you're searching for "motion strength" hoping to make a generated dancer more energetic from a text prompt alone, expressionIntensity is the wrong feature; it only exists once you're already driving a character from a recorded performance.

What do Seedance and Kling offer instead?

Seedance's closest field is camera_fixed, a boolean defaulting to false, and it's a lock, not a dial. BytePlus's own documentation describes what happens when it's set to true: "Fix the camera. ModelArk will append the fixed camera instruction to the user's prompt, but the actual result is not guaranteed." That's binary: the camera is either pinned or it isn't, and even then the vendor won't promise the result. It's also scoped to Seedance's 1.5 pro, 1.0 pro and 1.0 pro fast models specifically, not the current 2.5 or 2.0 series.

Kling's motion-related feature is named in a way that invites exactly the search this post is answering: Motion Control. It isn't a strength dial. It's a motion-transfer feature: it drives a character's movement and facial expression from a reference video or Kling's own motion library, matched to one primary subject in the shot. Its request body accepts character_orientation, audio and resolution; there's no strength, amount or intensity field anywhere in the specification. You feed it a performance to copy, not a number to turn up.

So how do you actually control how much a video moves?

Through the prompt, on every vendor checked here except Vidu's now-inert field. Grok Imagine is the cleanest illustration of a vendor building this deliberately rather than as an absence. xAI's own documentation states plainly: "The API supports configurable duration, aspect ratio, and resolution" (three fields, no fourth for motion), and one of its own example prompts writes the pacing directly into the sentence: "A hummingbird hovering near a red flower in slow motion." The phrase "slow motion" is doing the entire job that a motion_bucket_id-style field would have done in 2023.

That pattern generalizes past Grok Imagine. Where there's no parameter, motion amount lives entirely in word choice, verb selection and pacing language:

Subtle:    A leaf drifts slowly across a still pond, barely disturbing the water.
Moderate:  A cyclist pedals at a steady pace along a tree-lined path, leaves
           rustling as she passes.
Energetic: A skateboarder launches off a ramp, spinning hard through the air
           before landing and rolling out at speed.

None of those three prompts touch a request-body field. All three produce visibly different amounts of movement, because "drifts slowly," "steady pace" and "launches... spinning hard... at speed" are doing exactly what a strength parameter would have done, just in language instead of a number. Our seven-part video prompt structure guide covers where pacing language fits inside a full prompt if you want the fuller framework rather than three isolated examples.

Why did the prompt swallow the parameter?

It's a fair question, given that a numeric dial is easier to document and easier to search for than a paragraph of adjectives. The likely answer is that a general motion-amount field only works if "large" means the same thing on every subject, every shot length and every camera setup, and in practice it can't. A large movement_amplitude value on a static product shot and on a running crowd scene isn't remotely the same instruction, and the field itself has no way to know what's actually in frame. Prose can, because it already carries the subject, the verb and the pacing in one place, read together by the same model that has to render all three consistently.

That also explains why the one surviving numeric dial in this comparison, Runway's expressionIntensity, actually works. It's scoped to a single, narrow, well-defined target: how hard one performer's face moves, on a feature where the input is already a specific reference performance to match. A general-purpose "motion amount" field has no equivalent narrow target to aim at, which may be exactly why vendor after vendor keeps retiring it in favor of the same words you'd already use to direct a person on set.

This is also, quietly, an argument for treating your prompt as the durable interface rather than any one vendor's parameter list. A well-written motion sentence ports to a new model the day you switch; a movement_amplitude value does not, and neither will whatever field replaces it next.

If your video isn't moving at all, that's a different question

Everything above assumes you're choosing how much to dial motion up or down when a parameter for it barely exists. If your clip is producing close to zero motion regardless of what you write, that's a troubleshooting problem, not a missing-parameter one, and it usually traces back to the prompt describing a scene instead of an action, or a duration too short for the intended motion to complete. Our guide to AI video with no motion sorts that failure into the causes a rewrite actually fixes versus the ones it doesn't.

Two other adjacent topics worth knowing you don't need here: if what you actually want is camera movement vocabulary (dolly, pan, orbit and the rest), that's a naming problem the prompt solves directly, covered in our camera movement vocabulary reference. And if the "not enough happens" feeling is really about the clip ending before the action completes, that's a duration ceiling, not a motion-amount one; our duration parameters by model reference has the full matrix per vendor.

The honest summary

"Motion strength" was a real, named parameter once, on the model that popularized image-to-video generation in 2023. In September 2026, across the current flagship models from Kling, Runway, Seedance, Vidu, Wan and Grok Imagine, it survives as one documented field that no longer functions on its vendor's own current models, one narrowly-scoped performance-transfer setting that isn't a general motion dial, and otherwise nothing at all. What replaced it isn't a new parameter under a new name — it's the prompt itself, doing the same job it always did for anything these APIs don't expose a field for.