Loom Conditioning In

Conditioning is what prompts actually become inside ComfyUI, and in any workflow with multiple prompt stages it's the wire that multiplies fastest - positive and negative, for every sampler. Loom Conditioning In bundles a CONDITIONING into a LOOM stream so a whole prompt setup travels as one value.

Why you'd reach for it

The c4f-wire-loom README's Lens demo is the canonical example: a prompt subgraph that takes a few widget inputs, builds positive and negative conditioning, and pushes both into the loom. The sampler subgraph then pulls them out. Build it once, reuse it across every model and sampler variant you swap in - your prompt logic stops being duplicated across ten parallel branches.

It's also the mechanism behind prompt replacers. The LongCat demo swaps prompts mid-stream: pull the conditioning out, re-encode with a modified prompt, push it back in under the same key, and every downstream sampler gets the new conditioning. Because looms are streams, the updated value flows forward automatically - no global store to invalidate.

How it works

The usual typed loom insert:

key = f"CONDITIONING_{label}" if label else "CONDITIONING"
new_loom[key] = conditioning
return (new_loom,)

Empty label → CONDITIONING; a label like negative → CONDITIONING_negative. This is the one type where labeling is basically mandatory, because positive and negative are two distinct conditioning objects - store them under separate labels or one silently overwrites the other. The matching Loom Conditioning Out uses the same labels.

The inputs that matter

• conditioning (CONDITIONING): from CLIP Text Encode or any conditioning-mixing node.
• label (string): the key. Use positive/negative or similar.
• loom (LOOM, optional): the bundle to extend.

Output is a single LOOM, wired to Loom Split or Loom Join and pulled back out with Loom Conditioning Out inside each sampler subgraph.

Installing

Part of c4f-wire-loom. ComfyUI Manager → search "c4f-wire-loom" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Codes4Fun/c4f-wire-loom

No downloads beyond the pack itself, no extra deps.

Where it bites

Besides the ever-present label-collision trap, the gotcha here is that conditioning objects carry a lot of metadata (pooled output, cross-attention kwargs from ControlNet, etc.), so "the same" prompt can encode differently depending on when it's built. If you're pushing conditioning into a loom before a ControlNet applies, the ControlNet won't be part of it - build conditioning after all the influences that should shape it. And the stream rule still holds: only subgraphs downstream of the Loom In see it. The Nodes 2.0 arrow-drag quirk applies as it does to the whole pack.