H3 · Apply History

Anybody can chain two video generations together. Take the last frame, feed it as the first frame, done - that's the last-frame chaining everyone learned on Wan, and the reason AI video still looks stapled at the joins: you're conditioning on one still image while the model invents the audio from nothing.

H3 · Apply History wires in the previous window's frames and audio instead, at H3's native sliding-history checkpoint, so the continuation is an actual continuation and not a cut with a matching background.

What it's replacing

H3 packs picture and audio into one context. Its continuation mechanism expects a history extent of 17n+1 frames and regenerates the boundary frame, which is why H3 Relay's planner overlaps windows by exactly one frame. If you hand H3 a latent with no history, it generates a fresh shot that happens to start from a similar image. Voice timbre drifts, room tone resets, camera motion restarts.

This node is the bridge between Relay's window records and MiniMax's own apply_sliding_history. It handles the part native graphs leave to you: getting the decoded history frames back through the VAE at the right extent, resampling the history audio to the audio VAE's sample rate (32 kHz by default, not the 48 kHz your source probably is), and reconciling the trim contract that MiniMax's implementation expects.

The mechanism, briefly

With history_frames at 18 or more, it calls the vendored sliding-context implementation with the history frames, your latent, both VAEs, and the previous audio. That produces a new positive conditioning embedding, an updated latent, and a trim of exactly one boundary frame - the node asserts that, and hard-errors if the upstream contract ever changes underneath it. It does not quietly carry on with a different geometry.

With history_frames of 0 or 1 - the first window, basically - it falls back to ComfyUI's own MiniMaxH3AddGuide at frame index 0, using the last of the supplied frames as an image guide. Same node, same wires, no special-casing in your graph.

Inputs and outputs

Required: positive (your reference/CLIP conditioning), latent (the latent being sampled), vae and audio_vae (both are needed - this is an AV model, not a silent one), frames (wire Window Inputs' history), history_frames (wire Window Inputs' integer output; don't type 18 by hand or a small tail window will break), and two booleans:

• first_frame_guide - adds the native frame-0 image anchor when you're not using full sliding history. Leave it on for single-window runs.
• target_audio_guide - on by default, and it strips a leftover first-anchor audio latent from the conditioning metadata, so the generated audio is conditioned on the target rather than locked to a copy of the history audio. The reference graphs turn it off for Person Removal (where the goal is to preserve the source's ambience) and on for character swap.

Optional audio is the history audio; wire Window Inputs' history_audio into it.

Two outputs: CONDITIONING and LATENT. The conditioning goes on to your guider; the latent is what the patch/mask stage consumes next.

Install

Manager → H3 Relay → restart, or clone into custom_nodes and restart. No pip dependencies are declared by the pack, but this node imports some ComfyUI internals (comfy.audio, comfy_extras.nodes_minimax_h3, and the pack's vendored context-loop code), so it needs a ComfyUI new enough to have native H3 support - 0.37.0 per the version pin. Older builds get the pack's guarded packed-layout compatibility shim, but don't plan on it as a guarantee.

Weights: H3 Ref2VA/FL2VA, the Qwen3-VL 32B encoder, video VAE and audio VAE. Both VAEs get wired here, and getting that wrong is its own flavour of confusing.

Where people get burned

History must be 0, 1, or 17n+1 frames is the error you'll hit if you typed a round number like 20. The grids are strict because H3's temporal compression is strict.

The one that actually bites in practice: audio sample-rate mismatch on continuation windows. If you're feeding history audio from a decoded MP4 the node resamples it for you - but if you feed it a silent placeholder that isn't the same length as the frames, the trim assertion fires. Wire history_audio straight from Window Inputs and leave it alone.

And a structural note: this node changes the latent's history, so if you reroll a window with a different history length, everything downstream of that window is invalid. That's why Review Windows hashes the whole plan before reusing checkpoints.