H3 · Review Windows

Here's the thing nobody tells you about long AI video: you will not like window four. Not because the model is bad, but because you can't see window four until windows one through three exist, and by then you've spent forty minutes rendering a sequence with one bad shot in the middle.

H3 · Review Windows is the node that fixes that. It's the reason this pack exists in its current shape, and it's the one node worth reading the source for, because the UI gives you almost no clue what it's doing.

What it actually does

It sits before your loop, not after it. You hand it the full window plan, the source pixels and an anchor. It then:

1. Hashes your setup - the source tensor, the anchor, the window plan, the pack's own implementation files, and a conservative fingerprint of every model/LoRA/VAE/file name and mtime in the graph. That hash is the identity of "this configuration."
2. Looks in ComfyUI/output/__h3_removal_cache/ for per-window records saved under that identity.
3. Rebuilds the accepted prefix from those records, exactly as if you'd rendered it - same frames, same audio, same boundaries - and returns it as restored_prefix.
4. Returns only the unrendered windows as pending_list, and count as the number of them.

Your Start Loop iterates count times over pending_list, and the accepted prefix feeds in as the loop's initial carry. So a reroll after a coffee break renders one window, not eleven.

It also does something clever with the source pixels: the source input is a lazy input. If a signature-matched copy of the prepared source is already cached, the node declares it doesn't need the input, and ComfyUI skips evaluating the whole upstream chain - SAM detection, video tracking, mask expansion, all of it. That's the difference between an instant reroll and waiting two minutes for a mask you already approved.

Inputs and outputs

windows is the plan. anchor is your reference/anchor image - required, and it's part of the cache identity, so changing it invalidates the render. window_controls is a JSON string (default {}) holding per-window seeds and lock state; the node fills in defaults and returns the merged version through the UI payload, so you edit it rather than author it. source is the prepared/green-masked source.

Outputs: pending_list (a real list, for the loop), restored_prefix (the assembled state of everything already accepted), count (INT, drives the native loop), windows (the pending ones bundled as H3_RELAY_WINDOWS for Window Inputs), and prepared_source - the source pixels, which you wire onward so nothing upstream re-runs.

Install

Manager → H3 Relay → restart. Manual:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/akatz-ai/h3-relay.git

No extra pip packages. It does need real disk: checkpoints and prepared source tensors live under ComfyUI/output/__h3_removal_cache/ and are not small. Save your workflow - the review identity is tied to the saved graph, which is how the pack's own validation managed a browser reroll after a ComfyUI restart that kept window one byte-identical and regenerated window two with a new seed.

Same territory caveat as everything H3: community licence, US/EU/UK/Korea excluded.

Where people get burned

Unlock at least the final window to render looks like a bug and is a safety rail: it means every window already has a record and re-running would do nothing. Unlock one and you're back in business.

The real trap is expecting this to make stochastic rerolls stable. It won't and can't - a reroll from window N rebuilds N, N+1, N+2 with fresh noise, and those will differ from the previous take in face, pose and background. The pack's own numbers say as much: two windows of character swap came out with a mean absolute difference around 1.48/255 against the legacy path even when settings were identical, and continuity is described as visually close, not numerically equal. Review early, review every boundary, and accept that "reroll window seven" means "resample everything from seven onward."

Second trap: the graph fingerprint is deliberately over-eager. Renaming a LoRA file, moving a model directory, or touching a checkpoint's mtime all invalidate your cache. It prefers redoing work to silently reusing incompatible history, which is the right call - just don't be surprised when it happens.