WanVideo TextEncode Cached

Wan's text encoder is a chunky umT5 model, and on a card that's already sweating to hold the 14B diffusion weights, keeping that encoder resident in VRAM the whole time is a waste of memory you don't have. This node fixes exactly that. It encodes your prompt into embeddings, then completely unloads the T5 - the node's own description puts it plainly: it leaves "no VRAM or RAM imprint." And here's the good part: if you've already encoded these exact prompts before, it pulls them from cache and doesn't load the T5 at all. Second run onward, prompt encoding is basically free.

That's the whole pitch, and it's a good one for the VRAM-constrained crowd that runs Wan locally. If you're on a 12-16GB card following the community's usual advice, every gigabyte you claw back from the encoder is a gigabyte the sampler gets to use.

How it works

You give it your positive and negative text, it spins up the T5, encodes, hands you the embeddings, and evicts the encoder. The use_disk_cache flag (on by default) is the "Cached" in the name - encoded prompts get written to disk, so re-running an unchanged prompt skips the encoder entirely. There's also an optional Qwen LLM prompt-extender path: feed extender_args and it'll expand your positive prompt using one of the original Wan templates or your own system prompt, which is handy because Wan responds well to longer, descriptive motion prompts (the community rule is "for i2v you are George R.R. Martin").

The inputs and outputs that matter

• positive_prompt / negative_prompt - your text, both multiline. The negative is worth encoding even on the fast path (see below).
• quantization (disabled / fp8_e4m3fn) - quantize the encoder to fp8 to shave more memory. precision (bf16 default / fp32) is the base dtype.
• use_disk_cache (default true) - leave it on; it's the reason this node exists.
• device (gpu / cpu) - run the encode on CPU if you'd rather keep the GPU fully free.

Three outputs: text_embeds (wire into your sampler's text_embeds), negative_text_embeds, and positive_prompt (the string, possibly extended). That middle output is the interesting one - per the node, negative_text_embeds "is meant to be used with NAG, it contains only negative prompt embeddings." If you're running a speed LoRA at CFG 1 where normal negatives are dead, this is the negative you feed into a NAG node to get negative control back.

How to install it

ComfyUI Manager - open the Manager, search ComfyUI-WanVideoWrapper, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper
pip install -r ComfyUI-WanVideoWrapper/requirements.txt

then restart. You also need the text encoder file itself - the umT5-xxl encoder Kijai hosts on the Kijai/WanVideo_comfy HuggingFace repo - dropped into ComfyUI/models/text_encoders so it shows up in model_name.

Common issues & troubleshooting

model_name is empty. The dropdown reads from ComfyUI/models/text_encoders. If there's nothing there, download the Wan umT5 encoder and restart ComfyUI so it re-scans the folder.

First run is slow, later runs instant - then a change makes it slow again. That's the disk cache working correctly. Any edit to the prompt text (or precision/quantization) is a cache miss and reloads the T5. The cache folder also grows over time; it's just files on disk, clear it if it bloats.

Your negative prompt does nothing. If you're stacking a lightx2v/CausVid speed LoRA, CFG is pinned at 1.0 and there's no classifier-free guidance for the negative to act through - that's a Wan-wide gotcha, not this node. Route negative_text_embeds through a NAG node to get it back.