CLIP Text Encode & Combine (Cached)

Two boring things every ComfyUI workflow does a lot: CLIP-encode a prompt, and glue conditioning branches together. This node fuses both into one step - it encodes your text and combines it with whatever conditioning you feed in - and, on top of that, it caches the encode so unchanged prompts don't get re-tokenized on every run. It's the AK Pack's entry in the "why am I re-encoding the same sentence" optimization category, and it slots into any graph that already uses CLIPTextEncode + ConditioningCombine.

How it works

It's a CLIPTextEncode with a conditioning input bolted on and a cache in front:

• clip - the CLIP model.
• text - the prompt, multiline.
• conditioning (optional) - existing conditioning to combine with.
• Output: conditioning.

When text is present, the node encodes it, then returns your_input_conditioning + new_conditioning. That "+" is the standard combine semantics - the new prompt's tokens are appended to the conditioning batch, so the sampler attends to both, exactly as if you'd wired a CLIPTextEncode into a ConditioningCombine. Leave text empty and the node is a pure pass-through: it returns your input conditioning untouched.

The caching is the interesting part. The node remembers the last text and the clip it was encoded with; if you re-run with the same text and same clip, it hands back the stored conditioning instead of tokenizing and encoding again. Change the prompt, and it re-encodes just that one. In big workflows where a lot of re-runs happen while you iterate on other nodes, this skips a genuinely expensive step on every queue. It's a sibling to the pack's bare CLIPTextEncodeCached, which does the same caching without the combine.

Where it helps

• Big single-prompt workflows where you re-run constantly and your positive conditioning never changes - the cache makes every run after the first a bit cheaper.
• Combining a static base prompt with a second, per-branch prompt without adding a combine node.
• Keeping conditioning graphs tidy: one node instead of an encode plus a combine.

The honest caveats

• The cache is class-wide, not per-node. The node shares one cache across every instance of it in your session. In practice that's fine - the cache key includes the exact text and the clip object - but don't expect per-node isolation.
• Combine isn't concat-by-area. ConditioningCombine semantics append to the conditioning batch, which is what this does. If you need area-weighted or masked conditioning, ConditioningSetArea/ConditioningSetMask are separate steps regardless of which node you encode with.
• Caching saves Python-side work, not VRAM. The encoding was the bottleneck; the attention is still paid at sample time.

Install

Standard AK Pack. ComfyUI Manager → search "AK Pack" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/akawana/ComfyUI-AK-Pack

No dependencies beyond the pack, no model files.

Bottom line

If you already have a conditioning-combine pattern and re-run a lot, this is a free micro-optimization plus one less node on the canvas. If your prompts change every run anyway, the cache buys you nothing - in that case a plain CLIPTextEncode + ConditioningCombine is just as good and more standard for anyone reading your workflow later.