H3 Stage EAV · Actual Calls Audit (T8 EXP)

Every serious ComfyUI workflow eventually has the moment where you wire an effect, run the job, and have no idea whether it did anything. On a distilled model where CFG is 1 and the sampler is doing four NFE, "did my attention tweak fire?" is not answerable by looking at the output.

MiniMaxH3StageEAVAuditEXPT8 answers it. Wire it after the stage's sampler, hand it the runtime that came out of MiniMaxH3StageEAVApplyEXPT8, and pass av_latent through. It comes back with av_latent, report_json, and a text dump in the UI.

Why it exists separately from Apply

Apply can only tell you what it bound. Whether the bind survived into an actual sampling call depends on the sampler you used, the backend it dispatched to, and whether some other attention override intercepted the path. So the audit reads the immutable call record from the completed stage - not a mutable counter on the Apply node, which as the docs point out could otherwise let you guess that sampling succeeded.

That's why the node is registered as an output node and prints rather than silently passing JSON along: it's meant to be read. The report includes the actual absolute sigmas observed, the planned versus completed forwards, the forward plan, selector calls, sparse producer calls, Relay attention calls, whether a Relay was required but didn't cover every attention call, and the FETA result.

The status field is the one-line answer:

• observed_apply_exp - the effect really ran with gain applied.
• observed_report_only - it ran in observation mode; your config is report_only, so nothing was applied.
• disabled_identity / bypass - nothing was installed.
• observed_no_steps_in_effect_window - the wiring is fine, your progress window doesn't intersect the stage's real sigmas.
• unverified_incomplete_feta_coverage or unverified_relay_coverage - something on the attention path bypassed the effect. Treat the run as unverified.
• unverified_incomplete_coverage for producer-level gaps.

Two fields are hard-coded false and worth noticing: quality_accepted and cache_reuse_authorized. The pack is explicit that this node makes no GPU-quality claim and doesn't authorise treating the result as a persistent cache. An audit says "this call happened", not "this looks good".

Install

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

Fully restart ComfyUI and refresh the frontend. Manager search: MiniMax H3 Audio T8. Nothing to install dependency-wise - the pack's requirements.txt is empty by design so it can't replace ComfyUI's Torch/CUDA stack - but you need a recent ComfyUI core for native H3 and the newer node API, or the nodes render red.

Gotchas

Both av_latent and runtime are required, and runtime must be the one from the same stage's apply node; if you splice in a stale runtime from a previous stage, the coverage numbers describe a stage you didn't run. This is a debugging tool, so it's also the node that catches the classic EAV misunderstanding - an absolute progress window of 0.15–0.90 that never overlaps your later stage's sigmas. The audit says so in plain language; you don't have to reason it out.

Last thing: it reports, it doesn't fix. If coverage is incomplete because a third-party attention backend is in the way, the honest options are to remove that backend or accept that the effect is partial. The pack's policy is to preserve unknown patches and tell you the truth about them rather than to silently swap in a dense path that would change your memory profile.