While Loop Open

You'll almost certainly never add this node yourself - it's marked dev-only, hidden from the node menu, and it exists to make TensorLoopOpen/TensorLoopClose work. But it's the actual loop primitive underneath, and knowing what it does is the difference between "this pack is magic" and "this pack is a well-designed while loop." A generic while condition: in node form.

What it is

_WhileLoopOpen is the "head" of a while loop: it takes a condition boolean and up to five initial_value0 through initial_value4 slots, and outputs a FLOW_CONTROL token plus the five values. When the condition is true, the loop body keeps running; when it's false, the loop exits. Its execute is a stub - it returns the values it was given. The interesting part happens on the Close side, which is where the re-expansion lives.

The five value slots are the loop's working memory. Anything you want to carry between iterations - a latent, an image, a counter, a pack of state - goes in as initial_valueN on the Open node and comes back around the loop until the condition fails. That's a cleaner design than people expect from a throwaway testing repo: instead of special-casing "the thing being accumulated," it just treats loop-carried data as opaque values in five slots.

How it fits

When TensorLoopClose expands, it doesn't reimplement a loop - it builds a graph that calls _WhileLoopClose, which recursively re-expands the whole loop body with the new values wired into _WhileLoopOpen. The Open node's only real job in that dance is to be the anchor: the Close node finds the Open node through flow_control, clones every node in between, and stuffs the updated values back in. So _WhileLoopOpen is where each iteration "starts" from a graph-execution standpoint.

Inputs and outputs

• condition (boolean, default true) - keep looping while true. In the TensorLoop pair this gets wired to "should we continue?" - computed from remaining iterations or the accumulated frame target.
• initial_value0 … initial_value4 (any, optional) - the loop's carried state on the first pass.
• Outputs: FLOW_CONTROL and value0 … value4 - the carried values for the current iteration.

Install

It ships with the pack, so this is the standard drill:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-NativeLooping_testing

Restart ComfyUI, or grab it from Manager by searching "NativeLooping". No requirements, no model files. Because it's dev-only you won't find it in the node menu - you'd have to load it from a saved workflow that already contains it, or add it via a custom menu. That's the honest answer if you're hunting for it.

One caveat worth repeating since this whole pack is _testing: kijai's README frames this as a candidate for native ComfyUI loop nodes, so don't be shocked if a future ComfyUI ships its own equivalent and this repo goes quiet. For now it's the closest thing to native loop semantics you can run in a custom node.