H3 VDN · External Prompt Relay Audit (T8 EXP)

The VDN relay extension adds temporal bias to a distilled model's window attention and experimental text seeding to its linear scan. On an eight-step DMD route, a gain that isn't applied and a gain that is applied look remarkably similar in the output - you're working with very few forwards and a very short trajectory.

MiniMaxH3VDNRelayAuditEXPT8 is the answer to "did it fire". Wire it after the stage's sampler or save, give it the av_latent and the runtime that came out of MiniMaxH3VDNRelayApplyEXPT8, and read the report.

What it counts

The node's whole reason for existing is stated in its own description: it reports real window/linear calls and coverage, not just the presence of a Relay plan. That distinction is the difference between a plan that was built and a plan that ran through the attention path.

The report carries the stage context, the config, the binding hash that ties this runtime to the model it was prepared for, the expected versus installed and completed block counts, a neutral-block count, per-block stats, and the linear profile. The status line resolves to one of:

• observed_apply_exp - blocks ran through the extension for real.
• observed_neutral - it ran, but everything came out neutral. That's usually a prompt with no usable timing events, or a stage where the bias has nothing to attach to.
• disabled_identity - you ran with mode="disabled", so this is the bypass, recorded as such.
• unverified_incomplete_coverage - some blocks didn't get covered. Treat the run as unverified.
• aborted - it stopped partway; the report keeps that rather than pretending otherwise.

There's also a boundary string attached, and it says something worth internalising: unknown bypassed producers remain unverified. If some other node intercepts the attention path, this audit can't see behind it, and it says so instead of reporting an all-clear.

Outputs: av_latent passed through, and report_json.

Why it isn't the same node as the EAV audit

Because the mechanisms are different and so are the counters. EAV fires on attention energy during a sigma window; the VDN relay fires a temporal logit bias and a text-seeding term in the linear scan. The pack keeps the two audits separate, and it also keeps them honest about each other: the coverage check for one will flag if a Relay was required but didn't cover every attention call. If you stack both effects on one stage, read both reports.

Install

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. Manager search: MiniMax H3 Audio T8. The pack installs no Python dependencies at all - requirements.txt is intentionally empty so the install can't replace ComfyUI's Torch/CUDA stack - but it does require a recent ComfyUI core with native H3 support.

You need the OpenVDN model bundle in place too (t8star/Vdn-Minimax-H3-Comfy), since the audit is only meaningful when a real VDN stage ran behind it.

Gotchas

Both inputs are required and the runtime has to be from the same stage's apply node. Reuse a runtime from a previous stage and you'll get coverage numbers that look plausible and describe a run that isn't the one on your screen - the binding hash in the report is how you check.

Don't read observed_neutral as an error: it means the extension was installed and evaluated to no-op. If you expected an effect and got neutral, look at the prompt relay plan's events before you look at the node.

And treat the audit as what it is - evidence that calls happened. There's no quality claim attached to a green status, which the pack is refreshingly upfront about across every one of these nodes.