MiniMax H3 · Quality Latent 2-Pass Delivery

The R42 Universal Delivery system's whole trick is that several proven delivery pipelines live in one graph, and ComfyUI's lazy-input protocol decides which one actually runs. IAMCCS_MiniMaxH3UniversalFastR42 is the "fast" member of that family - the quality latent two-pass route that R42 exposes as a first-class delivery option. Display name: Quality Latent 2-Pass Delivery.

If the name sounds familiar, good. This node is a thin R42 adapter over the author's IAMCCS_MiniMaxH3FastLatent2PassR41 implementation - the class literally subclasses it. All the real work (the two-pass latent strategy, the delivery logic) is inherited from R41; the R42 layer adds one crucial behavior: it refuses to run unless the shot plan actually selected the fast route.

That route-check is the essence of the universal architecture. Each delivery adapter verifies it's the chosen route and raises otherwise, so you can wire every branch into the graph safely - the route controller in the shot plan (selected via IAMCCS_MiniMaxH3UniversalRouteControlR42) decides which one ComfyUI requests, and the losers never execute. When the fast route is selected, this adapter forces queue_next_segment on and hands the graph a finished segment path.

What does "fast latent two-pass" actually buy you? It's the quality-vs-speed middle path in the R42 menu. The route list from the source code shows the full spread: off (no upscale, native delivery), h3_pixel_refine (the windowed pixel refine), rtx_final (RTX VSR upscale on the native frames), the fast latent two-pass, and the LTX master routes. Where the pixel-refine route works in decoded pixel space at the end, the two-pass approach stays in latent space longer and does its quality work in two sampling passes before the final decode - which is generally the cheaper route to a clean result. For long multi-segment renders where the full pixel-refine pass feels like overkill, this is the branch you reach for.

Inputs and outputs

It presents as a delivery sink with the full segment-choreography input set: model, clip, video_vae, audio_vae, the sampled_latent, stage1_conditioning, cine_linx, the checkpointed native_frames/native_audio, resolved_render_id and native_saved_report strings, current_segment/total_segments, context_trim_frames/join_trim_frames, and queue_next_segment. Plus optional continuity sockets - motion_state, bridge_frame, first/last-frame overrides, and a bank of ref_image_1..4 / ref_video / ref_audio reference inputs for conditioning the pass. Outputs: video_path and report.

For most people the meaningful knobs are queue_next_segment (auto-chain your segments) and making sure native_saved_report is wired from the checkpoint - the fast route, like its siblings, insists it runs after the native safety checkpoint.

The honest take

You won't hand-pick this node out of a toolbox; you pick the route, and R42 pulls this branch in when you choose fast. If you're comparing delivery routes, think of it as the pragmatic default: cheaper than pixel-refine, far cheaper than RTX VSR, and the natural first thing to try when native looks fine but you want the quality pass without the hours. One warning: since it subclasses R41, its behavior tracks the author's R41 updates - if a reference workflow expects R41 semantics, keep both versions in sync rather than mixing old and new branches.

Install

Part of IAMCCS-nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes

or ComfyUI Manager (search "IAMCCS"), then restart. You need the R42 ecosystem and the H3 stack - current ComfyUI (≥ 3.x), Python ≥ 3.12, PyTorch ≥ 2.8, MiniMax H3 (~42 GB) plus its video/audio VAEs. H3's licence excludes the US, EU, UK and Korea, so check where you stand before running the local weights.