Loom Model In

The moment your workflow grows past one checkpoint, the model wire becomes the thing you're forever unplugging and re-plugging. Loom Model In bundles a MODEL into a LOOM stream so the model travels with the rest of your settings instead of as a lone wire snaking across the graph.

Why you'd reach for it

The pack's own README demo - LongCat Edit - builds a combo box for selecting models, and Loom Model In is the wire that makes it work. A single model subgraph loads several checkpoints, a selection widget picks one, and the chosen model gets pushed into the loom where any sampler subgraph can pull it out. Change the selection and everything downstream just gets the new model, no re-wiring.

It's also the answer to the README's favorite trick: keeping a separate upscale model in its own loom so its MODEL key doesn't collide with the main checkpoint's, then nesting that loom inside the main one and pulling it out when the sampler wants to upscale. That's the "looms inside looms" pattern, and model wires are where it shines - different models, same slot type, no name collisions.

How it works

A typed dict insert:

key = f"MODEL_{label}" if label else "MODEL"
new_loom[key] = model
return (new_loom,)

Empty label stores under the bare key MODEL; a label like upscale stores under MODEL_upscale. The matching Loom Model Out needs the same label to find it. Drag a model slot onto a collapsed Loom Split hub and the frontend auto-creates the node and fills the label for you.

The inputs that matter

• model (MODEL): the checkpoint, LoRA-stacked model, or whatever else outputs a MODEL.
• label (string): the key. Empty for the main model, named for the upscale/alternate ones.
• loom (LOOM, optional): the bundle to extend.

Output is a single LOOM, which feeds a Loom Split, Loom Join, or a Loom Model Out inside your sampler subgraph.

Installing

Same pack as the rest. ComfyUI Manager → search "c4f-wire-loom" → install → restart, or:

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

No extra dependencies and no model files to download - the node just moves model objects around in memory.

Where it bites

The usual loom traps apply, plus one model-specific one: because a loom is a stream, the model only reaches subgraphs downstream of where you push it in. Put the Loom Model In after your sampler subgraph and the sampler will never see the model - order in the stream is everything. And remember an unlabeled model clobbers any other unlabeled model in the same loom, which is precisely why the README pushes separate looms for separate models. The Nodes 2.0 arrow-drag collapse quirk applies here too, but the pack's workaround mostly tames it.