MiniMax H3 Max Text-to-Video Prompt Recipes for Developers

What a Good Text-to-Video Prompt Is Made Of

A text-to-video prompt is not a sentence. It is a small configuration file written in natural language. When a generation comes back wrong, the useful question is never "was the prompt good?" but "which part of the prompt failed?" That question is only answerable if the prompt has parts you can point at.

Treat every prompt as six separable blocks:

• Subject — who or what is on screen, with enough specificity to be consistent across runs (species, material, wardrobe, age range, distinguishing feature).
• Action — what the subject does, in the order it happens. This is the beat sheet, not the mood.
• Scene — location, time of day, weather, background activity, and light source.
• Camera — where the camera is, how it moves, and at what pace. This is a separate concern from the scene and deserves its own line.
• Duration — how long the clip should run, and implicitly how many action beats fit inside it.
• Resolution — the output tier you are targeting for this pass.

The reason to keep these blocks physically separate — one line or one labeled fragment each — is that video generation is a many-variable optimization problem and you only get to move one variable per experiment. If subject, camera, and duration are tangled in a single flowing paragraph, changing the camera means you also changed the subject's phrasing and the rhythm of the sentence, and you can no longer tell which change produced the different result.

Separated blocks also survive editing. A subject block can be reused across ten shots in the same scene. A camera block can be swapped like a lens. A duration block can be raised or lowered without rewriting the action. Prompts written as prose get rewritten from scratch every time; prompts written as blocks get diffed.

The last thing worth internalizing: these blocks are not equally powerful. Subject and action changes are usually visible and intuitive. Camera phrasing and duration changes are where most unexpected results come from, in both directions — a single preposition can flip the framing, and a duration change can silently delete your final action beat. Budget your attention accordingly, and give camera and duration their own tunable slots rather than burying them in adjectives.

Everything below builds on this anatomy. The recipes are just well-formed block sets you can copy and edit.

Anatomy of a Copy-Paste Recipe

A recipe is a prompt template with labeled slots. Copy it, fill the slots, send it, and you have a result you can compare against the next version because the structure never changed.

Use this skeleton as the base for every experiment:

SUBJECT: <who/what, with 2–3 identifying details>
ACTION: <beat 1> -> <beat 2> -> <beat 3>
SCENE: <location>, <time of day>, <light source>, <background activity>
CAMERA: <position>, <movement>, <pace>
DURATION: <target length>
RESOLUTION: <tier for this pass>

Two rules make the template useful rather than ceremonial.

Separate the slots that vary from the slots that stay fixed

In a typical project, SUBJECT and SCENE are your stable baseline — you are shooting the same character in the same location across many shots. ACTION, CAMERA, DURATION, and RESOLUTION are the per-shot variables. Mark them mentally as fixed versus floating, and when you run experiments, only touch the floating ones. If a result surprises you and you also changed the subject description that run, you have burned a test.

Write ACTION as beats, not adjectives

A beat list gives you something to count against duration. walks in -> sets down a box -> looks up is three beats; if the clip comes back with only two of them, you know the shot is overpacked or the duration is too short. a busy, dynamic scene gives you nothing to check. Adjectives belong in SCENE and CAMERA pace, where they describe texture rather than sequence.

Keep the labels in the prompt

The uppercase labels are for your own bookkeeping as much as for the model. They make diffs readable in a changelog, they make it obvious when a field was omitted, and they stop the prompt from degrading into prose over successive edits. If a model handles labeled fragments well, keep them; if it prefers flowing sentences, strip the labels on the final pass but keep them in your log so the record stays structured.

A filled example:

SUBJECT: ceramicist in her 40s, clay-dusted apron, hair tied back
ACTION: lifts a wet bowl off the wheel -> turns it to inspect -> sets it on the shelf
SCENE: small studio, late afternoon, single window light from the left, dust in the air
CAMERA: medium close-up at wheel height, slow push in, unhurried pace
DURATION: short pass
RESOLUTION: draft tier

That is the whole format. Every recipe that follows is this skeleton with one slot being the thing under test.

Recipe: Controlling Duration

Duration is not a slider that stretches a scene. It changes what a scene can contain. A short clip is one gesture; a longer clip is a sequence with a beginning, a middle, and an ending, and if you do not write the sequence, the model will invent filler or drop a beat.

So write ACTION to match the duration you are asking for, and state the duration explicitly rather than leaving it to defaults.

Short-clip recipe (one distinct action)

SUBJECT: <consistent subject block>
ACTION: single continuous gesture — <the one thing that happens>
SCENE: <stable scene block>
CAMERA: <fixed position, minimal movement>
DURATION: brief clip, one action beat
RESOLUTION: <current test tier>

Short clips reward restraint. One action, one camera idea, no background subplots. If the subject needs to enter frame, that entry is the action; do not also ask for a turn and a gesture.

Longer-clip recipe (sequenced beats)

