MiniMax H3 Continuum Decode Context

Ever done chunked MiniMax H3 continuation and seen a faint hiccup in the handful of frames right before a join? The protected prefix is bit-identical, the story continues cleanly, and yet something's off where two chunks meet - a wobble that vanishes if you decode the whole timeline in one go. MiniMax H3 Continuum Decode Context is the fix for that, and it's refreshingly surgical: it doesn't touch your sampling, your accepted latents, or your audio. It just hands the VAE a decoder window it was missing.

What it actually is

Continuum-style continuation generates a video in chunks, each new chunk starting from an exact protected copy of the previous tail. The expensive part is sampling; by the time you reach the VAE your chunk latents are accepted and done. So this node lives at the very end, immediately before Video VAE Decode and after every sampling/refinement/upscale step. It supplies real future latent context at exact chunk joins, then lets the assembly step trim the extra frames. The output is decode-only - the author is explicit that you must not feed it back into sampling, latent refinement, run storage, or continuation state.

Why the seam exists in the first place

H3's native temporal VAE (MiniMaxH3VideoVAE.decode_temporal) doesn't decode chunk by chunk the way you'd expect. It works in overlapping windows - seven latent tokens per window, striding forward five - and blends frames across window boundaries. A chunk's last frames are meant to blend with the next chunk's first window. When you decode chunks independently, that next window doesn't exist, so even bit-identical protected latents decode slightly differently at the boundary than they would in a single continuous timeline. That difference sits in roughly the five frames right before each join.

The node checks each physical join: if the protected overlap is exactly bit-equal, on the native 5/22/39-frame phase, and geometry/dtype/device all agree, it appends five real generated tokens from the following chunk onto a temporary copy of the previous one. The VAE can now evaluate the formerly missing window. Your Continuum Assemble step (keep the original assembly plan connected) trims the 17 extra decode-only frames, so the timeline length never changes.

The two inputs that matter

This node is intentionally boring to wire:

• video_latents (LATENT list) - your accepted chunk latents, in the same order the plan expects.
• assembly_plan (H3_CONTINUUM_ASSEMBLY_PLAN) - the unchanged plan from your Continuum workflow.

Outputs are video_latents (the decode-ready list) and a report string that tells you exactly what happened at each boundary - for instance 2/3 exact boundaries. Use the original assembly plan; added frames are trimmed by Assemble. A 0/N report isn't a crash: it means no boundary qualified, which is correct behavior for non-exact joins (Guide-mode chunks, or independently upscaled/refined prefixes). This node refuses to invent shared context it can't prove, and that's a feature.

Installing it

It ships in the MiniMax-H3-Flow-Aligned-Regenerate pack, from xmarre - the ComfyUI dev behind the faithful Spectrum and DiffAid research ports, who has a habit of shipping things that actually work. Install via ComfyUI Manager (search "MiniMax H3 Flow-Aligned Regenerate") or:

cd ComfyUI/custom_nodes
git clone https://github.com/xmarre/MiniMax-H3-Flow-Aligned-Regenerate.git

Then restart ComfyUI. The core pack has no mandatory Python dependencies and downloads no weights - this whole pack is training-free patches on top of H3, not a new model. You do need H3 itself running in ComfyUI and a Continuum workflow to attach it to.

Gotchas worth knowing

• It only handles native H3 video latents (the 5k+2 length form). A "latent duration differs from the assembly plan" error means your chunk list and plan disagree - check the order and that every chunk matches a physical assembly group.
• Keep the original assembly plan wired to Assemble. That's how the extra 17 frames per corrected boundary get discarded; if you feed the node's extended latents to a naive decoder you'll get a slightly longer video.
• If you still see a flash at the join after enabling this, that's a different problem: the generation-domain boundary flash, which is addressed by the suffix_dc_bridge on this pack's progressive Continuum nodes. Two separate defects, two separate fixes.

Per corrected boundary the cost is one extra seven-token VAE window and 17 discarded decoded frames - no added H3 transformer evaluations, no quality trade. If you're chasing clean chunk joins in long H3 video, this is the quiet node at the end of the graph that makes everything else look right.