H3 Progressive · LOW Effects Execution Audit (T8 EXP)

Here's the problem with attention effects in a node graph: a node that's present and connected looks exactly like a node that's present, connected, and doing nothing. You set apply_exp, you wire the config, you queue, and the result is... different? Or is it just a different seed?

Effects nodes that report their own success are useless for this. The apply node can only tell you what it intended. What you want to know is what the sampler actually did while it ran.

What it does

In: low_boundary. Out: the same low_boundary passed through, plus report_json.

That's the entire interface, and that thinness is the point. The node reads the actual immutable LOW completion evidence - the receipt the stage committed when it finished - not a counter on an apply node that some later patch could have bypassed, not a plan that says what should have happened. If the effect didn't run, or only ran for part of the window, the report says so.

Two design commitments from the node's own description, both of which are worth copying into any effects node you write:

• Missing effects never count as verified. Absence of evidence isn't a pass.
• Incomplete user-stack coverage never counts as verified either. If a third-party patch is bypassing the network path the effect rides on, that's reported as uncovered rather than quietly ignored.

You wire it after the LOW stage, anywhere the boundary is available, and read the JSON. It's a pass-through for the graph, so it drops in without rewiring anything.

When you should actually use it

Every time you change an effects configuration and care about the answer. Concretely:

low_boundary ─→ LOW Effects Execution Audit ─→ (continue to Lift Input / Save)

Run with the config in report_only first, to see what the machinery observes; then switch to apply_exp and run this audit to confirm the calls actually happened. The pack's own reporting philosophy is that callbacks, model calls and real network forwards are different counts and the progress bar conflates them - this node is you, checking.

If you're stacking attention backends (Sage variants, memory-efficient patches, sparse SolAttentionPatch), this is where the coverage question gets answered. The pack's position is that these patches may legitimately override or bypass each other, that users get to choose, and that the honest output when a wrapper swallows another is a report of insufficient coverage - not a prohibition and not a fake success.

Install

Manager, search MiniMax H3 Audio T8. Or:

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

Restart ComfyUI completely, then refresh the browser page. No Python packages get installed by this pack - requirements.txt is deliberately empty so installation can't replace your Torch/CUDA stack - and this node in particular costs nothing to run: it reads a receipt and formats it.

Where people get burned

Reading the wrong report. This node audits the LOW stage. If you applied effects to HIGH, you want the HIGH Effects Execution Audit, which reads the completed-HIGH evidence instead and deliberately does not run LOW or look at a stale apply counter. Wire both in a full run; they're cheap and they answer different questions.

Treating a clean report as a quality judgement. It isn't one. The report tells you effects executed and how much coverage they had - never whether they improved anything. The pack is emphatic that effect diagnostics are not a quality score, and that's the right frame: EAV is a bounded gain on temporal attention, and whether it helps your clip is a viewing decision.

Assuming effects fired because the video changed. Seeds, cfg, LoRA order, backend switches and stage geometry all move the picture. The audit exists precisely so you stop inferring machinery from pixels.