MiniMax H3 R42 · Universal Route + Queue Owner

Long renders in the R42 universal system auto-queue: when a segment finishes, something has to submit the next one, and the render crawls through the film segment by segment without you babysitting it. But when you have multiple delivery routes in one graph, who owns that queue becomes a real question. IAMCCS_MiniMaxH3UniversalRouteControlR42 is the node that answers it.

Its input is just cine_linx - the shot plan object that flows through the whole IAMCCS pipeline. It reads the selected upscale route out of that plan and translates it into a set of booleans that tell every other node in the graph whether it is allowed to queue the next segment. Read the code and the mapping is clean: if the route is one of the master routes (LTX one-film), the native checkpoint owns the queue and the per-segment deliveries don't; for every per-segment route (native/windowed, RTX final, pixel refine, fast two-pass, LTX per-shot), it's the reverse. Only one node in the graph ever queues - the "sole queue owner" - which is exactly how you avoid two delivery branches fighting over who submits segment 3.

That's the deeper point of the node, and it's the reason R42 can safely have multiple delivery branches connected at once: the branches don't each try to drive the render. They're told, up front, whether they're the driver. If you're not the queue owner, you just do your segment's work and stop.

Inputs and outputs

One required input, cine_linx. Five outputs, and they're the coordination signal:

• native_checkpoint_queues_next (BOOLEAN) - true when the native checkpoint should chain segments (master routes).
• per_segment_delivery_queues_next (BOOLEAN) - true when a per-segment delivery node owns the queue.
• master_delivery_route (BOOLEAN) - true for master routes; convenience mirror of the first.
• selected_route (STRING) - the resolved route name, e.g. off, rtx_final, fast, ltx23.
• report - a human summary naming the route and the queue owner.

You'd wire those booleans into the queue_next_segment inputs of the checkpoint and delivery nodes, or - in a reference workflow - they're already connected for you and this node is just doing its quiet coordination job.

The honest take

This node is pure plumbing, but it's the plumbing that makes the universal architecture not collapse. The failure it prevents is real: without a single queue owner, a render with both a per-segment RTX branch and a master branch wired in could end up double-queuing segments or, worse, having the master route start before the native film is complete. If you're hand-building an R42 graph and your segments mysteriously render out of order or skip, check that this node's outputs are actually feeding the queue_next_segment inputs. The report output makes it easy to confirm which node thinks it owns the queue.

One conceptual trap for beginners: this node doesn't render anything and doesn't set the route - it reads the route that's already in the shot plan (set by the upstream planner/route config) and broadcasts the consequence. If you want a different route, change it in the plan, not here.

Install

Part of IAMCCS-nodes:

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

or via 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 weights (~42 GB) and its video/audio VAEs. And the licence reminder: H3's community terms exclude the US, EU, UK and Korea.