MiniMax H3 R40 · Cached Candidate Selector

In the R40 Shot Lab flow, four cheap candidates get scouted, you eyeball the previews, and then something has to actually choose. IAMCCS_MiniMaxH3SeedSelectR40 is that chooser - and the reason it exists is ComfyUI caching.

Here's the design problem the R40 pipeline solves. If you render four seed candidates and then want to switch from take 2 to take 3, a naive graph would invalidate everything downstream of the swap and rerun half the render. The R40 answer is to isolate the choice in one node whose only real inputs are the cached candidates. Changing the selection (or the stage-2 seed later) reuses the entire candidate bank, because the candidates themselves never changed - only which one flows forward.

The node is lazy in the ComfyUI sense. It declares up to eight optional inputs - sampled_1 through sampled_4 and x0_1 through x0_4 - but it never asks ComfyUI to evaluate all of them. Its check_lazy_status looks at the take-select contract, figures out which candidate and which latent view it actually needs, and requests only that one. Wire all four candidates into it and changing the winning take from 1 to 4 doesn't evaluate candidates 2 and 3 at all on the next run. That's the caching win made visible.

Inputs and outputs

The only required input is take_select, a small contract object produced by IAMCCS_MiniMaxH3TakeSelectControlR40 that records which candidate won (1–4) and which latent view stage-2 should start from (denoised_x0 or sampled_output). The optional sampled_N / x0_N sockets are where you wire the four candidates' two views each.

Outputs:

• native_sampled_latent - the winner's sampled_output, which goes on to the native decode (SelectedDecodeR40).
• stage2_latent - the same take but the view stage-2 refine starts from (denoised x0 by default). Two outputs from one take, deliberately split: native delivery and stage-2 delivery are separate concerns.
• selected_seed - the actual seed of the winning candidate, pulled from the latent's stamp rather than recomputed.
• report - "cached scout reusable=yes" and friends.

Honest caveats

The validation is strict on purpose. If you select candidate 3 but only two candidates were configured as active, this node raises a clear error: "candidate 3 is not active. Increase Candidate Count ... or select an available take." That error message is your friend - it means the graph is telling you exactly which knob to fix rather than silently rendering the wrong take.

The one thing that will bite you: denoised_x0 is the default stage-2 source, and if the stage-2 branch that consumes stage2_latent isn't connected, you'll get a "selected Stage-2 latent is not connected" error. It's not a mystery failure, but it does assume you're running the full R40 graph. If you're pulling this node out of context to experiment, expect to re-wire its whole ecosystem.

Install

Part of IAMCCS-nodes - one install covers it:

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

or ComfyUI Manager (search "IAMCCS"), then restart. You're on a current ComfyUI (≥ 3.x, Python ≥ 3.12, PyTorch ≥ 2.8) with MiniMax H3 and its VAEs, and note the H3 licence excludes the US, EU, UK and Korea. The lazy-input trick this node relies on is a modern ComfyUI feature, so if the pack loads but this node behaves oddly, update ComfyUI before anything else.