Loom Latent In

Latents are the most awkward wire type to route because they're invisible - you can't look at one to check it's the right thing. Loom Latent In bundles a LATENT into a LOOM stream so your latent travels with the pipeline instead of getting lost in a tangle of invisible connections.

Why you'd reach for it

Multi-stage edit workflows are where this earns its keep. Encode an image to latent once, push it into the loom, pull it out inside each sampling stage, and after each stage push the refined latent back in. Because looms are streams, each downstream subgraph sees the latest version - which is exactly the "take it out, modify it, put it back" loop the c4f-wire-loom README describes, with latents as the thing being iterated.

It's also the clean way to run the same latent through several sampler subgraphs side by side (one for the main pass, one for refinement, one for an upscale pass) without dragging a LATENT wire across the whole canvas. Push it in once via Loom Split, and every branch pulls its own copy.

How it works

Standard typed loom insert:

key = f"LATENT_{label}" if label else "LATENT"
new_loom[key] = latent
return (new_loom,)

Empty label → LATENT; a label like init → LATENT_init. The matching Loom Latent Out uses the same label. Dragging a latent slot onto a collapsed Loom Split hub auto-creates the node with the label filled in.

The inputs that matter

• latent (LATENT): from VAE Encode or any prior sampler output.
• label (string): the key. Leave empty for the single working latent; name it if you juggle several (init latent vs. current latent).
• loom (LOOM, optional): the bundle to extend.

Output is a single LOOM, feeding Loom Split or Loom Join, with the latent pulled back out via Loom Latent Out at each sampling stage.

Installing

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

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

No model files, no extra dependencies - just a restart.

Where it bites

The stream order trap is the big one: if you push the latent into the loom after the sampler subgraph that's supposed to consume it, the subgraph gets nothing. Latent edit pipelines are where this bites hardest, because the "current latent" moves from stage to stage. Also, keys collide silently - two unlabeled latents in the same loom, and the second wins. And as with every node here, the Nodes 2.0 frontend's arrow-drag collapse quirk applies; the pack ships a workaround for it.