MiniMax H3 HyperFlow AV Sampler (EXP/T8)

Here's the node that does the actual HyperFlow generation. MiniMaxH3HyperFlowSamplerT8Advanced binds the HyperFlow-patched MODEL and the typed 8-interval plan to T8's dual-clock Euler sampler, and hands you back the three sockets a stock SamplerCustomAdvanced expects: model, sampler, sigmas.

The important structural point, straight from the node description: your graph barely changes. This plugs into the normal SamplerCustomAdvanced alongside native H3 conditioning. The old H3 sampler and the standard 4+4 route are untouched - nobody's workflow breaks because you installed this pack.

The dual clock is the interesting bit

H3 generates video and audio in one latent, and they don't share a noise schedule. A single sigma list can't express that honestly. So the plan carries a video segment and an audio segment, each shifted on its own clock (shift_video 12.0, shift_audio 3.0), and the sampler steps both. The pack's runtime probes record that the audio side can need raw audio velocity rather than the transformed value, which is a detail the sampler handles and you don't have to.

That's also why the plan is a typed object rather than a SIGMAS output you could rewire: the sampler needs to know which interval of the trajectory it owns.

Wiring it

Three inputs:

• model - the HyperFlow-patched MODEL, i.e. straight out of the Loader
• av_latent - a native packed MiniMax H3 AV latent. The node validates 24 video channels and 32 × 2 audio channels and raises if you hand it something else
• hyperflow_plan - from the Plan node. It has to be that model's plan; the sampler matches the binding and refuses a mismatch

Three outputs plus a receipt: model (patched, onward to your guider), sampler and sigmas (both into SamplerCustomAdvanced), and report_json.

Use the ordinary BasicGuider and the normal native H3 conditioning. Don't reach for a bespoke guider; this node deliberately presents itself as a standard sampler backend.

What you're getting

8 network evaluations for a full clip, on a trajectory the plan describes. Nothing here claims to be faster than the pack's other routes - the runtime notes are explicit that the probes prove execution and file validity, not subjective quality. A 22-frame 256² probe completed 8 forwards and delivered H.264 plus 32 kHz AAC; that's an existence proof, not a benchmark. If you want a number to trust, measure it on your own card with your own resolution - the pack's own comparison notes across routes are refreshingly free of universal speed claims.

Install

ComfyUI Manager → 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

Full quit and restart, then refresh the browser. The pack's requirements.txt installs nothing deliberately - no chance of it replacing ComfyUI's Torch/CUDA. You need a recent Core with native H3 support, an unpruned H3 base in models/diffusion_models, the HyperFlow safetensors in models/hyperflow/loras, Qwen3-VL in models/text_encoders, and the video and audio VAEs in models/vae.

Where it bites

It refuses generic restarts. A partial plan passed to the public full8 node raises rather than silently sampling a half trajectory. If you want a split, use the split nodes - they're separate for a reason.

Wrong latent shape is a hard stop. The check is on the packed H3 layout. A flattened or re-shaped AV latent from an adapter node will fail here even though it "looks fine" on the canvas.

This is a two-time adapter, so don't stack a generic acceleration LoRA on top and expect the same thing. The pack tolerates things like that in some routes but declines to certify them; when the docs say an unqualified combination is on you, believe it.

Watch the first run, not the tenth. These EXP routes carry more moving parts than the stable ones, and the reports are the only place the internals are visible. Whenever output looks like a different trajectory than you asked for, compare the plan report and the sampler report before changing any settings.