Load Condition

Every time you hit Queue, ComfyUI runs your prompt through the text encoder again. On most setups that's a few hundred milliseconds - nothing worth optimizing. But build a workflow where one long, carefully tuned prompt feeds every generation in a batch, and re-encoding it each run starts to feel wasteful. LoadCondition is the "stop re-encoding" node: it reads a conditioning tensor you saved earlier (with its sibling SaveCondition, same pack) straight off disk and hands it to the sampler. Text encoder never involved.

Quick background if you're new: a CONDITIONING in ComfyUI isn't a single tensor. It's a list of tuples - (tensor, cond_info) - where the tensor is the text embedding and cond_info is a dict carrying extras like pooled_output. That whole structure is what SaveCondition writes to disk and what this node brings back. Same data the CLIP Text Encode node would have produced, just pickled into a .ckpt file instead of living in RAM for a run.

How it works

LoadCondition reads from ComfyUI/models/conditions (auto-created if missing) using ComfyUI's folder_paths system, loads the file with torch.load, and returns it as a CONDITIONING. It sanitizes the filename and appends the .ckpt extension for you, so you can't navigate out of that folder with a cleverly named file. Small pack, no dependencies beyond what ComfyUI already ships.

Inputs and outputs

The only thing you set is one dropdown:

• filename - a list of the .ckpt files currently in models/conditions, shown without the extension. Pick one and you're done.

The output is a single CONDITIONING socket, and it wires exactly where a CLIP Text Encode output would: into the positive or negative input of a KSampler, or into conditioning modifiers like a ConditioningSetArea if you're doing regional stuff.

Where people get burned

• The dropdown is a snapshot. It's built when the node is created, so if you save a new condition and it doesn't appear, that's expected. Re-add the node or reload the workflow.
• Conditions are locked to their encoder. The embedding lives in whatever CLIP/T5's vector space produced it. An SDXL condition dragged into a Flux workflow is a shape mismatch waiting to happen (the dims differ - 768 vs 1280 vs 4096 territory) and will hard-fail or silently garble. Save and load within the same model family. This is the number one way people misuse these nodes.
• A missing file fails loudly. If the file isn't there, the node prints an error to the console and returns an empty conditioning list - which is not a real conditioning, so the sampler downstream will choke on it rather than quietly produce a blank image. Keep your conditions folder tidy.
• It's a pickled torch object, so only load files you saved yourself or got from someone you trust. Don't go grabbing random .ckpt condition files off a forum and pointing this at them.

Installation

Same as any custom node:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-Condition-Utils

Restart ComfyUI and it lands under conditioning/utils. Or just search "Comfyui-Condition-Utils" in ComfyUI Manager. No requirements, no model downloads, nothing to configure.

It's a niche tool - you'll reach for it when you're caching an expensive encode or sharing a workflow where you don't want to hand out the prompt. For everyone else, CLIP Text Encode is fine. But when the encode is the bottleneck, this is the one to grab.