H3 Audio Refine · Commit Long Context After Freeze (T8 EXP)

Long H3 video works by chaining contexts: each segment consumes a slice of what came before. The pack's Audio Refine route adds a twist - you freeze the first pass to a checkpoint, then re-run only the audio tail against it. Put those two things together and you get a real ordering hazard: if the long-video context saver writes before the frozen checkpoint is verified, your context chain now points at a video you can't reproduce.

This node is the fix, and it's about as small as a fix gets. Two inputs, one output, one boolean.

How it decides

checkpoint_status is the status string your native H3 AV checkpoint Save produced. planned_save_context is the "should I save context this segment?" boolean your long-video graph already had.

• Status is exactly SAVED_VERIFIED → save_context outputs whatever planned_save_context said. The plan is respected.
• Status is exactly NOT_SAVED → save_context outputs false. Nothing writes.
• Anything else → the node raises. Not a warning, an error.

That third branch is the interesting one. It refuses to treat an unknown state as a green light. A checkpoint in the middle of being written, a status string from a different node, an empty wire - all of them are "I don't know", and the node's position is that "I don't know" must not become a saved context.

Both inputs are force_input, which means they're sockets, not toggle widgets. You can't flip this gate by hand; you have to actually wire the checkpoint status through. In a graph where the point is provenance, a settable switch would be a hole.

Where it sits in the graph

It sits on the context-save branch of a long-video Audio Refine workflow, between the native AV checkpoint Save and whatever consumes the context. Its single save_context output is a BOOLEAN, so it goes into the boolean input of the existing context saver. Nothing else about that saver changes - the pack's design rule throughout is "append, don't replace".

If you're not running the long-video/continuation route, you don't need this node at all. For a single 124-frame clip it's dead weight; the checkpoint and the context saver aren't both in play.

For the record, the checkpoint it's reasoning about lives under output/MiniMaxH3/latent_checkpoints, and the matching loader is MiniMaxH3AudioRefineFrozenFirstPassLoadEXPT8, which insists on an explicit manifest, a whole-file SHA-256 and the checkpoint ID audio_refine_firstpass. The status string this gate wants comes from that same save path.

Getting the pack in place

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

Or search MiniMax H3 Audio T8 in Manager. Either way, quit ComfyUI completely and relaunch - this pack's nodes are registered at startup, and a hard refresh in the browser does nothing for a node you just installed. No pip step: the pack's requirements file intentionally declares no extra packages, because pulling in anything that touches Torch or CUDA here risks replacing ComfyUI's own stack. Take the README's warning seriously about not running the bundled example workflows until you've swapped in your own model paths and media.

Practical gotchas

• Wiring a homemade string. checkpoint_status is meant to be an output, not typed text. "SAVED_VERIFIED" written by hand will pass, and will also defeat the entire node. Use the save node's status output.
• Reading it as a validation of your video. It validates ordering, not quality. The checkpoint being saved and verified says nothing about whether your refined audio is good.
• Expecting "NOT_SAVED" to error. It doesn't; it silently returns false, which is the correct conservative behaviour for a resume graph that hasn't resumed yet.
• Two copies of this pack installed. It has happened to users of this repo before - an old test copy can shadow the real module and throw errors from code that isn't even in your install. Keep exactly one copy in custom_nodes.