MiniMax H3 Reel

---

You will almost certainly never place this node by hand. MiniMax H3 Reel is internal plumbing, marked dev-only, written into the graph automatically by the Creator node when you press Render. But it's the node that makes long H3 pieces actually fit in memory, so it's worth understanding even if you only ever see it when you peek under the hood of an expanded workflow.

Here's the problem it solves. ComfyUI keeps every node's output alive for the whole execution. If a node returned a decoded video pass, that pass - float32 frames plus soundtrack - would sit in memory until the save node at the end of the render had written every pass. A minute of 768p video is around 18 GB held at once, on top of a 33B model's weights. On a machine streaming a staged model from host RAM, that's the difference between a render and the OOM killer meeting you halfway.

How it works

The Reel node does five things in one call, and the whole design is "never let a decoded pass cross a node boundary." It takes the sampled latent plus the video VAE and audio VAE, decodes it, trims it, writes it straight to disk via the pack's spill.py, and returns a path and a frame count - not tensors. The pass exists in memory for the length of that one call and is dropped at the end of it. Peak memory is one pass, whatever the strip is. Previously the pack used a join node that folded passes pairwise, holding N-1 running totals alive

• about 81 GB of intermediates for ten 768p passes on top of the 15 GB of passes themselves. The reel took the intermediates away by carrying references instead of a total; this takes the passes away too.

The decoders are core's own, called rather than copied - VAEDecode's nested unbind and 5-dim reshape, and vae_decode_audio's attenuation of anything hot enough to clip. That's H3's decode contract, and the pack deliberately has no second opinion about it.

Reel nodes chain: each one takes the reel from the pass before it as an ordinary graph edge (no variadic inputs), which also means a pass's cache key names exactly the passes in front of it.

The inputs and outputs that matter

• samples - the sampled AV latent, video and audio halves together.
• vae / audio_vae - the two decoders, both required.
• head / tail - optional frame counts for the runs this pass shares with its neighbours. A blended seam re-generates what it inherited, and an untrimmed pass would play the overlap twice, so these get dropped before anything is written. Optional, so a pass with no blend on it has the same cache key it would have had before either existed.
• reel - the passes in front of this one. Absent on the first.

Outputs are the reel (the running list of parts) and pass (this one pass's reference). Both are pack-custom types (MMC_REEL / MMC_PASS), not images or video - you won't wire them into stock nodes, and you're not meant to.

Installing and running

It comes with the pack - no separate install. Same as every node here:

cd ComfyUI/custom_nodes
git clone https://github.com/roadmaus/ComfyUI-MiniMax-Creator

Restart ComfyUI, no pip install, and you need a ComfyUI that ships comfy_extras/nodes_minimax_h3.py plus the H3 weights in the usual folders (video and audio VAEs in models/vae). If you only ever see this node as a blip in an expanded workflow, that's exactly how it's supposed to be used. The README and the source both make the same point: the reason your ten-pass piece doesn't eat your machine is that this node refuses to hold more than one pass at a time. It's the quiet hero of the whole pack.