H3 Progressive · LOW Sampler Only (T8 EXP)

Every other sampler node you've used returns a latent you can decode. This one returns a stage boundary - a typed artifact that contains a clean model-space video latent, an audio stream that is still evolving, and the original audio noise. No VAE, no decode, no finished AV.

That's not an oversight. It's the design: the LOW pass isn't a smaller version of your video, it's half a trajectory. Handing it to a decoder would be nonsense, and the node type exists so you physically can't.

What it does

It executes the LOW half of the plan - native Euler, at the small canvas, on the front slice of the schedule - and returns the boundary plus a report. That's the whole output list: low_boundary and report_json.

The audio distinction is the thing to internalise. On this route audio is sampled jointly, not locked. So the boundary deliberately keeps two separate audio things: the evolving audio_next that the HIGH pass continues from, and the original audio noise. Video is the clean part; audio is mid-flight. That's why you can't treat the boundary as "the video so far" - and why you can't substitute it for the audio anchor later.

It also draws its own noise. Connect a Core NOISE provider and the node reads its seed and calls it, then checks that the provider didn't mutate your source latent while doing so. If you hand it something that isn't a proper noise provider with an unsigned 64-bit seed, it errors out with a message about needing a Core NOISE provider rather than pretending.

Inputs that matter

• model, sampler - from your H3 setup path for this stage. Each stage can have its own MODEL and LoRA chain, as long as architecture, latent format and AV clocks match.
• plan - the Plan + LOW Source output. It defines the split and the small canvas.
• low_source - the small-canvas source latent from that same node.
• noise - a real Core noise provider. Remember: for the original policy on the HIGH side, the video noise seed is meant to be LOW's seed plus one.
• positive / negative - conditioning prepared for the low phase.
• cfg (default 1.0) - the route runs CFG 1 with native Euler. Raising it isn't a quality dial here; it changes the guidance math the schedule was validated against.
• reserve_vram_mib (default 1024) - a boundary check before stage work, not continuous peak monitoring. It will not save you from an OOM that happens between checks.

Where it goes next

low_boundary → Boundary to External Lift Input → your learned 3D latent upscaler → HIGH Handoff
low_boundary → Save Frozen LOW Boundary        (if you want to bank it)
low_boundary → LOW Effects Execution Audit     (if you wired effects)

Note what's not wired: nothing from this node goes to a decode. If you see a workflow where a LOW boundary is handed to a VAE, someone rewired something they shouldn't have.

Install

Manager, search MiniMax H3 Audio T8. Or the clone:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Fully restart ComfyUI, refresh the browser page. No Python packages get installed - this pack's requirements.txt exists specifically so installation can't replace ComfyUI's Torch/CUDA stack - but you do need current ComfyUI with native H3 support and the model set in the right folders.

Where people get burned

Expecting a denoised output. The node description is refreshingly direct that you get typed model-space pieces rather than a completed AV or "ordinary denoised output." People who wire it expecting the usual flow spend ten minutes confused about why they can't preview anything.

Also: the docs are firm that learning-from-one-sample is a bad habit here. If you change the LOW model, LoRA, prompt, first frame, canvas or effects, the frozen boundary you saved is stale - re-run LOW. A matching SHA tells you the bytes match, not the settings.

And the memory reality: progressive sampling's claim is reduced compute at the same output size, not that it makes a 33B joint AV model comfortable on 16 GB. The pack says outright that its CUDA allocator numbers represent a default pool and shouldn't be advertised as memory savings. Treat reserve_vram_mib as a seatbelt, not a solution.