Prepared LTX · Load Frozen Refined Latent (T8 EXP)

Here's the scenario this node is built for. You queued a Prepared LTX run, the refinement worker did its three joint forwards and 144 blocks, you saved the result - and then the decode either crashed or you killed it. Or ComfyUI itself went down between the two halves of the pipeline.

You don't want to pay for the generation again. You don't want to trust a filename, either, because filenames lie and folders get reorganised. So this node loads the generation by its committed content hash, and refuses to start any GPU work while doing it.

What it does

Same family as the Generate node, opposite direction. It reads a committed generation receipt from disk, verifies it against the current bundle, seed and engine identity, and hands you back:

• generation_receipt - the typed T8_MODULAR_PREPARED_LTX_GENERATION value, byte-identical in role to what Generate would have produced.
• latent_path - the frozen latent on disk.
• report_json - the identity comparison, in detail.

No GPU worker is launched. No sampling. No VAE. That's the point: a fresh ComfyUI process can load the receipt and hand it straight to Prepared LTX · Decode Frozen Latent. The pack's own qualification notes describe exactly this - a cold Core that loaded a frozen generation and decoded only, while the encoder stage hit its own cache and no worker ran. Third process, all caches, zero workers.

Inputs that matter

• prepared_bundle - the same manifest Generate used. Different bundle means different identity, means the load is refused.
• noise_seed (default 8301) and chain_id (default ltx_split_trial_01) - identity fields, not knobs. Match them to the run you're reattaching to.
• expected_sha256 - this is the actual selection mechanism. Paste the hash the Generate node's report printed. Get it wrong and the node fails; it will not silently fall back to "whatever latent is sitting in that folder."

That refusal is the feature. There is no implicit cache lookup here, and no retry - the author is explicit that a load is not a claim that today's settings match the artifact. It's a claim about bytes.

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

Fully exit and restart ComfyUI, then refresh the browser tab.

The base pack installs no Python packages at all - requirements.txt is deliberately empty of real entries so it can't clobber your Torch/CUDA stack. But Prepared LTX as a route has real dependencies, and they live outside the pack: pinned upstream LTX-2, the Tao worker, and the H3→LTX latent adapter supplied from your own local directories, plus nvidia-ml-py (import pynvml) in the Prepared environment. The pack does not download or vendor any of it.

Where people get burned

Reusing a chain ID after editing anything. The docs are repetitive about this for a reason: a fresh chain_id when prompts, checkpoints, implementation or import environment change. Identical inputs plus identical chain means a verified cache read; anything else means you're asking the node to certify a mismatch, and it will decline.

Second: expecting this to work as a general resume. It resumes the Prepared LTX split specifically - Bundle → Generate → Load → Decode. It's not a checkpoint system for other H3 graphs, and it isn't a substitute for the pack's stage save/load nodes in the progressive or modular workflows.

Third: leaving the placeholder values from examples/workflows/61-prepared-ltx-split/DecodeOnly in place. Those are blanks to fill from your own receipt, and the example graphs carry the warning themselves.

If a node goes red on load, or the LTX worker fails at startup talking about missing VRAM observers, that's the pynvml dependency - the pack's docs/PREPARED_SOURCES_AND_ENVIRONMENT.md covers it and the resource observer is required to fail before launching a worker rather than reporting fake numbers.