MiniMax H3 Content Builder

If you've only used local video models, the MiniMax H3 API will surprise you in one specific way: it doesn't take a prompt. It takes a content array - a list of typed items, each with a role that tells the model whether an image is a first frame, a last frame, or a passing reference. Hand-writing that JSON every run is nobody's idea of fun. Content Builder is the node that assembles it from normal ComfyUI sockets.

What it actually produces

The single output is content (type MINIMAX_H3_CONTENT), and it's what feeds every generation node in the pack - Generate Video, Max, Max Turbo, Fast, and Context IR. It's not a string you can eyeball; it's a typed object the downstream nodes know how to read and validate. That's the whole point: the roles live in one place, so the generator nodes can refuse a request that MiniMax would reject anyway.

Worth knowing early: this node never touches the network and never reads your API key. You can build and wire the whole media side of a workflow before you've topped up a MiniMax account. The key only gets read when a generation node actually executes.

The inputs that matter

There's exactly one required input - prompt, a multiline text box - and the mode is inferred entirely from what you connect to it.

Text-to-video is the prompt with nothing attached. That's it.

Frame-guided is first_frame, last_frame, or both (they're native ComfyUI IMAGE inputs). One detail the docs bury: when you attach a frame, the ratio is forced to adaptive downstream regardless of what you picked. Another: frames and reference media are mutually exclusive - connect both and the node raises First/last frames cannot be mixed with reference media.

Reference mode is image_1–image_9, video_1–video_3 or audio_1–audio_3. At least one image or video is required; audio on its own is rejected, because audio is a texture on top of a picture, not an input by itself.

The conversions that bite people

Everything you connect gets inlined into the request as a base64 data URI, and the encoding path has opinions:

• Images are converted to RGB PNG, and only the first frame of an IMAGE batch is used. Load a 60-frame sequence into image_1 and you'll send one picture.
• Each image must be between 256 and 5760 pixels per side, with an aspect ratio between 0.4 and 2.5, and under 30 MB.
• Reference video must be 2–15 seconds and under 50 MB; audio must be 2–15 seconds and under 15 MB, re-encoded to 16-bit WAV.
• Prompts are capped at 7000 characters, and the whole assembled request has to land under 64 MB.

That last one is the real ceiling. Three reference clips plus nine images can blow past it, and the error message tells you to use public URLs or mm_file:// references instead - which means bypassing this node for those specific items and assembling the content by hand.

Install

Same pack, same two steps:

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

Restart ComfyUI, then copy local.example.json to local.json in the pack folder and drop your MiniMax key in. Dependencies are just requests and Pillow per the pack's requirements.txt - no models to download, no GPU work. Or search ComfyUI-MiniMax-H3-API in ComfyUI Manager.

When it fights you

Image aspect ratio must be between 0.4 and 2.5 is the one you'll hit first, because portrait crops and 21:9 images both fall outside it. Resize before you feed it in.

If a generation node complains that your content needs "exactly one non-empty text item", you've built content somewhere else, or the roles are wrong - the Max nodes read roles strictly and treat anything they don't recognise as a hard error. Start from Content Builder, don't hand-edit.

And if you're on Max Turbo, remember that references don't exist on that model at all. Anything beyond a first and last frame belongs on Max.