IAMCCS H3 · LatentGoAhead · Native AV History

The standard way to continue a video model is to take the generated output, decode it, pick the last frame, and feed that back in as the next clip's first image. It works, and it's the reason long chains drift: every hop goes through a lossy round trip, and the frame you anchor on is the decoded result of a generation that was already approximating. Errors accumulate like photocopies.

IAMCCS_MiniMaxH3LatentGoAhead does the other thing. It keeps the previous interval's sampled AV latent and continues from that, with negative temporal coordinates, without ever re-encoding your generated video. The pack credits the concept to wan2gp-h3-latent-continue in the source comments; the implementation is its own.

This is an experimental-continuity node and it behaves like one: it writes a lot of files, it's opinionated about your settings, and it will refuse to start rather than render something broken.

Inputs

Required: model, clip, video_vae, audio_vae, cine_linx, plus four continuity knobs:

• video_context_frames - 18, 35 (default) or 52. The visible window is split between past context and newly sampled future frames, so this is how much history the model can see when it continues.
• audio_context_seconds - 0 to 2, default 1.0. The audio side of the same idea.
• freeze_tail_max_frames (default 6) and freeze_tail_threshold (0.003) - the freeze-aware tail detection, so a take that lands on a static held frame gets trimmed rather than padded.

Optional, and all delivery-side rather than generation-side: cut_plan (JSON, default {}), join_blend (none/linear/smoothstep, default smoothstep), blend_frames (default 9), audio_join (click_safe/hard_cut), audio_smoothing_ms (default 20), and the flash guard trio - flash_guard, flash_guard_sensitivity, flash_guard_radius.

The tooltip on join_blend is the important one to read: delivery-only AV overlap; original checkpoints remain untouched; each join shortens delivery by blend_frames / 24 seconds. The joins happen after the fact, on the assembled film, not inside the latent history. That separation is what makes the next paragraph make sense.

Outputs and the run folder

frames, audio, bridge, sampled_latent, fps (24) and report. It's an output node, so it also publishes its own results.

Every run creates output/IAMCCS/LatentGoAhead/<32-hex>/ holding the per-interval delivered clips, an assembled master, and provenance sidecars - including SHA-256 fingerprints of the sampled latent and of each decoded boundary frame, so you can prove which latent fed which pass. The report string ends with checkpoints=<that folder>, and that token is exactly what IAMCCS_AheadControlRoom parses to open the seam editor. Wire LatentGoAhead's report into the Control Room and you have the full workflow: render the film, then fix individual joins on the finished master without re-sampling.

Where the flash guard comes in

H3's temporal VAE works on a 17-frame cadence, and some local decoders expose a luminance spike at those internal boundaries. flash_guard at auto measures each candidate transition against neighbouring motion and repairs only a strong isolated window; all_periodic treats every boundary as suspect. The tooltip is candid that it's interpolation: can introduce ghosting; does not fix sampling. If you're seeing periodic flashes, look at your decode path before you lean on this.

Validation you'll meet immediately

The node is strict, and every check is protecting something:

• Task mode must be latent_go_ahead, and the acceleration mode must not be the Fused Fast path - that one is T2VA only, and LatentGoAhead needs FL2VA.
• Progressive sampling can't be combined with a non-zero audio context, because it can't preserve the audio history mask. Set audio context to 0 or pick Native/PDD/FastH3/SLA.
• Audio must be H3-generated. Latent history is only continued for the native track.
• Every chunk must be 17k+5 frames (H3's window rule), the canvas must satisfy the %32 < 16 condition the local patchify path needs, and every interval needs its authored opening and destination images.
• It's 24fps or it's nothing.

The cut_plan has its own guard: cuts are validated against a hash of the timeline and canvas, and if the timeline changed since the recipe was written the recipe is ignored with a logged warning rather than applied to the wrong shots.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart, and depend on the pack's H3 stack: FL2VA model, text encoder, video VAE, audio VAE, plus a Shotboard plan to feed cine_linx. This node is the heavy end of the pack - it samples long programmes, writes real files, and puts a real diagnostic burden on the log. Start with two intervals before you author twenty.