MiniMax H3 Pending Review

Review Gate is great until you want to sleep. By default it pauses the graph and waits for a human - which means a live ComfyUI execution sitting there holding state while you're not at the keyboard, and no clean way to walk off and come back. Plug Pending Review into the Gate and the batch renders, saves and stops.

What it actually does

It's a one-widget node whose only job is to hand Review Gate a disposition. With defer_completed_batch on, the Gate generates the complete candidate batch, checkpoints every take, writes a small record under pending_reviews/, and ends the execution cleanly instead of waiting. The takes exist on disk; nothing is left running for you to come back to.

Two consequences worth knowing before you wire it up. It overrides a disabled Gate and per-candidate inspection, because there's nobody available to make those calls mid-batch. And the media isn't duplicated: the pending batch points at the same checkpoints the loop would have produced anyway.

Going the other way is deliberate, not incidental. The instant you connect Pending Review, the Gate stops being a live gate, so anything that depends on waking a waiting job - the Review Gate Relay in particular - has nothing to talk to. The pack's relay docs say this outright: after a ComfyUI restart, or after a batch was saved with Pending Review, "there is no live execution to wake."

Inputs and outputs

• defer_completed_batch (BOOLEAN, default true) - on defers the batch; off leaves the Gate's normal live wait in place. Wire it to a boolean switch if you want both modes in one workflow.
• pending_review (H3_REVIEW_DISPOSITION) - the single output. Connect it to Review Gate's optional pending_review input. That's the entire graph change.

How you actually review it later

Load the run back up and open the Plan or Project Asset Carousel, then in Review Gate use Pending candidate reviews → Refresh, pick the batch and hit Review. Browsing takes works like a normal gate, and Use this take & prepare resume promotes that take's exact checkpoint lineage, keeps the alternatives you checked, deletes the unkept ones, and arms Loop Start for the following scene. That lineage detail is the whole point - the active take's saved frames and AV tensors become the continuity for the next scene, not whatever rendered last.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/seitanism/ComfyUI-H3-Motion-Context-MultiRef.git
git clone --branch main https://github.com/ethanfel/ComfyUI-MiniMaxH3-Context-Loop.git

Restart ComfyUI after cloning. ComfyUI Manager finds the same pack as MiniMax H3 Context Loop. Weights aren't included; keep ffmpeg on PATH for the review and assembly path. If you're in the US, EU, UK or South Korea, remember the H3 community licence doesn't grant you rights to the local weights in those territories.

Where people get burned

The failure mode is expectation, not code. People set up a Pending Review batch, then try to attach a Relay or refresh the browser expecting to approve a running job - and there is nothing running. The takes are safe; the live decision-making is gone. You resume through the pending-review browser or checkpoint recovery, not through the Gate you left open in a tab.

Second: candidate count still governs how many takes get generated and checkpointed before the stop, and there's a hard safety cap of 20 per scene. A batch of 20 at a few minutes per take is a fine overnight job and a bad "quick test" - start with a couple.

Third, the boring one: this is a review deferral, not a memory optimisation. It stops the execution and prevents the RAM/VRAM a waiting Gate would pin, but it doesn't make the sampled scenes any smaller, and it doesn't change what gets saved. If your problem is the render itself, this node isn't the lever.