H3 Continuation · HIGH Sampler Only (T8 EXP)
The second half of the segment, with its own model and its own prompts
- prepared_phase
- high_restart
- model
- sampler
- positive
- negative
- av_latent
- report_json
- high_result
Every "why is my long H3 video two different videos" complaint has the same shape: the second half was generated with different prompts, a different LoRA, or a reset audio clock. H3 generates picture and sound together, so a hard reset in either stream is audible as well as visible. This node's entire job is to finish a segment on the same clocks while letting you change the knobs that should legitimately differ.
What it runs
Only the high-resolution tail: the back half of the native Euler schedule, at final canvas, with CFG1 and the accepted parent's motion guides. It does not run the low pass, does not lift anything, does not loop, and does not accept its own output into a chain. You get a candidate. Accepting, saving and appending are separate nodes in this pack, and that separation is a feature - you can look at a bad segment and throw it away without polluting the chain.
It takes the typed high_restart from the handoff node, which means the schedules, masks, noise and geometry are already settled. What you supply is the sampling environment: model, sampler, positive and negative conditioning, a seed, and a VRAM reserve.
The seed here is the sampler seed, not the high-resolution video-noise seed from the handoff. That distinction bites people. The original policy is that the sampler seed matches the LOW stage's, while the video renoise uses LOW seed + 1; the two numbers are related but they are not the same number, and they live on different nodes.
Inputs that matter
prepared_phase- the HIGH phase object. Hand it a LOW phase and it errors, which is the friendly version of this mistake.high_restart- from HIGH Handoff Only. This is the object that carries the frozen prefix and the tail schedule.model,sampler- HIGH's own. A cheaper low pass plus a heavier high pass is a legitimate reason to run this route in the first place.positive,negative- HIGH's own conditions. The plan node is explicitly independent of HIGH prompts, so you can describe the continuation differently from the low pass. And it is the low pass that is cheap; the high pass is where a mismatched prompt costs you.seed- default 1234, which will only match your LOW stage if you make it. For the original policy, set it to the same seed you fed the LOW sampler.reserve_vram_mib- default 1024, a free-VRAM check at the stage boundary. Not a card limit, and per the pack's own docs, not an OOM guarantee.
Outputs: av_latent, the finished window you decode; high_result, the typed result that goes into "Deliver Completed Window" for validation and delivery, and which can also be saved and reloaded without re-running VAE prep or either sampler; and report_json with the actual calls and clocks.
Wiring
Handoff → HIGH Stage → native AV decode, and high_result → Deliver Completed Window.
If you want the audio to be a source track rather than the generated one, that decision happens at delivery, not here. The pack is consistent about this: internally generated sound is the default, and an explicitly selected PCM is preserved - so if your graph feeds an explicit source track into the delivery path, expect to hear that track instead of the model's dialogue.
Installing it
cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8
Then quit ComfyUI completely and start it again; new node classes only appear after a real restart. Manager search is "MiniMax H3 Audio T8". The pack installs no pip packages on purpose, so it cannot clobber ComfyUI's Torch/CUDA stack, but you do need a recent Core with H3 support plus the H3 checkpoint, Qwen encoder and both VAEs.
Things that will bite you
The pack's own release notes repeat one caveat often enough that it is worth adopting: connect a workflow and it runs is not the same as validated for your material. The acceptance evidence behind these continuation nodes covers specific samples and configurations - a two-segment 8-second test is not a promise about a 24- or 32-second chain, and there is a documented, still-present colour shift at the seam.
Practical order of investigation when a segment looks wrong: check the seed pairing before the LoRA, check that prompt changes live on HIGH's conditions rather than on the shared plan, and only then look at the upscaler. Nine times out of ten the sampler is fine and one of those three numbers drifted.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| prepared_phase | T8_CONTINUATION_PREPARED_PHASE | — | |
| high_restart | T8_PROGRESSIVE_HIGH_RESTART | — | |
| model | MODEL | — | |
| sampler | SAMPLER | — | |
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| seed | INT | 12340–18446744073709550000 | — |
| reserve_vram_mib | INT | 1024512–65536 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| av_latent | LATENT | — |
| report_json | STRING | — |
| high_result | T8_PROGRESSIVE_HIGH_RESULT | — |