FastH3 V2 · Completed LOW x0 for Learned Handoff (T8 EXP)

What it is

One job, done precisely: take a completed FastH3 V2 LOW 0:4 stage result and expose its denoised prediction, x0. Not the half-finished x_sigma, not a preview tensor - the thing the LOW pass actually finished with.

If that distinction sounds pedantic, it isn't. In an 8-step distilled schedule, the whole point of the LOW pass is to produce a clean prediction that something else can lift. Feed the wrong tensor into the learned 3D upscaler and the upscale still runs, still produces a plausible-looking latent, and quietly ruins the next stage's starting point. You get mush downstream and no error message. This node is the guard against exactly that.

How it works

It verifies the incoming T8_STAGE_RESULT is an actual completed V2 LOW stage - not a mid-run snapshot, not a differently-configured stage - and then emits low_x0 from its denoised prediction. There's no sampling here and no model load. The verification is the feature; the tensor is the output.

Two practical consequences:

1. It's the handoff point. Wire low_x0 into the pack's learned 3D latent upscaler, then into the external reconcile and HIGH 4:8 stage. That's the shape of the whole V2 pipeline, and this is the joint where LOW ends and HIGH begins.
2. It's the cold-resume point. Because it accepts an exact frozen LOW result, you can finish a HIGH-only resume without re-running LOW at all. If you're iterating on just the resolution half of a clip, this is the node that makes that cheap instead of a full re-render.

The ports

Input is a single low_stage_result (T8_STAGE_RESULT, required). Outputs are low_x0 (LATENT) and report_json (STRING).

That's the whole node, and that's fine - it's a port with a bouncer on the door. The report_json is worth actually reading once: it's how you confirm the stage it accepted was the LOW stage you think it was.

Where it fits

The V2 chain is a relay race, and this is the baton pass. Upstream: the LOW stage, sampled in a normal SamplerCustomAdvanced off the Stage Setup node. Downstream: learned 3D upscale → reconcile → HIGH prefix → HIGH stage. Skipping the upscale and feeding low_x0 straight into a HIGH stage is not the intended path, and the HIGH side is what costs you the tokens - so it's a good place to be deliberate rather than clever.

One more reason to keep it in the graph even when you don't strictly need it: the pack's attestation nodes want a provenance story they can verify. The fewer hops you take out, the fewer SHA mismatches you'll be debugging later when a candidate refuses to save.

Install

Standard for the pack - ComfyUI Manager, search MiniMax H3 Audio T8, or:

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

Fully quit and restart ComfyUI, then refresh the browser. The pack ships an empty requirements.txt on purpose, so there's nothing extra to pip-install and nothing that can stomp your Torch build. You need a recent ComfyUI with native H3 support, the H3 weights in models/diffusion_models, Qwen in models/text_encoders, and the video/audio VAEs in models/vae; the FastH3 V2 path needs the ConvRot INT8 V2 checkpoint from FastVideo.

Gotchas

The error you'll actually hit is a type complaint: the input wants a typed T8_STAGE_RESULT, so a plain LATENT from a sampler won't plug in. That's the node doing its job - the stage result carries the provenance this node needs to check, and a bare latent doesn't. If you're seeing "never unfinished x_sigma" style refusals or a mismatch about the completed stage, you're feeding it something from a different stage or a different graph than the one it was set up for.

And remember the pack's own caveat: FastH3 V2 is a distilled student. Faster, yes - their 4060 Ti test showed the whole graph dropping from ~103s to ~78s cold - but not implicitly identical in quality to a 20-step native run. Judge the output, not the step count.