Guide
flux-3-max Keyframes-to-Video Prompt Recipes You Can Copy and Paste
A developer's guide to structuring keyframe descriptions and motion phrasing for predictable clips
What the keyframes-to-video workflow expects from your prompt
Before you write a single word of prompt, it helps to be precise about the division of labor in a keyframes-to-video workflow.
You supply two or more still keyframes. They are anchors: they define what exists, where it sits in the frame, and how the scene looks at specific moments. The model interpolates between them. Your text prompt is the motion brief: it tells the model how to get from one anchor to the next — what moves, in which direction, at roughly what energy, and with what camera behavior.
That split has a practical consequence: the prompt does not need to redescribe the whole world. Anything clearly visible in the keyframes is already established. The prompt should spend its words on the things the stills cannot express — motion, pacing, camera intent, and any change of state between the anchors (a door opening, a subject turning, light shifting).
A useful mental model: if two keyframes were handed to a human editor with no instructions, they would ask "how do we get from A to B?" Your prompt is the answer to that question. Everything else — color grading, wardrobe details, set design — is better solved by improving the keyframes than by stuffing adjectives into the text.
Keep that framing in mind for the rest of this guide. Every recipe below is structured around the same idea: keyframes anchor, text directs motion.
Anatomy of a keyframe description
Consistent output starts with consistent input structure. Describe each keyframe in a fixed order so that when something drifts, you know exactly which line to inspect.
Use this four-part order for every keyframe:
1. Subject
Who or what is the focus, and in what state. Be specific about count and posture: "a single cyclist, upright, hands on the bars" beats "a person on a bike."
2. Scene and setting
Where the subject is and the minimal context needed to place them: "on a wet asphalt street, low buildings behind." One clause is usually enough.
3. Framing and camera position
Shot size and angle for that keyframe: "medium shot, eye level, subject slightly left of center." This is the node the video will interpolate toward, so it matters.
4. Light and atmosphere
Time of day, direction of light, weather, haze. "Late afternoon backlight, soft haze" is more actionable than a list of five mood adjectives.
A few rules of thumb:
- Keep the same order across all keyframes. If keyframe A starts with subject and keyframe B starts with lighting, editing becomes guesswork.
- Describe only what is visible. Speculative backstory adds noise the model cannot use.
- One sentence per part. If a part needs two sentences, it is probably two ideas competing for control.
- Reuse vocabulary between keyframes. If it is a "medium shot" in A, call it a "medium shot" in B, not "mid-range framing."
This structure is boring on purpose. Boring structure is what makes the interesting part — the motion — debuggable.
Phrasing camera movement and motion
Camera and motion phrasing is where most prompts go wrong, usually by trying to do too much in one sentence.
The rule: short, single-intent, its own clause.
Good motion phrasing names one movement and lets it finish:
- "The camera pushes in slowly."
- "The camera tracks right, keeping the subject centered."
- "A gentle handheld drift, no zoom."
- "The subject turns toward the camera and stops."
Bad motion phrasing stacks intents and forces the model to compromise:
- "The camera slowly pushes in while panning left and slightly tilting up as the subject walks forward and turns, with a subtle zoom."
That sentence contains five directives. No single clip can honor all of them cleanly, so you get a muddy average. Split the work: pick the one movement that carries the shot, and let the keyframes handle the rest.
A few practical conventions that pay off:
- Separate camera from subject. "The camera holds static. The subject walks left to right." Two clauses, two owners of motion.
- Use speed words deliberately. "Slowly," "steadily," "quickly" are useful. "Dramatically" and "cinematically" are not speed words — they are hopes.
- Name the end state when it matters. "Pushes in until the subject fills the frame" gives the model a target.
- Negative phrasing is weak. Prefer "static camera" over "no camera movement."
If you remember only one thing: one clause, one intent. When a clip drifts, the first thing to check is whether a motion clause secretly contains two movements.
Copy-paste recipe templates
Below is a general-purpose skeleton. Copy it, fill the slots, and keep the labels in place — the labels are for you, not the model, so strip them before sending if you prefer.
[KEYFRAME A]
Subject: {{subject_a}}
Scene: {{scene_a}}
Framing: {{framing_a}}
Light: {{light_a}}
[KEYFRAME B]
Subject: {{subject_b}}
Scene: {{scene_b}}
Framing: {{framing_b}}
Light: {{light_b}}
[MOTION]
Camera: {{camera_move}}
Subject: {{subject_move}}
Pacing: {{pacing}}
A filled example, for a short product-style clip:
[KEYFRAME A]
Subject: a single ceramic mug, handle facing right, steam rising
Scene: on a wooden desk, blurred window behind
Framing: close-up, slightly above eye level, mug centered
Light: soft morning side light from the left
[KEYFRAME B]
Subject: the same ceramic mug, steam thinner, handle facing right
Scene: same wooden desk, window still blurred
Framing: close-up, slightly above eye level, mug centered
Light: slightly warmer morning light from the left
[MOTION]
Camera: slow push in
Subject: steam drifts upward and fades
Pacing: steady, unhurried
Two slots deserve extra care. {{camera_move}} should be a single movement from your short list. {{pacing}} sets the energy of the whole clip — it is the cheapest knob to turn when a result feels too fast or too slow.
Keep a small library of these filled templates. A handful of well-tested skeletons with obvious slots will outperform one-off hand-written prompts almost every time, because the variables stay isolated and visible.
Recipe variants for different motion intents
The template stays the same; only the motion block changes. Here are three variants built on identical keyframe blocks, each targeting a different intent.
Variant 1: Reveal (camera does the work)
[MOTION]
Camera: slow push in from medium to close-up
Subject: holds pose, breathing only
Pacing: slow, even
Use when the subject is the payoff and you want the frame to tighten around it. Keep subject motion to a minimum so the camera move reads clearly.
Variant 2: Traversal (subject does the work)
[MOTION]
Camera: static, locked off
Subject: walks left to right across frame, steady stride
Pacing: moderate, continuous
Use when the keyframes describe a path or a change of position. A locked camera makes the traversal legible; two competing movements would blur it.
Variant 3: Atmosphere (environment does the work)
[MOTION]
Camera: very slow lateral drift
Subject: mostly still, slight sway
Pacing: slow, ambient
Use for establishing shots and backgrounds where light, haze, or particles carry the clip. The subject anchors the frame; the environment provides the change.
Notice what did not change: the keyframe descriptions. That is the point of the structure. Once your anchors are stable, swapping motion intents is a two-line edit rather than a rewrite — which makes A/B testing clips on the same scene genuinely practical.
Failure modes and how to debug a drifting clip
When a clip drifts, resist the urge to rewrite the prompt. Drift is information. Change one variable at a time and re-run before touching anything else.
Here are the common failure modes and the single-variable fix for each.
The clip feels chaotic or "averaged"
Cause: two or more motion intents in one clause. Fix: split the motion block into separate lines and delete everything except the dominant movement.
The subject morphs or loses identity
Cause: the text is over-describing the subject, competing with the keyframes. Fix: trim the subject line in both keyframes to count, posture, and one defining detail. Let the anchor carry identity.
The camera moves when you asked it not to
Cause: implied motion elsewhere, or pacing words that suggest energy. Fix: state "the camera holds static" as its own clause and soften the pacing word.
Motion arrives too fast or too slow
Cause: pacing is unstated or contradicted.
Fix: change only {{pacing}}. Re-run. Do not adjust the camera clause in the same pass.
The clip ignores the second keyframe
Cause: keyframe B diverges from A in too many dimensions at once. Fix: compare the two descriptions line by line and reduce the difference on the line that matters least. Change one line, re-run, repeat.
The discipline is simple: one variable per iteration, and keep a short note of what you changed. After three or four passes you will usually find the single line responsible, and you will have learned something reusable about the recipe itself.
Versioning and sharing recipes across a team
Once a recipe works, it stops being a prompt and becomes a project asset. Treat it like one.
A lightweight system is enough:
- Store recipes in your repo. A
prompts/directory with one file per recipe, alongside the code that consumes them. Recipes and request code version together. - Name by intent, not by scene.
reveal-product-closeup.mdis findable;prompt-final-v3-really.mdis not. - Keep the skeleton and the fill separate. Store the template once, and keep filled examples as small diffs against it. Reviewers can then see exactly which slots changed.
- Log what you changed and what happened. A two-line changelog per recipe — variable changed, observed effect — is worth more than a long prose description.
- Review recipes like code. A teammate should be able to read the diff and predict the clip. If they cannot, the motion clauses are doing too much.
- Retire deliberately. When a recipe is superseded, mark it and link to the replacement rather than deleting it, so old clips remain reproducible.
This is the unglamorous part of the workflow, and it is what separates teams that ship consistent clips from teams that re-litigate prompts on every ticket. When you are ready to run these recipes through a single unified interface, wire up your requests end to end and start from the flux-3-max keyframes-to-video model page.
Related articles
View all articles →-
Guide
Getting Started with seedream-5.0-pro/image-to-image: Capabilities, Pricing, and Integration Essentials
Capability boundaries, billing model, and engineering integration practices for ByteDance's image editing model
-
Guide
seedream-5.0-pro Text-to-Image Getting Started Guide: Capability Boundaries, API Integration, and Cost Control
A hands-on developer perspective: from key parameters to a cost estimate of $0.05 per image
-
Guide
Hailuo 2.3 Fast Image-to-Video Getting Started Guide: Capability Boundaries, Pricing, and Integration Practices
MiniMax image-to-video model selection and integration key points for developers