CachingCLIPTextEncode|ARZUMATA

Every render runs your prompt through a text encoder before sampling starts. For SD 1.5 and SDXL that pass is quick enough that nobody thinks about it - which is exactly why this node, CachingCLIPTextEncode|ARZUMATA, exists for the cases where it isn't quick, and for workflows that waste time re-encoding the same words over and over. It's a drop-in replacement for the stock CLIPTextEncode that remembers what it already encoded.

The idea is simple and it's the kind of thing you've probably wished for while staring at a queue of twenty renders that only differ by seed: encode the prompt once, cache the CONDITIONING, and on every subsequent run where the text (and the CLIP model) are unchanged, hand back the cached result instead of running the encoder again. That's the entire feature, and it's honestly the right scope.

The inputs and outputs

• text - your prompt, multiline, the same field you already use.
• clip - the CLIP model, wired from your checkpoint or dualCLIP loader.
• cache_limit - how many distinct text+model combos to remember, from 1 to 100, default 10. Hit the limit and the oldest entry gets evicted.

One output: CONDITIONING, identical in type to stock CLIPTextEncode, so it plugs straight into the same sampler or conditioning combine. No workflow surgery required to try it.

How the caching works

The mechanism is hashing with a twist. It computes a SHA-256 of your text plus the memory address of the CLIP model object, so switching the CLIP model invalidates the match (and, per the README, keeps the old model's entries around - switch back and the cache is still warm). On a miss it tokenizes and encodes the normal way and stores the result. It's the same approach as discus0434's comfyui-caching-embeddings, which the author credits as inspiration.

A few honest notes on when this actually pays for itself. The cache lives in memory for the ComfyUI session - it's not persistent across restarts, and the "limit" keeps it from eating RAM, but 10 entries of conditioning are nothing. And here's the thing: on SD 1.5/SDXL the encode is fast enough that you might save milliseconds. The real win is the Flux sibling (CachingCLIPTextEncodeFlux), because T5-XXL is a proper language model and encoding it costs real seconds. This node is the simplified version: single text input, no guidance value, same hashing. It's the one you use when you're on SDXL with a fixed prompt and a long batch queue and you'd rather ComfyUI not redo work it already did.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/ARZUMATA/ComfyUI-ARZUMATA

Restart ComfyUI, or search ComfyUI-ARZUMATA in ComfyUI Manager. No extra dependencies, no models to download.

Gotchas

• The cache is per-node-instance. Duplicate the node in a workflow and each copy caches independently. That's usually what you want, but it means cache memory scales with node count.
• Dynamic prompts still work (the text field has dynamicPrompts enabled), but each generated variation is its own cache entry - a wildcard-heavy prompt will churn through the limit fast. Raise cache_limit if you see the cache thrashing.
• It's a small personal pack. If your prompt genuinely changes every render, this node does nothing for you except add a hashing step that's cheaper than the encode - harmless, but not a fix.

Worth a try in any workflow where the prompt is static and the queue is long. Worst case it's a wash; best case it shaves a visible chunk off every render.