H3 HyperFlow P7 · Save Exact HIGH 4:8 (T8 EXP)

P7's HIGH phase is the expensive one: full-resolution diffusion over the enlarged AV latents, four steps of a 33B joint audio-video model. When it finishes, you want it on disk in a form you can trust tomorrow in a different ComfyUI process. That's all this node does - and it does it without asking you where to put anything.

What it writes

A new immutable artifact in the chain's own P7 stage store:

output/MiniMaxH3/modular_p7_stages/<chain_id>/segment_00000/

The store is deliberately separate from the older HyperFlow caches and from the generic stage store. That separation is the feature: if you migrate the old cache format, the pack can't tell your files apart from its own, so P7 keeps its own namespace and refuses to reuse anything it didn't write. Every save creates a new directory, uses an OS-level lease so two runs can't stomp each other, and commits atomically. No pickles.

It stores the completed HIGH result - the joint AV with the exact handoff and the sampler receipt attached. Not a preview, not a checkpoint in the middle of the pass.

Inputs and outputs

There's exactly one input: high_result, the typed output of Bind Completed HIGH Result or of Load Exact Completed HIGH.

Outputs: high_result and completed_av pass straight through, so you can save and keep going in the same graph - wire the pass-through into your candidate save and you don't need to branch. Then the two that matter long-term: artifact_path and artifact_sha256. Those two values are the entire input to Load Exact Completed HIGH. Save them somewhere real - a text node, a filename prefix, your notes. report_json is the manifest.

Why the SHA as a first-class output instead of letting the loader figure it out? Because the load side is fail-closed on purpose: missing file, wrong hash, truncated write, or a tensor that doesn't match the manifest all produce a hard error rather than a silent re-sample. Handing you the hash means you never have to reconstruct it.

The honest caveat

Saving freezes a result. It does not freeze the graph that produced it. If you reopen this artifact in three days with a different HIGH LoRA, or a different prompt, or a different learned upscaler, the loader will check what it can check - current parent, LOW lift, HIGH conditions, reconciled handoff - and accept or reject on that basis. But "these settings match what made this file" is not something the format claims, and the pack says so in the node description. If you need today's edited HIGH to be provably the same as yesterday's saved one, it isn't, and no amount of hashing fixes that.

Install

Manager → MiniMax H3 Audio T8, or clone it:

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

Restart ComfyUI completely and refresh the browser. requirements.txt is empty by design - this pack installs no Python packages so it can't disturb your Torch/CUDA install. Model-side, you need H3 in models/diffusion_models with its Qwen text encoder and both VAEs, the original non-pruned HyperFlow adapter in models/hyperflow/loras/, and a learned 3D latent upscaler in models/latent_upscale_models.

Practical notes

Disk usage adds up fast. Each HIGH artifact holds AV latents at full segment geometry, and a chain saves one per segment, plus candidates in a different directory. If you're iterating, delete candidate directories you've rejected rather than the stage artifacts you might still want to resume from - they're different things and only the stage files can be reloaded.

And be careful with chain ids. The store path includes <chain_id>, so two chains with the same id in the same ComfyUI install share a namespace. Unique ids per project are cheap; the error message when they collide is not.