Powder Conditioner

The Powder Conditioner is the centerpiece of the E2GO "Powder" pack, and it's solving the problem that everyone doing batch work hits eventually: your prompt is actually five pieces - a style wrapper, a base prompt, and a LoRA trigger - and stringing them together by hand across dozens of combinations is where errors sneak in.

In stock ComfyUI, you'd wire a CLIPTextEncode for the positive, another for the negative, and do the assembly yourself with text-concat nodes. The Conditioner replaces that whole block. It takes a prompt, optional negative, a LoRA trigger block, and a style block, assembles the final text, and encodes it - once, not once per combination - and hands you ready-to-sample CONDITIONING.

How it works

The node pulls together three optional JSON inputs that the other Powder nodes produce:

1. Style (from Powder Styler) - a prefix and suffix that wrap your prompt.
2. Prompt - your actual prompt text, usually from Powder Prompt List or Powder Prompt Wildcard.
3. Trigger (from Powder Lora Loader) - LoRA trigger text, placed before or after the prompt per the loader's trigger_position.

The assembly order is governed by style_position (from the style) and trigger_position (from the lora_info). With "wrap" style and an "after" trigger you get style_prefix, prompt, style_suffix, trigger.

Then it encodes via CLIP and caches. Each (CLIP model + prompt) pair is encoded once; repeat runs with the same pair are cache hits, which is the whole point when you're sampling the same prompt at different seeds or CFG values. Prompts sharing the same CLIP/prompt pair are deduplicated so the actual encode happens only once.

The inputs that matter

• clip - the CLIP model, usually straight from Powder Lora Loader (or a CLIPLoader if you're not using LoRAs).
• prompt - your prompt(s). Wired in.
• negative_prompt - your negative prompt(s). Optional.
• lora_info / style - the JSON contracts from the Lora Loader and Styler. Optional; the node works without them.
• cache_mode (default auto) - this is the setting to know about. auto caches for stable CLIP encoders (SDXL, SD 1.5) but automatically disables caching for FLUX, T5, and mixed-precision quantized CLIPs, where identity tracking is unreliable. aggressive caches everything including FLUX - only use it if you've verified no CLIP state changes between runs. disabled never caches. Leave it on auto unless you have a specific reason not to.
• use_cache (default yes) - master switch, kept for backward compatibility. Turn it off and the node bypasses all caching regardless of cache_mode.

The outputs

• positive_conditioning / negative_conditioning - the CONDITIONING you wire into your sampler (CFGGuider, KSampler, etc.).
• final_positive / final_negative - the assembled prompt text as STRING. These are your debugging friends: when the output is weird, wire these to a text display node and check exactly what text got encoded.

Installation

The pack is one install for all eight nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/E2GO/e2go-comfyui-nodes.git e2go_nodes

Restart ComfyUI, or search e2go_nodes / E2GO in ComfyUI Manager. No external pip dependencies - the pack runs on ComfyUI's own runtime, and the README verifies ComfyUI 0.17+.

Common issues

The two things that bite people are cache-related, and they pull in opposite directions. First, stale results: if you switch base models and the output stops changing, the conditioning cache is holding old encodings - wire in Powder Clear Conditioning Cache, bump its trigger, run once. Second, "why is my FLUX workflow not caching?": that's not a bug, it's auto mode doing exactly what it says - FLUX encoding is just not safely cacheable by identity, so the pack skips it. If you're on FLUX and want the speed anyway, aggressive is there, but know the risk before you flip it.

One more tip from the usage guide: the Conditioner works fine on its own as a plain caching CLIP encoder. You don't need the whole Powder pipeline to use it - wire a prompt straight in and it behaves like a CLIPTextEncode that remembers what it encoded. For anyone who's tried to keep CLIPTextEncode + prompt-assembly strings in sync across a batch, that alone is worth the install.