Skip to content
Astral Nexus/Documentation
GET STARTED

MiniMax H3 vs H3 Max Turbo: choose inputs and video specifications

Compare platform input modes, duration and resolution constraints for MiniMax H3 and H3 Max Turbo, then design a matched-specification video evaluation.

Choose these video routes by required inputs and deliverable specifications before comparing cost. This is a platform-contract selection guide, checked against repository definitions on 2026-11-03, not a quality benchmark. Availability and the live request schema must be checked before calling a model.

Filter by the input your project actually needs

Section titled “Filter by the input your project actually needs”
Requirementminimax-h3minimax-h3-max-turbo
Text promptSupportedSupported
First/last framesframes_images, up to 2frames_images, up to 2
General image referencesimages, up to 9Not declared in this route’s schema
Video/audio referencesvideos and audios, up to 3 eachNot declared in this route’s schema
Resolution choices480P, 768P, 2K480P, 768P
Duration4–15 seconds at 768P/2K; 480P starts at 55–15 seconds

The table compares platform fields, not every upstream capability. Frame inputs and general references are different modes. For H3, do not combine frames_images with images, videos or audios. At 480P, an audio reference also needs an image or video reference; AIGC watermark selection and a 4-second request require a compatible higher-resolution route. Validate the entire object, including conditional rules, rather than only the enum lists.

For an existing opening image, start with the frame mode. For motion or audio references, inspect H3’s full reference contract. If you need 2K or a 4-second clip, do not select Turbo simply because its name suggests a faster version. The model name alone establishes neither latency nor task quality.

Use a shared specification for a fair comparison

Section titled “Use a shared specification for a fair comparison”

A text-only, 5-second, 768P, 16:9 request lies within the declared common specification set. This example is request JSON for POST /v1/tasks; it does not execute a generation.

{
"model": "minimax-h3",
"input": {
"prompt": "One continuous shot of a red paper boat moving slowly across a still pond. Keep the whole boat visible. The camera stays fixed; soft daylight and small ripples.",
"seconds": 5,
"resolution": "768P",
"aspect_ratio": "16:9"
}
}

After checking both current schemas and approving a sample budget, the same shared input can be submitted with model: "minimax-h3-max-turbo" for a separate paid attempt. Keep every task ID. Do not resubmit on a polling deadline: a local timeout does not cancel the accepted task. Use the Node.js video workflow for submit, resume and save behavior.

For the boat example, mark each clip against subject visibility, continuous motion, camera stability, duration and usable output. Treat these as your own evaluation criteria. Keep task creation time and terminal observation time; a polling-based elapsed time includes queueing and observation delay, not just inference.

Review repeated approved samples before making a performance claim. Record the prompt, model, specifications, input asset versions, observation window and rejection reasons. A single attractive example is not evidence that one model is consistently better. Neither this guide nor the sample prompt reports measured performance.

Use the calculators on H3 and H3 Max Turbo with the same duration and resolution. Check the displayed billing unit and your account quote. Do not compare one route’s 480P price to another route’s 2K price or infer a universal discount.

For a completed evaluation, divide the actual total charge for the sample by the number of clips you accepted. Include charged rejected attempts and treat zero accepted clips as an unsuccessful evaluation, not a zero-cost result. The batch budget guide explains attempt limits and reconciliation.