Caching Conditioning to not Waste

If you batch-process images with one fixed prompt - colorize every photo in a folder, "restore and enhance" a stack of scans - your workflow runs the CLIP text encoder on that same prompt once per image, every time. Text encoding is fast on a big GPU and genuinely slow on a small one, and it's a classic memory hog when the text encoder is huge. caching_condition from the Caching to not Waste pack encodes the prompt once, saves the CONDITIONING tensor, and reuses it for the whole batch.

This is the pack's one genuinely clever node, because it inverts the caching key. Every other node in the pack keys on your source image; this one keys on the prompt text. That makes it perfect for the "same prompt, many images" pattern that image-edit automation produces. It's also the node people actually ask about - there's an r/comfyui thread from late 2025 asking how to cache conditioning for a repetitive Qwen-Image-Edit colorization job, and the questioner points at this pack as the reference implementation for exactly this idea.

How it works

Give it your prompt text, and it MD5-hashes that text (plus an identification string) into a filename, runs the text encoder once, and torch.saves the CONDITIONING tensor to ComfyUI/output/caching_to_not_waste. On cache hit, it loads the saved tensor back to CPU and returns it - no text encoder, no CLIP, nothing upstream of it.

Note the mechanism difference from the image-caching siblings: the key is the prompt string, not an image. Change one word of the prompt and you get a fresh cache. That's the design, and it's why this node shines for a fixed-prompt batch rather than a varied-prompt workflow.

The inputs that matter

• original_text - the prompt. This is the cache key, so it's the input that matters most.
• conditioning - a CONDITIONING input. Wire your CLIP Text Encode (or whatever text-encoder chain you're using) here.
• identification - unique name for the entry. Default "conditioning"; rename it if you cache more than one prompt, or the second overwrites the first.
• force_recreate - true once to re-encode, then back off.

Outputs: original_text (passthrough, so you can keep the prompt visible in the graph and feed it onward) and conditioning - the cached tensor, which wires straight into your sampler.

Installing it

Manager → search Caching to not Waste, or:

cd ComfyUI/custom_nodes
git clone https://github.com/alastor-666-1933/caching_to_not_waste

Restart. No dependencies beyond ComfyUI itself, no models to download.

Where people get burned

Two things, and one is easy to miss. First: conditioning tensors belong to a specific text encoder and model. If you cache with SDXL and then switch your checkpoint to something with a different text encoder (Flux, Qwen, a Pony/Illustrious variant with a different CLIP), the cached tensor may not be valid for the new model. Re-encode with force_recreate after any model swap - the prompt-hash cache won't save you from a mismatch. Second: the prompt is the key, so a tiny whitespace or wording change silently creates a new cache entry. That's fine, it just means old entries accumulate. Every so often, empty out ComfyUI/output/caching_to_not_waste to reclaim the space.