Boyo Latent Passthrough
The latent clone node for when loops start sharing state they shouldn't
- latent
- latent_out
A latent passthrough sounds like the most pointless node imaginable - take a latent, return the same latent. But in loop-heavy workflows it earns its keep. The problem is reference contamination: when you're looping a latent through ComfyUI's cache system, a plain pass-through can carry hidden state between iterations, and suddenly iteration 3 is being influenced by iteration 2 in ways you didn't ask for. Boyo Latent Passthrough's real job is to break those references by cloning the tensor into fresh memory.
The force_copy toggle (on by default) does a deep clone of the latent dict - tensors get .clone().detach(), everything else gets deep-copied - so downstream nodes can't mutate the original through a shared reference. Flip it off and you get the literal no-op passthrough, useful when you want to confirm the node isn't the culprit.
The inputs
- latent - the LATENT to pass through.
- force_copy - default true. Deep-clone to break state references, or plain pass-through when false.
- clear_cache - default false. When enabled it runs garbage collection and
torch.cuda.empty_cache()before passing through. Aggressive, but handy right before a memory-hungry stage in a long batch.
Output: latent_out - functionally the same latent, possibly a fresh copy.
Install
Part of Boyonodes. ComfyUI Manager → search "Boyonodes", or:
cd ComfyUI/custom_nodes
git clone https://github.com/DragonDiffusionbyBoyo/Boyonodes
Restart. No extra dependencies.
When you actually need it
Honestly? Sometimes you don't. It's a debugging and hygiene tool. Reach for it when a looped workflow produces results that change between runs despite a fixed seed, or when an iteration seems to inherit the previous one's artifacts. Drop it in line with force_copy on and see if the weirdness disappears. The same file also ships a sibling, Boyo Execution Barrier, for enforcing execution order between otherwise unconnected branches - this node is the reference-cleaner, that one is the order-enforcer. Different jobs, same category.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — | |
| force_copyopt | BOOLEAN | true | — |
| clear_cacheopt | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| latent_out | LATENT | — |