MiniMax H3 R40 · Cacheable Seed Candidate

Every long render starts with a coin flip: is this seed going to give you the shot, or is it going to make you wait an hour to find out it didn't? The R40 Shot Lab pipeline's answer is to scout first - generate several cheap, low-resolution candidates from different seeds, eyeball them, then commit the winner to the full native pass. IAMCCS_MiniMaxH3SeedCandidateR40 is the node that makes one of those scouting takes. Its job is deliberately narrow: produce one cacheable low-res seed candidate. No selection, no judgment - just a deterministic sample that later stages can reuse.

Deterministic and cacheable are the whole design. The seed isn't random; it's derived from the shot plan: (base_seed + chunk_index × chunk_stride + candidate_index × scout_stride), masked to 64 bits. Same inputs, same seed, same latent. That's what lets ComfyUI's cache skip re-sampling a candidate when you only change the winning take or the stage-2 seed downstream - the graph boundary between the candidates (upstream) and the selector (downstream) exists precisely so those expensive scout samples don't rerun.

You can have up to four of these nodes in the graph, indexed 0–3 via candidate_index. Here's the subtle bit: how many of them actually sample depends on the candidate_count setting in the shot plan's seed-scout config. If the plan only configured two candidates, nodes 3 and 4 don't burn compute - they return a copy of the input latent marked active=False, and the tagging machinery downstream knows to skip them. That "active" flag, plus the candidate index and seed, is stamped into the latent dict so the selector and decode nodes can trust it.

Inputs and outputs that matter

Inputs: model, positive conditioning, the latent to sample from, cine_linx (the framework object carrying the shot plan - this is where scout enable/count/stride settings actually live), chunk_index (from the planner), and candidate_index (0–3).

Outputs, which feed the rest of the R40 flow:

• sampled_latent - the sampled output of this candidate.
• denoised_x0 - the denoised estimate. This is the one that becomes the stage-2 starting point; stage-2 refine runs from the clean-ish prediction rather than re-noising.
• candidate_seed (INT) and active (BOOLEAN) - read the actual derived seed, and confirm whether this candidate was live.
• report - a log line telling you seed, sampler, LoRA, sparse settings and candidate 3/4 status.

Both latents carry sampled_output / denoised_x0 kind tags, which is how downstream nodes tell the two views apart.

What you need around it

This node is a cog, not a tool. By itself it does nothing useful - it needs the shot plan inside cine_linx with seed scout enabled, and it wants the rest of the R40 scaffolding (the preview, the take-selector, the decode). The intended data path is: four SeedCandidateR40 nodes → previews → IAMCCS_MiniMaxH3TakeSelectControlR40 + IAMCCS_MiniMaxH3SeedSelectR40 to pick the winner. If you're not running the IAMCCS Shotboard framework, grab the author's reference workflows from the companion comfyui-iamccs-workflows repo.

Install is the pack once:

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

or via Manager (search "IAMCCS"), then restart. You're on current ComfyUI (≥ 3.x), Python ≥ 3.12, PyTorch ≥ 2.8, with MiniMax H3 (~42 GB of weights) and its video/audio VAEs - and check the licence, which excludes the US, EU, UK and Korea. Common stumble: raising candidate_count in settings without adding candidate nodes, or vice versa. The inactive-candidate mechanism absorbs the mismatch gracefully, but you'll just be seeding fewer takes than you thought.