H3 SPEED · External Relay for ONE Stage (T8 EXP)

The T8 pack's Prompt Relay system lets you point a prompt at specific parts of an H3 generation - this shot, this reference, this time range - instead of one blob of text describing the whole clip. MiniMaxH3SPEEDRelayApplyEXPT8 is the per-stage adapter: it takes an external Relay plan and a SPEED stage's exact canvas, re-encodes the text at that canvas, checks the rebuilt AV target against what Stage Setup prepared, and hands you back a MODEL and CONDITIONING pair.

Read the default before you read anything else: execution_mode is report_only. Wired and left alone, this node will tell you what a Relay would do and apply none of it. That's deliberate - the whole family defaults to observation so a mis-wired graph can't quietly change your generation. Switch to apply_exp when you actually want the relay events to fire.

Inputs and outputs

• model - this stage's model, after your LoRA chain.
• stage_spec - the T8_SPEED_STAGE_SPEC from MiniMaxH3SPEEDStageSetupEXPT8 for this same stage. This is the contract: it's how the node knows what canvas and audio layout it's supposed to produce.
• speed_source - the H3_T8_SPEED_SOURCE built by the Advanced "SPEED Stage Source" node. It carries the per-stage conditioning source.
• prompt_relay_plan - the H3_T8_PROMPT_RELAY_PLAN from the pack's Relay Builder side. Planning and execution are separate nodes here, so you build the plan once and reuse it across stages.
• execution_mode - report_only (default) or apply_exp.
• query_chunk_rows (default 256, 32–2048) - a memory bound on the query-side chunking. Lower it if the encode is what's spiking.

Outputs: model and positive (wire both into that stage's sampler, or into MiniMaxH3StageEAVApplyEXPT8 first if you're stacking effects), av_latent, mux_audio, conditioned_prompt (the actual text as it resolved - genuinely useful for debugging why a shot ignored you), media_map_json, and report_json.

The trap: this node is not proof

The author's description says it outright - this node alone is not effect execution proof. An applied-by-configuration and an applied-in-reality Relay look identical on the canvas. The evidence is downstream: run the stage, then read the actual-call audit. In the SPEED family that's what report_json from the sampler plus your own eyeballs on the audit coverage means; the pack is consistent about never certifying quality from a wiring diagram.

There's also a hard interaction nuance: an authenticated Relay can coexist with Stage EAV, and the documented order is Relay first, then the stage's EAV apply. The two are tracked separately in the audit, because they're different mechanisms on different parts of the attention path.

Install

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

Fully restart ComfyUI afterwards, then refresh the browser tab. In Manager, search MiniMax H3 Audio T8; if it shows an older revision than the GitHub release, install from GitHub - the registry and the repo publish independently. No pip install step exists by design; the pack's requirements.txt is empty so it can't clobber ComfyUI's Torch/CUDA stack. Recent ComfyUI core is mandatory, since the nodes build on native H3 support.

Gotchas

If the Relay reports that it re-encoded at a canvas different from Stage Setup's, you've crossed the specs from two stages - a very easy mistake when you've got 82 example graphs open. If your prompts seem to be ignored entirely, check execution_mode first; the default is not an accident. And if you're mixing this with an external attention override (Sol, Sage, SLA), read the pack's patch-stack policy: Relay is preserved and delegated where it can be, but simultaneous acceleration is not promised.