H3 Continuum Sampler V3.9

MiniMax H3 generates 4–15 seconds with synced stereo audio, and it's genuinely good at it. It cannot generate two minutes. So you chunk - and by hand that means feeding each clip's tail into the next and hoping the audio and the subject survive the seam. H3 Continuum Sampler V3.9 does that loop for you: N sequential chunks, continuity at every boundary, saved to disk so a long run can resume or a chunk can be swapped without redoing everything.

If you know the Wan ecosystem, this is the SCAIL-2 Infinity / Bernini Infinity idea - chunk-stitching collapsed into one node - applied to H3, with more knobs.

What V3.9 changed

Virtually nothing about generation. The V3.9 Sampler's one structural change is that the old direct Reference Image 1–3 sockets are gone: all nine reference images now arrive through a single typed Reference Images (Optional) input fed by H3 Continuum Reference Images V3.9. If you're coming from a V3.8X2 workflow, that workflow keeps its own V3.8 Sampler and loads fine - open the new V3.9 graph rather than changing the node type in an old one, because saved widget positions from older prototypes can be misread.

How it works

The node is a driver, not a model wrapper. model, clip, sampler and sigmas pass through untouched, which is why external gear - an rgthree power LoRA loader, SageAttention, a Spectrum wrapper - still applies. What Continuum owns is the loop: it derives a deterministic seed per chunk from Base Seed, samples the first chunk, then carries a bounded amount of the previous chunk's context (video frames and, if you leave Audio Continuity on, generated audio) into the next one. Continuity = Balanced - 22 frames is the validated default at that boundary size.

It emits raw latents, not pictures. video_latents and audio_latents are lists - one entry per physical group - and they normally go through Core VAE Decode (or the pack's built-in Decode Cache Helper, which is what the shipped workflow wires) and then into H3 Continuum Finalize, which assembles the groups into the exact timeline you asked for. assembly_plan is what tells Finalize how. After that it's the ordinary Create Video → Save Video chain. This node is not an output node, no matter how big it looks on your canvas.

The controls you actually set

Forget the twenty-odd widgets for a first run. These are the ones that matter:

• Chunks (1–16) and Seconds per Chunk. 5 seconds is the fast test; 8–10 usually reduces handoffs without being painful. 5–15 is the validated range, and the tooltip warns that above 15 VRAM use and time "can increase substantially."
• Size Source - First Image keeps your first frame's aspect ratio and then Resolution picks its pixel budget (Draft - 0.30 MP to test, Balanced - 0.60 MP when you care). Manual uses Width / Height exactly, both multiples of 32, and is the normal choice for text-to-video.
• Run - Full Run does the whole thing; Review Each Chunk stops after each physical group so you can accept it, retry it, or branch. Worth knowing up front: the tooltip says Review "requires Run Storage = Save + Auto Resume." Set Run Storage to that and give Run Name a stable value, or the panel has nothing to come back to.
• Base Seed. It derives the per-chunk seeds, so keep it fixed when you continue, compare takes or try to reproduce something.
• Prompt Format (Auto unless you want to force the parser) and Sequence Prompt, which takes one multiline text node for the whole sequence - a timeline like [10-20s] per chunk is the intended style.

Optional media, briefly: first_frame / last_frame for image-to-video, reference_images from the V3.9 helper, reference_video_1 for 24fps video guidance (with video_reference_mode - Repeat Reference legacy, Follow Timeline experimental), driving_audio + audio_vae when the source audio should become the output, and reference_audio_1 + reference_audio_vae when audio should only condition. Don't wire the legacy single reference audio and the audio_references bundle together; the tooltip says pick one.

Outputs: video_latents, audio_latents, assembly_plan, status, driving_audio when used, and refine_context for the Advanced Second Pass.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum.git

Manager users can search H3 Continuum instead - but don't do both to the same install. No extra pip packages; pyproject.toml declares ComfyUI >=0.32.0 while the real validation baseline is 0.34.2. Restart the backend and hard-refresh the browser, then check the console for H3 Continuum 3.9.0 loaded. Model weights, LoRAs, images and audio are not included, and the supplied V3.8X2 graph additionally expects Spectrum, rgthree and KJNodes to be installed separately.

Where people get burned

16 GB is the boundary, not the target. The pack's own nine-reference run landed at roughly 15.0–15.5 GiB of 16,311 MiB at 512×608 with three 5-second chunks. Drop to Draft - 0.30 MP, fewer references, smaller sources - and if Windows is spilling work into shared memory and everything is slow, the community's usual advice about NVIDIA's "Sysmem Fallback Policy" applies here too.

Reference Image Size is not output resolution. It controls how the reference is encoded; Size Source, Resolution, Width and Height control the canvas.

Chunks regenerate when inputs change. Run Storage resumes the longest compatible saved prefix. Change the model, the LoRA or the size and your earlier chunks no longer match - the status output reports reused vs generated, so read it instead of judging by wall time, which barely moves since decoding and saving still run.

Issue #13 is still open. Long continuations on some prompts drift toward more contrast and edge energy. There is no production mitigation in the standard path, so build shorter sequences or expect to re-roll late chunks.