H3 · Load Continuation History

Long-form video is usually one giant render you're afraid to touch, because touching it means starting over. H3 · Load Continuation History is the node that breaks that assumption: it reads a saved set of frames back as an IMAGE batch so a new graph can continue from a shot you already accepted.

It's one input, one output, and a pile of validation - which is the right shape for a node whose entire job is "trust me, these frames are the boundary."

Why it exists

The pack separates native H3 continuation state from finishing state, and it keeps both on disk rather than in RAM. That's what makes the segment workflow possible: render ten seconds, accept it, save the continuation master, and come back tomorrow with a graph that starts from those frames instead of re-running the diffusion that made them.

There's a second, subtler use. Chained generation across sessions is where people lose track of identity drift - the last-frame-chaining habit that got the community its 30-second Wan clips, with a slow smear of the subject's face at every join (our Wan notes cover that history). If your history extent is fixed and validated, you at least know exactly what context the next window is continuing from, rather than discovering at frame 300 that the protagonist has become someone else.

How it works

It reads an .npz archive from ComfyUI's input directory - file name relative, traversal refused - and pulls the frames array out as float32.

Then it argues with you, in the good way:

• Frame count must be 1 or 17n+1 (18, 35, 52 …). Those are H3's legal history extents, and a history of 20 isn't "close enough," it's a different relationship between video and audio tokens.
• Dimensions must be divisible by 32 on both axes. History has to sit on the same DiT grid as the canvas it continues.
• Values must be finite and in 0–1, with three channels. So no 16-bit-integer arrays smuggled in, no alpha channel.

Its change detection hashes the file on disk, so editing the archive properly invalidates anything downstream rather than replaying a cached render built from different frames.

Using it

Wire IMAGE into one of two places, depending on what you're doing:

• H3 · Plan Windows' initial_history - and you must also switch the schedule to segment, because the planner refuses external history under adaptive. This is the path where the supplied history is excluded from delivery: the planner marks it, and Finish Windows slices it off the front.
• H3 · Window Inputs' initial_history - for feeding the carry socket's first iteration directly, usually alongside initial_history_audio.

Practical rule: the planned history extent in your window settings has to be at least as long as what you loaded, and the frames have to sit on the exact source boundary. The node can't check that for you - it doesn't know your timeline - but Window Inputs will, and its error names the boundary problem explicitly.

Install

Manager → H3 Relay → restart, or:

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

Needs numpy (undeclared by the pack, nearly always present) and ComfyUI 0.37.0+. No GPU, no ffmpeg, no models - this node just parses a file. The file itself is the hard part, and the intended source is H3 · Save Continuation Master, which writes the 16-bit FFV1 master. Note that node writes .mkv, so if you're loading .npz, your frames came from somewhere else - the pack's app, or your own export.

Where people get burned

History must contain 1 or 17n+1 RGB frames is the first wall, and it catches people who saved a nice round 20 frames. Save 18, or 35, or 1.

History requires a finite, 32-pixel-aligned canvas means the frames were cropped after saving, or came from a source whose dimensions never got onto the grid. There's no silent resize here on purpose: rescaling history would put a slightly-soft boundary frame into the model's context and you'd never know why the join looked mushy.

And the biggest expectation gap: a loaded history does not make your graph continue - it makes your next window continue from those frames. Everything else about the shot (prompt, references, LoRA, resolution) still has to match, or you'll get a well-formed continuation of a shot that no longer looks like the one you saved.