MiniMax H3 Preflight (T8)

You know the feeling: you queue a 124-frame, 1088×544 H3 render with two reference videos, walk away for fifteen minutes, and come back to a CUDA out-of-memory error that was completely predictable from the inputs. MiniMaxH3PreflightT8 is the node that makes that prediction before you press run - a stable, no-sampling audit of your dimensions, frame count, audio mode, media references, and VRAM risk.

MiniMax H3 is a 33B joint audio-video transformer, and it punishes sloppy inputs: width/height must be multiples of 32, frame counts sit on a 17n+5 grid (22, 124, 362 - never just "whatever seconds you guessed"), and every reference image, video, or audio track you add grows the sequence length and VRAM. Preflight checks all of that against what you told it and hands you a verdict before the model ever loads.

How it works

You give it the intended width, height, length, and audio_mode, plus - optionally - the actual model, video_vae, audio_vae, drive_audio, and any reference inputs (ref_images, ref_videos, ref_audios via autogrow). It cross-checks alignment against H3's grid constraints, audits the media tag bindings (that's where "prompt media tag validation failed" errors get caught early), and flags VRAM risk based on canvas, frame count, and how many references you're throwing at it. Then it returns:

• ready - a real BOOLEAN you can wire into a gate node or just read.
• warning_count - how many things are worth worrying about.
• report_json - the human-readable breakdown of what's wrong and what's merely risky.

Nothing samples, nothing decodes, and the model/VAE inputs are optional - you can run the geometry checks with no weights loaded at all. The author's stance, repeated all through the README: a 16GB card is not a blank check. Start small (22 frames, small canvas, stock sampler), confirm clean decode, then grow. Preflight is that discipline made into a node.

When you'd actually bother

Honestly? It pays for itself the first time it catches a width that isn't 32-aligned or a "124 frames" that's actually a 5n+2 violation on a task where the official node would have silently produced something broken. The pack's own guidance is to keep preflight reports around while debugging - when you get an OOM, NaN, or glitch, the report gives you the input side of the equation before you start suspecting the model. It also does the audio side: audio_mode: lock_source tells it you're keeping the input track, and it can flag when your reference audio count or sample rate is a risk factor.

It's a stable node for a reason - no experimental caveats, no fail-closed drama. It's the first thing the author's own troubleshooting flow reaches for.

Install

Ships in the MiniMax H3 Audio T8 pack:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8

or search "MiniMax H3 Audio T8" in ComfyUI Manager, then restart. No pip dependencies, no model downloads - you bring the H3 weights, CLIP, and VAEs yourself, and Preflight doesn't need any of them to run its checks. Quick-start workflows live in examples/workflows/01-basic-generation. If your render still dies after a green light, the report is your best starting point for the error log: record task type, model files, width/height, frames, sampler/scheduler, references, and audio sample rate, the way the README's troubleshooting section asks.