How to Use MiniMax H3 (API): Limits, Traps, and What a Render Really Costs

MiniMax H3 launched at the end of July 2026 and the documentation has not caught up with it. The pricing page for video packages still says H3 is not supported. The parameter reference lists caps without saying which ones the API enforces and which ones it silently ignores. If you are wiring it into something real, several of the things you need to know are not written down anywhere.

We run H3 in production as one of the render engines behind a product. This is what we would have wanted to read first: the limits that actually bind, the three traps that cost us renders, and how the bill is put together.

The limits that bind

One model, no variants. The video endpoint takes exactly one model value. There is no fast/pro/lite split to reason about, which removes a decision you may be used to making.

Duration is 4 to 15 whole seconds. The allowed values are enumerated, four through fifteen, and fractional durations are not accepted. Fifteen seconds is the longest single continuous take you can get.

Resolution is 768P or 2K. There is no 1080p rung. If your pipeline assumes 1080p exists as a middle option, it does not here — you pick below or above it. Output runs at 24 frames per second, which is film cadence rather than the 30fps most phone-shot feed video uses, and it is visible in fast motion.

Inputs are capped per kind and in total. At most one first frame, one last frame, nine reference images, three reference videos, three reference audio files, and no more than twelve files in a single request. The whole request body is capped at 64MB. Individual caps: reference images up to 30MB each with dimensions between 256 and 5760 pixels and an aspect ratio between 0.4 and 2.5; reference video up to 50MB per clip, 2 to 15 seconds each with a total across all clips of 15 seconds; reference audio up to 15MB, same 2-to-15-second rule.

Prompts can be long. Up to 7,000 characters per text element, and every request must carry at least one non-empty text item or you get error 2013. That is room for a genuine shot-by-shot brief rather than a caption.

Trap one: the ratio rule overrides you

This is the one that produces the most confused bug reports. H3 accepts adaptive, 21:9, 16:9, 4:3, 1:1, 3:4 and 9:16, but which of those you are allowed to set depends on the generation mode:

• Text-to-video requires a concrete ratio and rejects adaptive.
• Image-to-video is always adaptive, and any ratio you pass is ignored.
• Reference-to-video accepts either.

So if you drive a render from a product photo and ask for 9:16, you will get the shape of your photo, not the shape you asked for. The fix is upstream: crop the input frame to the ratio you want before you send it. For vertical ad creative this matters constantly, because product photography usually arrives square or landscape.

Trap two: the silent parameter drop

first_frame and last_frame are mutually exclusive with the reference_image / reference_video / reference_audio family. That is documented. What is not documented is that the API does not enforce it: send both and the request is accepted, billed in full, and one of the two groups is silently dropped.

There is no error, no warning field, and nothing in the response that tells you which half of your intent was thrown away. You find out by looking at the video and noticing your reference was ignored. If you are building a pipeline that can assemble either shape of request, validate the exclusivity yourself before you submit, because the vendor will not.

Trap three: content moderation runs on your inputs

H3 screens what you send in, not only what it sends back, and a rejection surfaces as a failed generation rather than as a validation error at submit. We have hit this in production on inputs that looked unremarkable. Two practical consequences:

Budget for it in your retry logic. A moderation rejection is not a transient error and retrying the identical request will not clear it. Something in the input has to change.

Prefer a still frame over a clip when continuing a shot. Beyond the moderation angle, this is also the cheaper path, for reasons in the next section.

How the bill is actually assembled

Four rules, and the third is the one that catches people:

1. Output video is billed per second at the output resolution's rate.
2. Input audio is free, and the first five reference images are free — after that, images are charged individually.
3. Input video is billed by its own duration at the output resolution's rate, on top of the output. Hand H3 a fifteen-second reference for a ten-second render and you are paying for twenty-five seconds, not ten. This is why a well-built continuation hands over a still tail frame rather than the previous clip: a frame is an image, and images are free up to five.
4. A request that fails at submit costs nothing. A request that completes incorrectly is billed in full. The expensive failure mode is not the rejected call, it is the call that returns something you cannot use.

There is also a regeneration endpoint for upgrading a finished 768P render to 2K, billed per second of regenerated video plus a re-bill of the original inputs. It is narrower than it sounds. It only accepts video that meets H3's own 768P output spec — audio track present, 24fps, width and height each divisible by 32, total area within 768×1344, and 107 to 362 frames — the source task must still be queryable, which gives you a seven-day window, and you must resubmit exactly the same inputs the model saw, which means the final post-processed prompt rather than the text you originally typed. Rendering 768P and upgrading later costs the same as asking for 2K up front; what you buy is the chance to look at the cheap version first.

One more line item worth knowing about: MiniMax offers a separate paid endpoint that reads your multimodal context and returns an enriched video prompt — a shot breakdown, character detail, lighting, soundscape — rather than a video. It is priced per token and is small next to the video seconds, but it is a real second call, and it is the vendor's own answer to prompt adherence.

Throughput is concurrency, not requests per minute

H3 is rate-limited by concurrent tasks, not by requests per minute: two concurrent on the free tier, fifteen on paid. This changes how you build the queue. A per-minute limiter will either under-use your quota or blow through it, because the constraint is how many renders are in flight, not how fast you submit them. Latency is minutes, not seconds — a short clip lands in roughly a minute, a 2K render or a multi-asset request in one to three.

The audio is the part people underestimate

H3 generates sound jointly with the video: stereo, with dialogue support across eleven languages, and a variant that animates mouth movement in sync with the spoken line. You do not bolt a voiceover on afterwards.

For anyone making product video in more than one market, that is the feature that changes the workflow, not the price. It also means your prompt has to carry the audio intent — what is said, in what language, over what music bed — because leaving it unspecified does not give you a silent clip, it gives you sound you did not choose.

Where this fits if you are choosing engines

Two limits above set the boundary between H3 and its usual comparison: the fifteen-second single-call window, and the fact that a reference video is metered by its own length. If you want the cost arithmetic side by side with the other engine we run — including the two counter-intuitive results we measured on our own invoices — that is in Seedance 2.5 vs MiniMax H3: three costs every comparison misses. The joining problem that the fifteen-second ceiling creates, and why continuity across a boundary is harder than generating one clip, is in our production notes on the same ceiling in Seedance 2.0.

If you would rather not build any of this, that is what we do: Riffkit takes a short video that already worked, rebuilds its formula around your product, and handles the segmentation, the reference disambiguation, the audio decisions and the engine choice underneath. The rate for whichever engine and resolution you pick is shown before you render, on the pricing page and in the product itself.