H3 Continuation · External Relay ONE Phase (T8 EXP)

There is a subtle trap in every timestamped-prompt video workflow: the model does not know what second it is. Relay plans solve that by attaching a per-query time bias at attention time, so tokens belonging to frame 40 attend to the prompt text that applies at frame 40 instead of to everything at once. That is real mechanics, not a nicer prompt string, and this node installs it.

What it does

Relay Apply takes the projected events for one phase - LOW or HIGH, your choice, since they run independently here - and binds them to that phase's actual MODEL and CONDITIONING. It needs the prepared phase, the plan, a CLIP to encode through, and the projected relay output from the window node.

The output is a patched MODEL plus positive and negative conditioning. Feed those into your sampler for that phase. Nothing crosses phases: there is no dependency on the opposite half, which is the point of the modular route. HIGH does not need LOW's conditions to exist, and vice versa.

query_chunk_rows (default 256) controls how many query rows the biased attention is processed in. If you are tight on VRAM, lower it; there is no quality setting here, just batching.

mode is the honest switch: apply_exp installs the bias, disabled returns the long-video-patched model with no routing bias, effectively a bypass. Default is apply_exp, which is the correct default for anyone who wired this node deliberately.

Inputs and outputs

• model - the phase's model. The apply step refuses if another Relay owner or wrapper is already attached: one independent continuation Relay per model, applied before stage EAV, not after.
• prepared_phase - from ONE Phase Conditions, and it must match this node's phase, its encoded prompt and its frame count.
• plan - the shared plan object. The phase is checked against it.
• clip - used to encode the compiled prompt through the relay binding.
• projected_relay - from the Relay Window node for this window. The node re-verifies it, and re-verifies that the prepared phase's encoded prompt is exactly the projected compiled_prompt.
• Outputs: model, positive, negative. In bypass mode the positive conditioning is echoed to the negative output, which is what you want for CFG1 native H3 anyway.

Wiring order

Plan → conditions (low) → Relay Window → Relay Apply → Stage EAV Apply → LOW sampler.

Relay first, EAV second. The pack is explicit about it: externally applied Relay comes before the EAV stage, and you cannot stack two owners on one model. The effect that actually ran is recorded by the audit nodes after sampling - the Apply node's own configuration is not proof that anything executed, in the same way that a settings panel is not a receipt.

Install

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

Restart ComfyUI fully - new node classes only register at import - or install via ComfyUI Manager by searching "MiniMax H3 Audio T8". The pack ships no pip dependencies by choice; optional EXP features check their own requirements when used. You need a recent ComfyUI with native H3 support and the H3 model, Qwen encoder, video VAE and audio VAE in place.

Things that will bite you

The most common error people will hit is a refusal, not a crash, and it usually means one of three things:

• The compiled prompt and the phase's encoded prompt differ. That happens when you wired the Relay Window straight into Apply and skipped sending compiled_prompt back through the phase's conditions node. Re-encode, then apply.
• The window length does not match the phase's frame count. Two phases with different length need two window nodes.
• Locked source audio plus the joint AV dialogue route. The pack documents this combination as unsupported and errors out - if you are preserving an existing soundtrack, use the video-focused routing rather than trying to have the model speak into a locked track.

One more: if you are on an attention backend with shape or bias constraints, a relay time bias can push the pack's sparse paths into a documented fallback. Running is not the same as the optimisation actually being active, and the pack keeps separate call counts to make that distinction visible. Read the report rather than the progress bar.