SUBJECT: <consistent subject block>
ACTION: beat 1 -> beat 2 -> beat 3 (in this order)
SCENE: <stable scene block, plus any change over time>
CAMERA: <movement that supports the beats>
DURATION: extended clip, three beats
RESOLUTION: <current test tier>

Longer clips need an explicit order and a finite beat count. Three beats is a reasonable target for a single continuous shot; if you need five, consider whether you are actually describing two shots. Also decide which beat earns the extra time — usually the middle one, because the first beat establishes and the last resolves.

How duration phrasing changes pacing

Two practical observations from running these recipes:

• Describing the pace in words matters as much as the length. unhurried, continuous, in one take, and quickly shift how the same beat list distributes across the clip. A three-beat list labeled unhurried and the same list labeled quickly are different shots, not different lengths.
• When a beat goes missing, lengthen before you shorten the action. If your final beat keeps getting truncated, the usual fix is more room, not fewer beats — assuming all three beats are load-bearing.

Keep duration fixed while testing anything else

This is the discipline that makes the recipe worth using. Duration alters pacing, pacing alters how camera moves read, and camera affects how the action appears to unfold. If duration is floating during a camera test, you will misattribute the difference. Lock it, log it, and only then vary the next slot.

The same logic applies to resolution, which is the subject of the next recipe.

Recipe: Choosing a Resolution Tier

Resolution is a cost and iteration-speed decision before it is a quality decision. The prompt does not change much between tiers; what changes is how many attempts you can afford and how quickly you can see whether a prompt idea works at all.

Think in two tiers: a draft tier for exploration and a final tier for delivery. The exact values live in the model's parameter documentation — the point here is the workflow, not the numbers.

Draft-tier recipe

SUBJECT: <subject block>
ACTION: <beat list>
SCENE: <scene block>
CAMERA: <camera block>
DURATION: <short test length>
RESOLUTION: draft tier

Draft runs answer compositional questions: Is the subject recognizable? Does the camera move read? Are all the beats present? At a low tier you can run several variants in the time a single final render would take, which is exactly what you want while the prompt is still moving.

Final-tier recipe

SUBJECT: <locked subject block>
ACTION: <locked beat list>
SCENE: <locked scene block>
CAMERA: <locked camera block>
DURATION: <delivery length>
RESOLUTION: final tier

Notice the word locked. Promotion to the final tier is a promotion of a proven prompt, not another experiment. Change nothing except resolution and duration; if the final render differs in composition from your draft, you have learned that something in the prompt was resolution-sensitive, and that is worth logging.

Choosing a tier per use case

• Exploration and internal review — draft tier. You are checking structure, not polish.
• Prompt regression checks — draft tier. Cheap enough to run on every change.
• Client-facing or embedded delivery — final tier, only after a draft pass matches the intent.
• Background or heavily cropped elements in a composite — draft tier can be sufficient if the element occupies a small part of the frame.

Why testing low first actually saves time

The expensive failure mode in text-to-video is a beautiful, high-resolution render of the wrong shot. Every minute spent polishing a composition you are about to discard is wasted, and at higher tiers the waste compounds because attempts are slower. Draft-tier iteration front-loads the cheap decisions — subject clarity, beat count, camera direction — and reserves the expensive tier for confirmation.

One caveat: do not draft at a tier so low that fine detail becomes unjudgeable. If your shot depends on a small prop or a facial expression, that detail may only be evaluable at a higher tier, and you should promote earlier for those specific checks.

Recipe: Camera Phrasing That Actually Changes the Shot

If you take one thing from this guide, take this: camera phrasing moves results more than almost any adjective you can add to the subject. Two prompts with identical subject, action, and scene but different camera blocks are different shots. Two prompts that differ only in a pile of mood adjectives are often the same shot.

That makes the camera block the highest-leverage slot — and the one most worth testing one phrase at a time.

Movement patterns

CAMERA: static, locked off
CAMERA: slow push in
CAMERA: slow pull out
CAMERA: lateral tracking left to right
CAMERA: handheld follow behind the subject
CAMERA: orbit around the subject, quarter turn

Each of these is a complete, copy-pasteable camera block. They are deliberately short. Long camera sentences tend to contain two competing instructions (push in while orbiting), and when they conflict the output picks one semi-randomly.

Angle patterns

CAMERA: eye level, medium shot
CAMERA: low angle, close on hands
CAMERA: high angle, wide, subject small in frame
CAMERA: over-the-shoulder from behind the subject

Angle is where framing intent lives. "Close on hands" and "subject small in frame" are not moods — they are decisions about what the viewer can see, and they change the shot far more than cinematic does.

Pace patterns

CAMERA: unhurried, deliberate movement
CAMERA: brisk, follows the action closely
CAMERA: settles and holds on the final beat

Pace belongs in the camera block, not the action block. It describes how the camera behaves, and it is the cleanest way to make a long-duration shot feel composed rather than floaty.

