H3 Studio · Condition & Route

Most of the nodes in H3 Studio have a visible job: the Director takes your prompt and references, the Decode turns latents into pixels. This one is the unglamorous middle layer - and it's the reason you don't have to think about H3's weirdness. If you use the maintained workflow you'll see it sitting between the Model Loader/Director and the sampler, doing exactly what its name says: deciding which H3 route to take, then building the conditioning and latent for it.

H3 has two generation paths. FL2VA handles text-to-image and image-to-image; REF2VA is the reference-edit path where one or more images are the primary conditioning. That distinction is why a "Condition" node needs a "Route" - feeding references into the wrong path is a classic H3 failure, and this node exists to not do that. It consumes the h3_bundle from H3 Studio · Model Loader and the studio_context from H3 Studio · Image Director, picks the route (or honors the route you set in the Director), encodes the prompt and images once, prepares the temporal latent, and loads the transformer the route actually needs.

What it returns

The outputs are ordinary ComfyUI types plus one typed bundle, which is the whole point - everything downstream just sees a normal graph:

• model - the loaded FL2VA or REF2VA transformer, ready for a sampler.
• generation - a typed H3_STUDIO_GENERATION bundle you can hand to H3 Studio · Unpack Generation if you'd rather do the sampling yourself.
• positive - the compiled conditioning (prompt plus reference encoding).
• h3_latent - the prepared temporal latent packet.
• video_vae, requested_frames, run_info - VAE for decoding, frame count for the temporal profile, and a string report of what actually happened.

The caching story

Under the hood this node is also where the separate prompt, reference-VAE, source-VAE and latent caches live. If you're doing repeated runs with the same prompt or references, those caches are what keep you from re-encoding images every single time. The node is deliberately hands-off about memory, though: "ComfyUI alone owns model residency and offloading" is in the description, which is a polite way of saying it doesn't try to outsmart ComfyUI's memory management - it just uses it.

What to set

Virtually nothing, honestly. There are no widgets - you connect h3_bundle and studio_context and the node does the work. The only real decisions live upstream (which models you loaded, what route the Director chose). If a route or reference combination is impossible, it gets rejected here with an actionable error before any expensive sampling, which is much nicer than discovering it after ten minutes of conditioning.

The one thing worth doing: don't skip the Director's route understanding. auto routing here means text-to-image uses FL2VA without silently consuming your connected references, and reference edits use REF2VA. If you force a route in the Director and it conflicts with what's actually connected, this is the node that tells you - read the run_info output if something behaves unexpectedly.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/thaakeno/ComfyUI-MiniMax-H3-Studio.git
cd ComfyUI-MiniMax-H3-Studio
python -m pip install -r requirements.txt

Restart and hard-refresh the frontend. No extra dependencies beyond the pack itself, and the core H3 models are never auto-downloaded - install them first via Model Setup or the README. Alpha caveats apply, and ComfyUI Nodes 2.0 isn't supported yet.