MiniMax H3 VLM Guide

MiniMax H3 conditions video from text, and the Qwen3-VL text encoder that reads your prompt can also see - which is the whole reason H3's image-to-video takes reference frames as numbered "pictures" in the prompt text. Those pictures are the anchor points, and the model only knows where in time each one sits because of the timestamp text wrapped around it. This small node from silveroxides' ComfyUI-UtilsCollection gives you a way to inject one more of those anchors at a precise second - an independently-encoded "frame at <N> seconds" block spliced into the conditioning right before your prompt - without re-encoding the whole prompt to do it.

How it works. You feed it an already-built H3 conditioning (conditioning), the Qwen3-VL 32B clip (clip), a single image, and a timestamp in seconds (a float, default 0.0, step 0.1). It encodes that timestamp as text and the image as visual tokens at vlm_resolution - the same equivalent-square Qwen resolution used across this pack's encoders, default 384, effective range 256–3584 - then splices the result into the existing conditioning sequence immediately before the prompt tokens. That last bit is the subtle part: it only works because this pack's MiniMax H3 encoders stamp their conditioning with layout metadata recording exactly where the prompt starts. The guide finds that boundary and inserts itself there, updating the token tags as it goes. Chain two guides and the inserts keep order, so you can anchor multiple moments across a clip.

Output is a single CONDITIONING that you wire back down the same path your original conditioning was taking - into the sampler.

Why it exists and its honest caveat. Stock H3 i2v anchors are first/last frames plus whatever reference pictures you supply; if you want to steer the middle of a clip with a specific pose or look at a specific second, your options were limited. This is a way to point at a moment precisely. But read the pack's own description carefully: the guide is encoded independently - it does not re-encode the original prompt jointly with the inserted block. That means the picture-to-prompt coupling is weaker than native Core picture conditioning, where the whole sequence is encoded together. It's a research-grade steering mechanism, not a Core feature, and it needs the pack's encoders' metadata to know where to insert - feed it conditioning from Core or another pack and you'll get a "requires supported VLM layout metadata; re-encode the conditioning" error, which is the code telling you it wasn't built for that input.

Install. Same pack, same three commands as every node here: ComfyUI Manager → search ComfyUI-UtilsCollection, or

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-UtilsCollection

then restart. Light Python deps (opencv-python, unifiedefficientloader); the real requirement is the MiniMax H3 stack - the ~42.5 GB checkpoint, the Qwen3-VL 32B text encoder, H3 VAE - and the licence reality that the MiniMax H3 Community License excludes the EU, UK, South Korea and the US from its applicable territory.

Where people get burned. It needs qwen3vl_32b - not your SDXL/Qwen-Image clip - and it needs conditioning produced by this pack's H3 encoders, which is a narrower contract than the node's one-line description suggests. In practice: build your conditioning with UC_AdvancedMiniMaxH3ImageToVideo, branch it through this guide, and you're on supported ground. This whole corner of the ecosystem is new and barely discussed - zero impressions on the node page says everyone's still figuring out what these experiments are for. If your clip doesn't need a mid-timeline anchor, skip it; the extra splice is not something you want on every generation.