Zura · Cache Video Prompt

Text encoding is cheap for SDXL and annoying for anything with a big language model behind it - which, in 2026, is most video models. LTX 2.5 runs a Gemma-family text encoder; MiniMax H3 uses a Qwen3-VL encoder. Loading and running those on every take is minutes you don't get back. GenjSaveTextConditioning ("Zura · Cache Video Prompt") writes the encoded conditioning to disk so GenjLoadTextConditioning can pick it up in a later job.

The pair exists because the pack splits long video work across multiple queued jobs: a preparation pass, a refinement pass, a decode. The prompt encoding survives the boundary.

The mechanism

Required inputs: positive and negative (CONDITIONING - the two outputs of your native CLIPTextEncode) and cache_key (STRING, default empty).

It recursively converts the conditioning to CPU tensors - including the H3-style nested structures - and writes output/genj/text_cache/<key>.pt atomically: a .tmp file, then a rename, so a crashed job can't leave a half-written cache behind. The key must be 64 lowercase hex characters, or you get Invalid local prompt cache key.

It returns the key as a STRING (handy for threading into the loader), and as an output node it prints "Local video prompt ready."

That's the whole node - and note what it doesn't do. There's no text encoder inside it. The pack's own comment describes it as a "thin tensor adapter": the encoding still happens in a native CLIPTextEncode node that stays visible and editable in Graph view. If you're the kind of person who likes being able to change the clip model without hunting through a packed subgraph, that design choice is a gift.

Inputs and outputs at a glance

• In: positive (CONDITIONING), negative (CONDITIONING), cache_key (STRING).
• Out: STRING - the key you pass to GenjLoadTextConditioning.
• Writes: output/genj/text_cache/<cache_key>.pt.

Install

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

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

torch.save and nothing else - no ffmpeg, no model downloads for this node. The encoders feeding it (LTX 2.5's text encoder, or H3's Qwen3-VL file) are separate multi-gigabyte downloads, listed in INSTALL_STUDIO.md.

Where people get burned

Batching a prompt change through the cache. The key is a plain string; the node doesn't know or care what prompt produced the conditioning. Regenerate the key whenever the prompt or the encoder changes, or you'll wonder why your "new" prompt produced last week's result. The pack derives keys from a hash of the recipe for this exact reason.

Clearing the cache folder mid-project. output/genj/text_cache/ is disposable by design, and the loader will rebuild from nothing - but if your multi-job queue is waiting on a key, you'll get a load failure rather than a quiet re-encode. Let the queue finish.

Sharing these files between machines. They're tied to the encoder that produced them. A cache written with one text encoder file loaded is not valid for a different one, and the failure shows up as strange conditioning rather than a clean error. The pack's own key derivation includes the encoder's size and mtime, which is the pattern to copy if you're doing this by hand.

Expecting a speedup on a five-second LTX test. On short generations the encode isn't the bottleneck; this earns its keep on repeat takes and across job boundaries, not on a one-off draft.