H3 Progressive · External Relay + ONE Stage Conditioning (T8 EXP)

Prompt Relay is the reason H3 videos can have a script instead of a vibe: instead of one global text block, you give the model a timeline of local events, and the relay adds real temporal bias to the keys so event four actually lands at second four. It's one of the more convincing tricks in the pack, and it's also the one with the most ways to be silently misconfigured.

Split it across a two-stage progressive graph and you multiply those ways. This node is the adapter that keeps the pairing honest.

What it does

Take your Relay-bound MODEL - the one carrying your paired Relay conditioning - your positive and negative conditioning, and the progressive plan. Pick a phase. You get back a model, plus positive and negative conditioning, all rebound for that stage's actual packed layout.

Under the hood it's rebinding dimensions, not resampling: LOW and HIGH have different spatial grids and therefore different packed token layouts, and the Relay conditioning has to be prepared against the layout of the stage that will consume it. It prepares the stage guides at the same time. No sampling happens here, and no model is called - the earlier Relay conditioning node already did that work.

It reuses the same phase and guide_resize controls as the plain conditioning node, plus a mode:

• mode - apply_exp actually applies the relay; disabled removes only the authenticated Relay owner for that phase. Useful when you want relay on HIGH only, or on neither, without rewiring.
• guide_resize - legacy_bilinear or preserve_mean, same semantics as everywhere else in this family.

Use it instead of ONE Stage Conditioning

This is the note that matters most, and it's in the node's own description: use this instead of ONE Stage Conditioning, not after it. You're either on the Relay path, where the MODEL carries bound Relay provenance and the conditioning has to be prepared as a pair, or you're on the plain path. Stacking a plain conditioning-prep node after this one breaks the pairing it just established.

Practically, that means your LOW and HIGH each get their own Relay Stage Apply with their own phase and their own prompt. HIGH can run a different Relay plan, or be the only phase with Relay enabled at all - that's supported, and it's a nice way to keep the expensive full-resolution pass on a cleaner schedule while the small pass does the composition.

Install

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

Restart ComfyUI fully and refresh the page. The pack installs no Python dependencies by design - requirements.txt won't touch your Torch/CUDA - so a failed install is almost always a stale process rather than a missing package.

You need the usual H3 furniture: a recent ComfyUI with native H3 support, the H3 weights in models/diffusion_models, Qwen text encoder in models/text_encoders, VAEs in models/vae, and the learned latent upscaler in models/latent_upscale_models/ if you intend to actually lift the LOW boundary.

Where people get burned

Mismatched plans. Different scripts or timelines bound to LOW and HIGH are rejected - that's deliberate - and the node checks the original target canvas before building the paired hash.

Trusting the progress bar. The pack's reports distinguish model forwards from actually relay-routed attention calls, on purpose. If a third-party attention patch bypasses the main network routing, the honest outcome is a report saying coverage is incomplete and unverified - not a green tick. Read the report_json on the first run of any new combination; it takes thirty seconds and it's the difference between "Relay is on" and "Relay claims to be on."

And the general engineering note that shows up all over this family: only the spatial grid changes. Local event timing, text token ranges and the audio time coordinates stay where they were, which is exactly why a relay plan survives the low/high split at all. If your events land late in the HIGH pass, look at your plan's coverage length - the pack's guidance is that a plan has to cover the frames you actually output, and changing duration means re-checking it.

Starting point: examples/workflows/44-progressive-split/, which ships the LOW/HIGH/combined effect variants as separate editable graphs so you can see the pairing before you build your own.