One idea, two models: Seedance writes structure into the text, MiniMax writes it into the protocol

Open both vendors' prompt documentation side by side and your first impression will mislead you.

On the ByteDance side, the Seedance 2.0 prompt guide runs past forty thousand characters. Basic formula, advanced formula, subject-definition syntax, shot sequencing, action-writing standards, camera guidance, constraint-word templates, and twelve failure modes with fixes — including "trim 6 frames off the end of the previous clip and 1 frame off the start of the next" when your extension joins jump. That's an editing lesson, not prompt advice.

On the MiniMax side, the page at the video-prompt URL is titled H3 Feature Highlights and contains six examples in a gallery.

The natural conclusion: one vendor has conventions, the other doesn't.

That conclusion is wrong. MiniMax has just as many rules. They live in a different layer — the API. And once you see that, the comparison stops being about who wrote better documentation and becomes a more interesting question: should structure live in the prose, or in the protocol?

The same job, two homes

Take the most concrete task there is: telling the model that this image carries the character and that clip carries the camera move.

Seedance does it in the prompt text.

Define the woman wearing a red dress and a straw hat in Image 1 as Subject 1

There's a tighter binding form too, <Subject_N>@<Image_N>. And you're expected to reuse that exact label every time you mention her — switch words once and the model may treat her as somebody else.

MiniMax does it in the request schema.

"content": [
  { "type": "text",      "text": "..." },
  { "type": "image_url", "image_url": {...}, "role": "reference_image" },
  { "type": "video_url", "video_url": {...}, "role": "reference_video" }
]

role is an enum with exactly five legal values: first_frame, last_frame, reference_image, reference_video, reference_audio. Asset responsibility is carried by the field, so the prose can just point at things. The official launch post demonstrates it:

Reference the Hitchcock camera movement from Video 1, have the character in Image 2 sing, with the vocals matching Audio 3.

One sentence, zero notation.

This difference isn't stylistic, it's consequential. Typo Subject 1 as Subject l in a Seedance prompt and nothing tells you — it generates anyway, just inexplicably. Typo a role value in MiniMax and the API returns 400.

Structure in the text layer means errors arrive as silent drift. Structure in the protocol layer means errors arrive as an immediate failure.

The second reversal: on camera moves, MiniMax is the stricter one

This runs against most people's intuition. I only found it by reading the API reference.

Seedance's camera section reads:

The model has a strong understanding of camera movement terms, so you can directly use standard camera movement terminology, such as "medium shot, close-up, wide shot, slow push-in, smooth lateral tracking, fixed shot."

