H3RelayRemovalRestore

Video diffusion is expensive, and the single most valuable feature of a windowed workflow is not re-running the windows you already like. H3RelayRemovalRestore is how H3 Relay does that: it reads one previously rendered window back off disk - exact float frames and exact generated audio - and hands it to the chain as if it had just been sampled.

Internal node, generated automatically. You'll see it in an expanded Person Remover or Windowed Edit graph, sitting upstream of an append node with reuse_record set, instead of a whole sampler branch.

Inputs, and why they look like hashes

Three required strings, no sockets:

• cache_scope - binds the checkpoint to a specific workflow + node pair. It's a sha256 of the workflow ID and node ID, which is why it looks like nonsense.
• record_id - the individual window checkpoint, a 32-hex id written when that window was saved.
• config_key - the fingerprint of the inputs that produced it: hash of the actual source pixels and clean anchor, the prompt, steps, window size, seed scheme, source-audio hash, plus a walk of the model, CLIP and both VAE loaders including their file size and timestamps.

Outputs are IMAGE and AUDIO - the exact stored frames and waveform.

All three values are written by the frontend and by the wrapper nodes. There is no reasonable way to guess one, and you shouldn't try; if you want to force a re-render, use Reroll or Regenerate all on the parent node rather than fiddling with ids.

How the validation works

config_key equality is the gate. If the saved record was produced with different inputs - different source pixels, a different character reference, a different prompt, more steps, another LoRA - the restore raises Locked windows use different inputs or settings instead of quietly splicing an old window into a new render. The file itself is verified against a stored sha256 before loading, and the checkpoint is torch.load-ed with weights_only=True and mapped to CPU.

The same fingerprint protects the chain: a record also stores the ids of the windows before it, and the planner insists the restored set is a contiguous prefix. That's why "reroll window five" automatically rebuilds five, six and seven - nothing later may depend on something earlier that just changed.

Everything lives in ComfyUI/output/__h3_removal_cache/windows/<scope>/, as a .pt plus a small JSON manifest. Checkpoints deliberately aren't auto-deleted, so disk use grows with every reroll. The cache is not embedded in the workflow JSON - it's a local artifact on the machine that rendered it, which is the trade you're making for cheap reruns.

Practical effect

You hit Run on a nine-window removal, the server restarts at window six, and you hit Run again. Windows one through five are restored from disk without SAM tracking, without the Qwen encode, without a single sampling step. Same for a reroll of window eight: reuse one through seven, resample eight and nine.

The one caveat is what happens to your prepared masks, which live in a sibling prepared/ directory. Those are handled by H3 Relay Green Mask with its own key, and they're large - full-resolution lossless tensors. Deleting them means the next run redetects and retracks before it needs any window checkpoint.

Install

Ships with the pack: Manager → H3 Relay, or

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

ComfyUI 0.32.0 or newer, restart after cloning. No pip dependency and nothing to download for this node specifically.

What the errors mean

• Saved window is unavailable on this server. Unlock it and render again. - the manifest is gone. Usually the cache directory was deleted, pruned, or you've moved the workflow to a different machine. The node cannot re-derive this: render it fresh.
• Saved window is missing or damaged. Unlock it and render again. - the manifest survived but the .pt doesn't match its hash. Truncated write from a hard shutdown is the usual cause.
• Locked windows use different inputs or settings. - the fingerprint moved. Something upstream changed, including model file mtimes; replacing a LoRA with identically-named different weights counts. That's intentional: it's the mechanism that stops stale windows poisoning a new render.
• Window checkpoint ownership does not match / Invalid window cache scope - the scope doesn't belong to this node, or the string is malformed. Only happens with hand-edited graphs.
• Windows rendered on a different workflow id won't restore. Duplicating a workflow makes a new id and therefore a new scope; the artifacts are still on disk, but they belong to the original.