Nodes/comfyui-minimax-h3-audio-T8/FastH3 V2 · Load Exact Frozen LOW Recipe (T8 EXP)
ComfyUI Node

FastH3 V2 · Load Exact Frozen LOW Recipe (T8 EXP)

No LOW model, no LOW sampler, no guessing

By T8mars·Created 2 months ago·Updated about 7 hours ago· 1,158
FastH3 V2 · Load Exact Frozen LOW Recipe (T8 EXP)
  • low_stage_result
  • current_recipe
  • current_recipe_sha256
  • model_id
  • report_json
  • low_attestation
  • low_condition_receipt
  • bundle_sha256
◄artifact_path►
◄artifact_sha256►

What it is

The cold-start half of the frozen-LOW workflow. Point it at a completed LOW artifact and its bundle, hand it the same LOW stage result, and it gives you back the full provenance set - recipe, model_id, the LOW attestation and the LOW condition receipt - without loading a LOW model or running a LOW sampler.

This is the node that makes "run only the HIGH half today" an honest claim rather than a save-and-pray. The pack is emphatic elsewhere that re-running a stage is not the same as continuing it; this is the counterpart. You're not re-deriving the LOW; you're re-validating a receipt.

Equally worth reading is what it does not do: HIGH live inputs still have to be attested independently. Freezing LOW settles half the graph. The HIGH model, conditioning, sigmas and EAV config in today's run are today's problem, and the chain's later verification nodes will check them.

How it works

Three inputs: artifact_path, artifact_sha256, and low_stage_result. The first two identify the completed Stage Save manifest and pin its bytes - the SHA is not decoration, it's what stops you from loading a bundle from a manifest that has since been rewritten. The stage result is the LOW execution the bundle claims to describe.

It revalidates the bundle against that artifact, checks the bound recipe, LOW stage attestation and condition call, and returns current_recipe, current_recipe_sha256, model_id, report_json, low_attestation, low_condition_receipt and bundle_sha256.

There's a subtle piece of plumbing in the source worth knowing about: the node fingerprints the manifest and its sidecar files as inputs, so ComfyUI's cache can tell when the underlying files changed. In practice that means editing the bundle on disk invalidates the node properly instead of silently reusing a cached result - which is the behaviour you want and which you'd never notice until it bit you.

Wiring it into a HIGH-only graph

The pack's example graphs for this are the "cold HIGH" templates: no LOW UNET loader, no LOW sampler. Instead, the same LOW manifest path and SHA go into both the stage load and this bundle load, this node regenerates the provenance, and the HIGH half of the graph proceeds normally from there.

Practical consequence for your canvas: those example graphs ship with placeholder paths that must be filled in. A cold graph queued with the placeholder values won't run, and shouldn't. Also note that the node doesn't certify that today's models, LoRAs or prompts are equivalent to what you had when you froze - it certifies that the LOW you're resuming from is the LOW that was actually saved. If you've changed the HIGH side, that's a new recipe and the attestation nodes will say so.

Install

ComfyUI 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

Fully quit and restart ComfyUI, then refresh the page. No pip step: the pack keeps requirements.txt empty on purpose so installation can't replace ComfyUI's Torch/CUDA stack, and optional EXP features pull their own dependencies only when they're used. You need a recent ComfyUI with native H3 support, H3 in models/diffusion_models, Qwen in models/text_encoders, both VAEs in models/vae, and the FastH3 V2 ConvRot INT8 checkpoint for the HIGH pass.

Where it goes wrong

The refusal you'll actually see is a SHA or artifact mismatch. Causes, in order of frequency: you edited the LOW config after freezing (so the bundle describes a graph that no longer exists), you're pointing at a different manifest than the one the bundle was written against, or the manifest was re-saved by a later run. All three mean the same thing - the frozen thing and the thing you're loading are not the same thing. Re-freeze from a real completed LOW rather than trying to persuade it.

Second: the input stage result must be the matching LOW result. Handing it a HIGH stage result, or a LOW from a different segment, is a type-valid but identity-invalid mistake, and it fails at verification rather than at the widget.

Third, and the one that catches people mid-project: after loading a bundle, everything downstream still expects the HIGH side to be attested. Skipping those nodes doesn't save you work, it just moves the failure to the candidate save, where the error message is much less informative about the cause.

CategoryT8/MiniMax H3/Modular Sampling/Continuation Experimental

Inputs (3)

NameTypeDefaultDescription
artifact_pathSTRING—
artifact_sha256STRING—
low_stage_resultT8_STAGE_RESULT—

Outputs (7)

NameTypeDescription
current_recipeT8_FAST_H3_V2_CURRENT_RECIPE—
current_recipe_sha256STRING—
model_idSTRING—
report_jsonSTRING—
low_attestationT8_FAST_H3_V2_CURRENT_STAGE_ATTESTATION—
low_condition_receiptT8_FAST_H3_V2_CONDITION_RECEIPT—
bundle_sha256STRING—