MiniMax H3 Max Turbo Generate Video

MiniMax H3 Max Turbo Generate Video is a separate node because it's a separate model: it calls MiniMax-H3-Max-Turbo, and the entire thing is a speed-and-price play on the Max tier. Roughly half the output rate, same 480P/768P options, same 5–15 second range - and no reference media. None. You get text-to-video, first-frame, or first-and-last-frame, and that's the menu.

For a lot of drafts, that's enough. A talking-head shot or a landscape pan doesn't need nine reference images, and paying the Max reference-video rate for a test render you'll bin anyway is silly.

Same inputs, one fewer question

The four required inputs are identical to Max: content from Content Builder, resolution (480P or 768P), duration from 5 to 15, and ratio across the usual seven choices. The two optional inputs also carry over unchanged - prompt_expansion_mode (disabled, balanced, quality, default balanced) and seed, where 0 omits the field for server-side randomness and anything from 1 to 4294967295 pins it.

The difference is enforcement. Attach a reference image, video or audio to content aimed at this node and it stops with: MiniMax-H3-Max-Turbo does not support reference images, videos, or audios; use MiniMax-H3-Max. That's a helpful error, and it's the pack being polite about a hard API limitation rather than guessing. First and last frames still work fine - last_frame still requires first_frame, and frames still can't be mixed with references.

Content is also still checked for exactly one non-empty text item with roles the pack recognises, so build it in Content Builder and you'll never see that validation fail.

What you get back

video_url, task_id, status, task_json, request_json. The first is the one you care about - send it to Preview Video to pull the MP4 down, or to Query Task if you want to re-read the task later. status and task_json are what you inspect when a job fails; the node polls the task to a terminal state, so a returned video_url means the clip actually exists, not that it was queued.

There's no 2K tier here and no regeneration path, and Context IR isn't part of this model's flow either. If you need either, you're on the plain H3 node.

The money

Output runs ¥0.17/second at 480P and ¥0.26/second at 768P, against Max's ¥0.33 and ¥0.50. Overseas USD rates are 0.025 and 0.04. No input-video charges, because there's no input video; no extra-image charges, because there are no reference images. A 5-second 768P Turbo clip is about ¥1.30 - versus ¥2.50 on Max and ¥2.50 on plain H3 at 768P.

One quirk in how the node estimates: when the API's usage payload omits output_seconds for Turbo, the pack falls back to total_seconds rather than reporting an incomplete estimate the way Max does. Same estimate, slightly different reasoning - the number on screen is still just an estimate and MiniMax's invoice wins.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/magicwang1111/ComfyUI-MiniMax-H3-API

Restart ComfyUI, then cp local.example.json local.json in the pack folder and add your MiniMax key. Match the endpoint to the key's region - https://api.minimax.cn for China, https://api.minimax.io for overseas - since the two bill in different currencies and a mismatched pair fails on the first run. Installation pulls only requests and Pillow. ComfyUI Manager: search ComfyUI-MiniMax-H3-API.

Verdict

Reach for Turbo when the prompt is the whole story and you're iterating fast; switch to Max the moment you need to show the model a face, a product or a clip you shot yourself. And if 480P looks soft to you, that's the model, not the node - 768P is a real step up and still half the price of Max.