Swap one phrase at a time

The method that makes camera phrasing legible:

1. Write a base prompt with subject, action, scene, and duration fixed.
2. Run the base with CAMERA: static, locked off.
3. Change only the camera line — one swap per run.
4. Keep the clip from each run and label it with the camera phrase used.

After four or five runs you have a private phrasebook: you know what slow push in does to your subject in your scene, which is more valuable than any generic list. Do this once per project and the phrasebook carries over to every subsequent shot.

Two failure modes

• Stacked instructions. push in, then orbit, then pull out inside a short clip asks for three camera moves the duration cannot hold. One move per shot.
• Adjective substitution. Replacing a camera move with a mood word (dramatic, dynamic, epic) does not specify a camera. If nothing in the camera block says where the camera is or what it does, you have left the most important slot empty.

Embedding and Comparing Real Outputs

A recipe is only useful if you can tell whether version B beat version A. That requires a harness — a small, boring routine for producing and lining up outputs so comparison is mechanical rather than vibes-based.

You do not need tooling. You need discipline and a folder.

The harness, in five steps

1. Fix everything you are not testing. Write a baseline.md containing the subject, action, scene, and duration blocks that stay constant for this experiment. Every run in the batch copies those blocks verbatim.
2. Name the variable. One run, one changed slot. If you are testing camera phrasing, the camera line is the only line that differs between files.
3. Generate the batch. Run all variants at the same draft tier and the same duration so the comparison is fair.
4. Line them up. Play the clips back-to-back in the same order every time, or place them side by side in a simple grid. Sequence matters — the eye compares better when the position is stable between viewings.
5. Record a verdict per variant. One sentence each: what changed, whether it was the change you intended, and whether you would keep it.

What to look at when comparing

• Beat completeness — did all the beats in your action list appear, in order?
• Camera read — could a viewer describe the camera behavior without being told?
• Subject consistency — is the subject recognizable as the same subject block across runs?
• Unintended changes — did swapping the camera phrase secretly change the scene? That is a sign your blocks are leaking into each other.

That last check is the real payoff of the harness. When blocks are clean, one slot changes one thing. When they leak, you get cross-talk you would never notice from a single viewing — and cross-talk is exactly what makes prompt iteration feel random.

Keep the harness small

A batch of four or five variants is enough to make a decision. Larger batches dilute attention and tempt you to skim. If the first batch is inconclusive, the answer is usually that the variable you chose is too subtle, not that you need twenty more runs.

Finally, feed the verdicts back into your recipe files. A winning camera phrase should be promoted into the baseline template so you stop rediscovering it.

A Repeatable Prompt Iteration Workflow

Here is the full loop, assembled from the recipes above. It is deliberately unglamorous, and it is the difference between a prompt collection that improves and one that drifts.

Step 1 — Draft the blocks

Fill the template once: subject, action beats, scene, camera, duration, resolution. Do not polish. The first version exists to be changed.

Step 2 — Run cheap, run short

Generate at the draft tier with a short duration. You are buying information about composition, beat count, and camera read — nothing else. Run two or three variants, each differing in one floating slot.

Step 3 — Pick a winner and lock it

When a variant does what you intended, copy its exact text into a locked/ file. Locking means you stop editing that file; future experiments branch from it rather than mutating it. This single habit prevents the most common regression: losing the good version because you kept tweaking in place.

Step 4 — Promote to final settings

Change only duration and resolution to their delivery values, then render. If the final differs from the draft in a way that matters, log the discrepancy — that is a resolution-sensitive or duration-sensitive prompt, and you want to know which slots are fragile before the next project.

Step 5 — Log everything

Every run gets an entry. The log is the artifact that makes the workflow compound. Minimum fields:

id: shot03_v2
template: studio-ceramics
variable_tested: camera
prompt: <full prompt text, verbatim>
duration: <value used>
resolution: <tier used>
verdict: <one sentence — what changed, keep or discard>
artifact: <clip path>

Three rules keep the log trustworthy. Verbatim prompts only — a paraphrase cannot be reproduced. One variable per entry — otherwise the log cannot answer "why did this work?" Clip path for every entry — a verdict without the artifact is an opinion.

Step 6 — Prune into a phrasebook

Every few projects, read the log and pull the recurring winners — camera phrases, beat-list shapes, scene blocks — into a shared phrasebook file. The phrasebook is your reusable knowledge; the log is the evidence behind it.

Why the order matters

Cheap-first iteration, then locking, then promotion, then logging: each step depends on the previous one being disciplined. Without locking, promotion tests a moving target. Without logging, locking has no rationale. Without cheap drafts, you cannot afford enough runs to generate anything worth locking.

Run the loop against MiniMax H3 Max text-to-video through HiAPI.ai's unified API, and keep the prompt text and parameter values in your own repository so every win stays reproducible.