Zura · Load Video Prompt

The read half of Zura's prompt cache. GenjSaveTextConditioning wrote your CLIP conditioning to output/genj/text_cache/<key>.pt; this node ("Zura · Load Video Prompt") hands it back as a normal positive/negative pair, so a second queued job can sample without loading a twelve-billion-parameter text encoder again.

What it does

It takes one required input, cache_key (STRING, default empty) - the 64-character hex string the save node returned - and returns two outputs:

• positive (CONDITIONING)
• negative (CONDITIONING)

The read is torch.load(path, map_location="cpu", weights_only=True), so the tensors land on CPU and PyTorch is restricted to loading plain data rather than executing pickle code. The pack says out loud that weights_only is the reason this is safe to do; that's the kind of thing worth preserving if you fork it.

IS_CHANGED returns the hash of the cache file, which is the correct behaviour for a file-backed loader: rewrite the file under the same key and the downstream sampler re-runs instead of serving a cached image of the old prompt.

Two conditionings in, two out - wire positive into your guider or LTXVConditioning, negative into whatever takes the negative branch. In the pack's LTX 2.5 route this replaces the text-encode branch entirely once the caching pass has run, which is why an exported refined graph can look suspiciously short compared with the preparation pass.

Why you'd bother

Because of how video generation is actually structured in this pack: preparation, refinement and decode are separate queued jobs. Without a cache, job two re-encodes the same prompt through the same model to get the same tensors. With it, job two starts at the sampler.

There's a second, subtler benefit: determinism. A cached encoding is exactly the bytes that were used in the first pass. Re-encoding "the same" prompt on a different model load is the same result in theory; a cache removes the theory.

Install

ComfyUI Manager → search Zura Nodes → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_zura_nodes/requirements.txt

Nothing to download for the node. The cached conditioning itself comes from the text encoder of whichever engine you're running - Gemma-family for LTX 2.5, Qwen3-VL for H3 - so that model has to be installed for the save half to have produced anything.

Gotchas

• Invalid local prompt cache key. - the key isn't 64 lowercase hex characters. It's a sha256-style hex digest, not a filename you get to choose.
• Wrong key, right file. There's no validation that the file matches your current model or prompt, because the key is the identity. Reuse a key across a prompt change and you'll get a perfectly clean run with the old prompt's conditioning. That's the trap this node has, and the pack avoids it by deriving keys from a recipe hash rather than letting users type them.
• Empty or missing file. A fresh install with no caching pass behind it has no .pt to read. Run the save stage once - or, in Studio, let the caching stage do its thing - before wiring the loader.
• Assuming it saves VRAM. It saves the text encoder's load and inference, not necessarily its memory: your original graph may still hold the encoder model. In the pack's routes the caching pass runs in its own job, which is where the real win is.