Loop
Recursion that borrows ComfyUI's internals — handle with care
- _event
- _hold
Let's start with the author's own warnings, because they're the most accurate description you'll get: Loop is "very hacky recursive repetition by messing with ComfyUI internals," "probably unstable as hell since I only tested for simple case," and it "will mess up the workflow very easily if not careful." This is the most dangerous node in the pack, and also the reason some people install the pack at all.
What it does is genuinely unusual: it re-executes a slice of your graph within a single prompt queue. Normal ComfyUI runs every node once per queue and that's it. Loop can run a set of nodes again and again - with a different random seed, a different prompt, a different region - all in one "Generate" press. The pack's README demos it turning a single sampler into a 20-image run with 20 different seeds, and even driving FABRIC-style "pick an image, do it again" loops. There is no vanilla-ComfyUI way to express that.
How it works
_event is the tripwire. It accepts an EVENT_TYPE (from 0246.Count) or a boolean. While the event stays "true," Loop re-invokes the upstream slice of the graph; when it flips false, execution falls through. The node has two code paths: one that calls ComfyUI's recursive_execute directly (the "mess with internals" path), and a newer one built on the dynprompt GraphBuilder that ComfyUI's topological execution introduced. It tracks its state in a LOOP_DB keyed by prompt id + node id so it doesn't leak across queues.
The practical requirement: you need two Hold nodes sandwiching the Loop to pass data between iterations - one to save the previous iteration's output, one to feed it back. That's the README's explicit instruction, and skipping it is how workflows silently corrupt.
The inputs and outputs
_event- the loop condition. Wire0246.Count's_count_eventoutput here for a counted loop._mode- currently onlysweep(the enum has one choice). Reserved for future modes._update- default"{'update': ''}"; this is what tells ComfyUI the loop state changed so it re-executes. Leave it alone until you know what you're doing._hold- theHOLD_TYPEoutput that feeds yourHoldnodes.
How to install it
The usual:
cd ComfyUI/custom_nodes
git clone https://github.com/Trung0246/ComfyUI-0246
restart, or ComfyUI Manager → search "ComfyUI-0246". No models. Because Loop depends on ComfyUI's execution internals, it's the node in this pack most likely to break when ComfyUI updates - the author literally said he'd keep Loop around only "until the topological PRs got merged." That time has passed; newer ComfyUI has moved on, so test Loop against your exact ComfyUI version before trusting it.
Common issues & troubleshooting
Infinite loop / runaway re-execution. The event never flipped false. Check 0246.Count's _event threshold and that the count node actually runs inside the looped slice.
Data from iteration N shows up in iteration N+1 (or is missing). Your two Hold sandwich isn't arranged correctly. Follow the README's loop demo workflow exactly before inventing your own arrangement.
Workflow "messes up" for no apparent reason. The author's own words. Loop rewrites cached node outputs mid-run; any node whose cache assumptions it violates will misbehave. If you can express your repetition as a ComfyUI batch or a list-sweep instead, do that first. Reach for Loop only when the problem genuinely can't be batched - and save your workflow before you enable it.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| _event | * | — | |
| _mode | COMBO | 1 options: sweep | |
| _update | STRING | {'update': ''} | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| _hold | HOLD_TYPE | — |