CLIP Text Encode with Caching

This one does exactly what it says on the tin, no more and no less: it's CLIPTextEncode, the node that turns your prompt into conditioning, with a cache bolted on so it doesn't redo that work when it doesn't have to. The whole pack is one node. The README is four lines long. That's not a knock - it's a sign the author knew exactly what problem they were solving and stopped there.

Why this exists

Every prompt you type gets run through a text encoder - CLIP on older models, an LLM encoder like Qwen3 on newer ones - before the diffusion model ever sees it. That conversion isn't free. It's usually small next to a full sampling pass, but "usually small" adds up the moment you're re-encoding the same text over and over: queuing a batch of variations off one prompt, running an XY-plot style sweep, or looping a workflow where the positive prompt is fixed and only the seed or the negative changes. ComfyUI already skips re-running a node if none of its inputs changed since the last queue - but that protection breaks the moment the text going into CLIPTextEncode comes from something dynamic (a wildcard node, a prompt list, an LLM node generating variations), even if the actual string it produces happens to repeat. CachingCLIPTextEncode catches those repeats at the content level: same text, same CLIP model, and it hands back the conditioning it already computed instead of running the encoder again.

It's worth knowing this is the same instinct that shows up on the training side: the standard advice for LoRA training configs is to precompute and cache text embeddings once up front, because reloading the text encoder for every step is one of the biggest, dumbest speed costs in a training run. This node applies the same idea at inference time, inside your workflow graph, one node at a time.

The author, discus0434, isn't a stranger to this corner of ComfyUI either - they're also behind comfyui-aesthetic-predictor-v2-5, a node people actually reach for when grading LoRA training datasets. Not directly related, but it's a small signal this is someone who ships focused, single-purpose tools rather than kitchen-sink packs.

Inputs and outputs

Only two inputs, both required, and they're the same two CLIPTextEncode takes:

• text - your prompt, multiline.
• clip - the CLIP model to encode with, from your checkpoint or CLIP loader.

One output: CONDITIONING, which wires straight into a KSampler's positive or negative slot exactly like the stock node's output would.

There's nothing else to configure - no threshold, no cache-size knob, no device selector. That's the whole interface, and it's why the swap is genuinely drop-in.

How to install it

Straight from the README, and it's about as light as installs get:

cd ComfyUI/custom_nodes
git clone https://github.com/discus0434/comfyui-caching-embeddings.git

Or search "ComfyUI Caching Embeddings" in ComfyUI Manager and install from there. Either way, restart ComfyUI afterward. There's no requirements.txt to run and no model file to download - it's pure Python logic wrapped around the existing CLIP encode call, so it adds no new dependency weight to your environment.

Using it, and where it won't help

Swap it in anywhere you'd use CLIPTextEncode and treat it identically - same inputs, same output, same wiring. The only thing to actually understand is when it doesn't do anything: if every run genuinely has a different prompt, there's nothing to cache, and you're paying zero cost but getting zero benefit either. Where it earns its keep is repetition - batch jobs, prompt sweeps, API workflows that fire the same positive prompt across many requests, anything where the same string keeps coming back around.

Because it's such a small, self-contained node, there isn't a documented list of failure modes to speak of, and I couldn't find community reports of it breaking against ComfyUI updates the way heavier caching nodes (like Wan's TeaCache) sometimes do. If you hit an error, the usual custom-node checklist applies first: confirm the pack updated cleanly (git pull in its folder) and that you restarted ComfyUI after installing - that covers the overwhelming majority of "custom node won't load" reports for packs this size.