H16-3 · Load Exact Frozen Window (T8 EXP)

The pitch is simple and it's real: you froze window 2 with a save node two hours ago, and now you want to try a different prompt on windows 3 through 6. Instead of paying for windows 0-2 again, you load the frozen one and carry on.

This node reads an explicitly selected completed H16 window back off disk by exact manifest SHA, re-checks that the current source, plan and window number still line up, and hands you back the typed result the next window expects. No sampling of prior windows, no model loading, no silent regeneration.

It is not a cache

This is the thing to internalise, because the feature looks like a cache and is designed not to behave like one.

There's no lookup pass. You paste a path and a SHA-256 into two widgets - both default to empty strings - and the node reads that artifact or fails. It won't scan output/MiniMaxH3/h16_window_artifacts for something that looks close. It won't decide that today's MODEL and conditioning are close enough to a cached window, because the author considers that reasoning unsafe: a saved window is a record of what was executed, not evidence that today's edited graph reproduces it.

The verification it does perform is about identity of the contract: the plan it was sampled against, the source segment identity, the window index, the audio policy. Those have to still match, or you get an error instead of a quiet mismatch in the middle of your clip.

Inputs and outputs

You need source_segment, segment_spec, pass2_context and plan - the same live objects your window nodes consume, so the check has something to check against - plus artifact_path and artifact_sha256. Nothing else. No model socket, which is the point: loading a frozen window shouldn't pull a 30GB checkpoint into VRAM.

Outputs: cumulative_av_latent, window_result (typed, so it plugs straight into the next H16 PASS2 window's previous_result), and report_json.

That means the standard resume graph looks like: chunked source/prepare → load frozen window N → window N+1 → ... → save/audit. Everything upstream of window N can be deleted from the graph, and the docs note the shipped resume examples genuinely remove those nodes rather than leaving them muted.

What happens if you change the plan

You'll find out immediately, which is good. The plan SHA is part of the frozen window's identity, so bumping temporal_chunk_frames, changing anchor_strength, or swapping the upscaler model invalidates every saved window in the chain. The correct response is to resume from an earlier window you saved under the current plan, or re-run the chain - not to wave the load node through.

Same story for changing the source: different first-pass latent, different source identity, refusal. The one thing you can freely change downstream is everything after the loaded window - prompts, model, LoRAs, noise - because those weren't part of the frozen window's contract.

Install

Standard pack install. Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Full restart. Recent ComfyUI core (the pack tracks native H3 APIs), H3 base model, Qwen3-VL encoder, video and audio VAEs, and the learned upscaler in models/latent_upscale_models/. No extra pip installs - the empty requirements.txt is intentional so the pack can never swap out your Torch/CUDA build.

Keep the artifact where it is. Moving it is fine if your path widget follows, but renaming the file or editing the manifest is how you turn a working resume into a checksum failure. And keep the whole h16_window_artifacts tree out of any cleanup script that deletes "old outputs" - one of the more annoying ways to lose an hour.

Where people get burned

Empty strings. Both path and SHA default to blank, and the examples ship with placeholders that cannot be executed. Run the matching save first, copy the returned values, then resume.

Mixing windows. Loading window 2 and wiring its window_result into window 4 leaves a hole in the chain the previous-result check will catch - but if you also seed a bogus window in between, you've now built a clip with a non-contiguous overlap. Windows chain to their immediate neighbour. That's the whole design.

Finally, the honest scope note: resumption on tiny CPU test graphs with the real handoff logic is not the same claim as "this works on your 124-frame full-resolution run with your LoRAs". Test the resume path on one window pair before you make it your production habit.