Such as. Examples, not an inventory. It never tells you what the full set is. (The 1.0 guide's such as Tracking Shot, Pan Left/Right, Truck Left/Right is open-ended in exactly the same way — both generations decline to enumerate.)

MiniMax's API reference hands you a closed table, headed verbatim Supported 15 camera commands:

[Truck left] [Truck right] [Pan left] [Pan right] [Push in] [Pull out] [Pedestal up] [Pedestal down] [Tilt up] [Tilt down] [Zoom in] [Zoom out] [Shake] [Tracking shot] [Static shot]

Plus usage rules:

• multiple commands inside one [] take effect simultaneously, e.g. [Pan left,Pedestal up], with a recommended maximum of 3;
• commands apply in the order they appear, e.g. "...[Push in], then...[Push out]";
• free-form descriptions work, but explicit commands yield more accurate results.

Incidentally, the two vendors give opposite advice on how many moves per shot: Seedance says one, because more destabilises the image; MiniMax says up to three can be combined in one bracket.

One honest boundary. That table is documented under MiniMax-Hailuo-2.3, MiniMax-Hailuo-2.3-Fast, MiniMax-Hailuo-02, T2V-01-Director and I2V-01-Director — it is not restated on the H3 endpoint. The H3 guide only offers lowercase e.g., [pan], [zoom], [static]. So what you can say is that bracket syntax is a MiniMax house convention across generations and the full vocabulary is documented on the Director/Hailuo line. You cannot say "H3 supports these fifteen."

Even with that caveat, the impression that MiniMax gives thinner camera guidance is simply false. It just isn't on the page you'd think to look at.

The third difference: the shot breakdown, and this one is real

The first two are questions of which layer structure lives in. This one is an actual difference of position.

Seedance's shot-sequencing section is explicit and comes with a worked bad example:

A man runs nervously down the street, and the scene feels very cinematic.

And the good one:

Shot 1: Side shot of a street alley; the man slowly starts running, with a sense of rapid breathing. Shot 2: The man knocks over a fruit stand; the camera shakes quickly and gives a close-up of the man's frightened face. Shot 3: The man climbs over a low wall and disappears; the camera slowly pulls back and freezes on the empty street.

The MiniMax version is a single Core story: passage, and the model decides how many cuts it needs and where. Its API has no shot field at all — this isn't "you may omit it," it's "there is nowhere to put it."

It can afford that because the work happened lower down. The H3 launch post lists Native multi-shot modeling among its pretraining properties. Multi-shot is native.

So this row isn't about documentation depth. It's about who owns the shot breakdown. Seedance hands it to you along with the responsibility. MiniMax took it back, and took the field with it.

One clue that ties MiniMax's evolution together

Dig through the older endpoints and you find a parameter H3 no longer has: prompt_optimizer.

Whether to automatically optimize the prompt. Defaults to true. Set to false for more precise control.

Default true. In the Hailuo generation, your prompt was rewritten by an optimizer unless you opted out — and those models capped prompts at 2,000 characters.

The H3 v2 endpoint has no such parameter, and the cap rises to 7,000 characters per text item. Subject reference also collapsed from a dedicated S2V-01 endpoint with its own subject_reference[] field into a single role inside content[].

Three changes pointing the same way: from "write whatever, I'll rewrite it" to "say it properly, I won't touch your words." The launch post's describe their intent directly in natural language only reads as substantive once you notice the rewriting layer was genuinely removed.

And one less flattering difference

Seedance's documentation admits failure.

It states in writing that subtitles cannot currently be avoided 100% of the time, then offers three mitigations — including "if your business allows it, generate landscape, because landscape produces subtitles noticeably less often than portrait, and crop afterwards." It says the duplicate-character problem can't be fully avoided either, and supplies a global constraint line for it. It says extended videos degrade, that repeat extensions compound the damage, and that faces get mottled first. It notes the model mispronounces Chinese homographs and suggests substituting a common same-sound character.

MiniMax has no equivalent layer. What it has is API error codes — 400 bad params, 402 insufficient balance, 422 sensitive content, 429 rate limit. Those are protocol failures, not generation failures.

Put differently: MiniMax will tell you very precisely that a request is invalid. It won't tell you what you're in for when the request is perfectly valid.

For a working creator that Seedance page is arguably worth more than the formula. A formula tells you how to write. A failure list tells you which walls exist and where to go once you've hit one.

The whole thing in one table

Dimension	Seedance 2.0 (ByteDance)	MiniMax H3
Where structure lives	prompt text	request schema
Asset binding	<Subject_N>@<Image_N>, define … as …, declared once and reused	role field, five enum values; prose just points
What a typo does	silent drift	immediate 400
Camera vocabulary	such as … (open-ended examples)	closed list of 15 named commands plus combination/sequence rules
Moves per shot	recommends 1	up to 3 combined in one bracket
Shot breakdown	you write it (Shot 1 / 2 / 3)	native to the model; no API field
Timing	says precise timing is unstable, don't force it	duration is a required integer; ratio is forced to adaptive in i2v, so prompt text can't set it
Is your prompt rewritten?	no optimizer offered	legacy defaulted to true; removed in H3
Constraints / negatives	dedicated section with templates	none
Troubleshooting	12 symptoms with step-level fixes	API error codes only

So which is better?

Wrong question. Two better ones:

1. Do I want to make the execution-layer decisions on this piece?

"Execution layer" means where cuts fall, how long each beat runs, how the camera moves, which asset locks which feature in which shot. Seedance assumes you want those calls and gives you syntax for them. MiniMax assumes you only want to state intent, and leaves you exactly one piece of prose syntax: the camera brackets.

• A narrative order that must hold — the phone dies, then she looks up, then the train passes — or one character surviving several shots in the same coat: you need the shot breakdown.
• A tone-driven piece — brand film, mood piece, product showcase — where cuts only need to be attractive and unjarring: handing execution over is less work.

2. Which layer do I want my mistakes caught in?

Fewer people ask this one, and it matters more. With structure in the protocol, you get stopped before you spend anything — no text is a 400, mixing first-frame with references simply fails. With structure in the prose, everything submits, you're billed, and you receive a video that's subtly wrong in a way you can't name.

Neither is free. A strict protocol means reading the schema first. A permissive text layer means being your own linter.

A practical way to end this

Before writing anything, split the video in your head into two piles.

Intent — what this is about, who it's for, what tone, how long, what it sounds like. Execution — how many cuts, where, how the camera moves, who's in each shot, which asset locks which feature.

Both vendors need the intent layer. They differ on execution: Seedance wants it written into the prose; MiniMax puts part of it in the schema and the rest inside the model.

And here's the unglamorous part — if your intent layer is vague, neither of them can save you. A formula's value is that it forces you to fill in every field. A schema's value is that it rejects illegal requests. Neither one will ever tell you that you failed to say what you wanted. That gap doesn't throw an error. It just gets quietly filled in by the model.

A model can decide where to cut. It cannot decide what you wanted to film.

Further reading

• Writing for MiniMax: "How to prompt MiniMax H3: the formula isn't in the guide, it's in the API"
• Writing for Seedance: the field-by-field walkthrough is currently published in Traditional Chinese only; the underlying source is the BytePlus prompt guide linked below.

Official sources

Every comparison rests on publicly readable English documentation from both vendors. The Seedance side follows BytePlus's Seedance 2.0 series prompt guide; the MiniMax side follows its v2 and legacy API references, developer guides and the H3 launch post. The 15 camera commands are documented for the Hailuo/Director line and are not restated on the H3 endpoint; this article does not claim H3 supports them.

Last verified: 2026-08-01.

• Seedance 2.0 series prompt guide (BytePlus)
• Create Video Generation Task (MiniMax v2, H3 endpoint)
• Create Text-to-Video Generation Task (MiniMax legacy, with the 15-command table)
• Video Generation (MiniMax guide)
• MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities (launch post)