Nodes/comfyui-minimax-h3-audio-T8/H16-3 · Verified Native Resume Source (T8 EXP)
ComfyUI Node

H16-3 · Verified Native Resume Source (T8 EXP)

Start an H3 window chain from a checkpoint — but only if the SHA checks out

By T8mars·Created 2 months ago·Updated about 7 hours ago· 1,158
H16-3 · Verified Native Resume Source (T8 EXP)
  • av_latent
  • source_av_latent
  • report_json
◄resume_verified—►
◄checkpoint_id—►
◄content_sha256—►
◄file_sha256—►
◄manifest_json—►
◄report_json—►

Native AV checkpoints are the pack's way of saving an in-progress H3 generation and picking it up later. Useful, but there's a wrinkle when you then want to feed that latent into the H16 window machinery: a loaded checkpoint carries provenance that describes how it was loaded, which is not the same as evidence about the content itself. If you feed that straight into window identity checks, the identity is about the load, not the pixels.

This node exists to make that distinction explicit. It requires the checkpoint's external manifest and file SHA-256 up front, verifies them, and only then strips the volatile Load provenance so the latent can be used as an honest H16 resume source.

It never samples and never decodes

Worth stating plainly, because the node sits right at the top of a graph and looks like a loader. It doesn't run diffusion, it doesn't decode media, and it doesn't load a model. It's a gate: present credible evidence, get a latent with a clean identity; present a mismatched SHA, get an error.

The inputs are deliberately all evidence:

  • av_latent - the latent from the native checkpoint loader.
  • resume_verified - a boolean you set, asserting you've done the verification step.
  • checkpoint_id - the checkpoint's identifier, carried into the output identity.
  • content_sha256 - hash of the content.
  • file_sha256 - hash of the file on disk.
  • manifest_json - the checkpoint's external manifest.
  • report_json - the report from the load step.

Out: source_av_latent and a fresh report_json. The naming is the giveaway: it hands you a source, meaning something with a defensible identity that downstream window nodes can bind to, rather than a raw loaded latent.

Where it fits

If you're running the H16 split chain, your timeline normally starts from a completed first pass. If instead you're restoring a saved native AV checkpoint and want the window chain to treat it as the source, this node goes between the checkpoint loader and the chunked source/prepare stage. Everything downstream is unchanged: plan → one PASS2 node per window → audits and saves as usual.

The one thing it does not do is magic up trust. Pass a SHA that doesn't match the file, leave resume_verified false, or hand it a manifest that doesn't describe the latent you gave it, and it refuses. Which is the intended behaviour: the entire point of the pack's resume work is that a resume either matches the exact plan/source identity or fails loudly. Silent fallbacks are how people end up with a 124-frame clip whose middle eight seconds came from a different model.

Install

Standard for the pack - Manager → 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

Full restart. Recent ComfyUI core is required, plus H3 base model, Qwen3-VL text encoder, video and audio VAEs. The pack installs no pip packages by design. If the whole T8 category shows up red, update core, frontend and Manager together before you file anything - that combination is the usual culprit in this ecosystem generally, and the author says the same thing in the pack's own troubleshooting notes.

Also, and unrelated to the node but impossible to skip: the local H3 weights ship under the MiniMax H3 Community License, whose territory excludes the US, EU, UK and Korea. If you're in one of those regions you're not licensed to run the weights at all - the node doesn't care, but your lawyer might.

Where people get burned

Copying hashes from the wrong step. content_sha256 and file_sha256 are different values and both get checked; grabbing the file hash twice, or the manifest's own digest, will fail.

Editing the checkpoint file after saving it - renaming is harmless, re-saving it isn't. Any byte change invalidates it, and the pack would rather error than silently treat your modified checkpoint as the original.

And assuming this certifies quality. It certifies provenance of a resume source. Whether the frames coming out the other end are good is a question for your eyes, the audit reports, and a fixed seed.

CategoryT8/MiniMax H3/Modular Sampling/H16 Experimental

Inputs (7)

NameTypeDefaultDescription
av_latentLATENT—
resume_verifiedBOOLEAN—
checkpoint_idSTRING—
content_sha256STRING—
file_sha256STRING—
manifest_jsonSTRING—
report_jsonSTRING—

Outputs (2)

NameTypeDescription
source_av_latentLATENT—
report_jsonSTRING—