H3 Stage EAV · Apply to This Stage (T8 EXP)

MiniMaxH3StageEAVApplyEXPT8 attaches the Enhance-A-Video / FETA enhancement to exactly one stage. It's placed after the stage has been set up or bound - MiniMaxH3SPEEDStageSetupEXPT8, MiniMaxH3VDNStageSetupEXPT8, MiniMaxH3RFRestartStageSetupEXPT8 and the rest of the family all produce the same T8_STAGE_CONTEXT this node wants - and its model output goes into that stage's sampler.

Configuring the effect is a separate node: MiniMaxH3StageEAVConfigEXPT8 gives you the eav_config this node consumes. Keeping them apart is the point. One config can drive both stages, or you can give each stage its own.

What it needs from you

Five required inputs, and two of them are the fiddly ones:

• model - this stage's model, post-LoRA.
• sigmas - this stage's sigmas. Not the full schedule. Not the other stage's.
• av_latent - this stage's AV latent, same geometry as the sigmas.
• stage_context - from the matching setup node, for the same stage.
• eav_config - from the config node.

The author's note - "Connect matching stage SIGMAS and AV latent" - is doing a lot of work. The adapter uses those to decide when in the trajectory it is (remember, the progress window is absolute video sigma, not per-stage), so a mismatched triple doesn't crash reliably; it just applies the effect at the wrong moment or not at all. The downstream audit catches it, which brings us to the outputs:

• model - feed to the sampler (or through a Relay apply first, if you're stacking).
• runtime - a T8_STAGE_EAV_RUNTIME. Keep it. MiniMaxH3StageEAVAuditEXPT8 needs it after sampling.
• report_json - what this node bound, not what executed.

What it deliberately won't do

This is where the node earns its keep in a stack full of attention hacks. Three commitments from the author's description:

It keeps the selected backend. If the stage is running a sparse attention (VSA) path, EAV doesn't quietly swap in dense attention to make its own life easier. Native V2 sparse FETA uses bounded extra target-video projections and keeps the original kernel - meaning it costs a bit of workspace rather than replacing your acceleration.

It keeps the authenticated Relay. If you've wired MiniMaxH3SPEEDRelayApplyEXPT8 or the VDN relay adapter, the two effects compose and are tracked separately in the audit - a Relay event and a FETA call are different counters.

It won't claim what it can't see. Third-party or unknown attention producers can bypass the effect. The pack reports that as uncovered rather than silently substituting a dense path, and there's a current caveat that CUDA qualification and sparse Relay bias for native V2 sparse FETA are still pending. If you're on a fresh experimental backend, read the report before you trust the picture.

Install

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

Exit ComfyUI fully (not a soft restart), then refresh the browser tab. If you use Manager, search MiniMax H3 Audio T8; when the registry copy lags the GitHub release, install from GitHub. No extra Python packages are needed - the pack keeps requirements.txt empty specifically so a node install can never swap out ComfyUI's Torch/CUDA build. Recent core is required for the native H3 path, and H3 model / Qwen3-VL encoder / both VAEs go in models/diffusion_models, models/text_encoders and models/vae.

Gotchas

If you wire this and see no change, check mode on the config before anything else - report_only is the default and does nothing on purpose. If the audit says coverage is incomplete, an unknown producer on the attention path is bypassing the effect; that's a real limitation, not a bug you can parameter your way out of. And if your stage is LOW and your window starts at 0.15, check the arithmetic on absolute sigma before concluding the effect is broken.