Image Accum State Pack

Somewhere inside every TensorLoopClose expansion there's a node that shoves the entire loop state into one dict, and another that pulls it back out. _ImageAccumStatePack is the shover - and it's also the node that actually answers the question "should we run another iteration?" Everything else in the loop machinery is bookkeeping around that decision.

What it does

Pack takes the pieces of loop state and bundles them into a single loop_state dict that gets carried around the loop as initial_value0. One dict on one wire instead of five wires of state - that's why the while-loop primitives stay so clean. The inputs are exactly what you'd expect from reading TensorLoopOpen's internals: remaining, previous_value, count, open_node_id, total_frames, prev_accumulated_count, blend_overlap, plus the optional accum (the running accumulation list). Its two outputs are loop_state (the bundle) and should_continue (the decision).

The decision logic is where it earns its keep, and it differs by mode:

• iterations mode - should_continue is simply remaining > 0. Countdown until zero.
• total_frames mode - should_continue is accumulated_count < total_frames. Keep going until enough frames have piled up. It counts the accumulated frames correctly even when fade overlap eats frames at the seams (that's what blend_overlap is for), and it updates the progress bar against the frame target so you can see it crawling toward 100.

There's a subtle bail-out in there that's worth knowing about: if the accumulated count didn't increase since the last iteration, it stops the loop even if the frame target isn't met. That guard exists because a video model can stall - generate a chunk that contributes zero net new frames - and without it you'd loop forever chasing an unreachable target. It's a small thing, but it's the difference between a node that hangs and a node that gives up gracefully.

Inputs and outputs

The two inputs you'd actually touch if hand-building a loop are remaining (the countdown) and total_frames (the target, 0 to ignore). prev_accumulated_count is the "did we make progress?" value. Outputs: loop_state goes into a _WhileLoopClose as carried state; should_continue becomes the while loop's condition.

Install

Pack-standard, and it has no dependencies beyond a current ComfyUI:

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

Restart ComfyUI, or use Manager ("NativeLooping"). It's dev-only, so it's hidden from the menu - you'll only meet it inside an expanded loop workflow.

Honest caveats: this is a _testing repo from kijai, explicitly a candidate for native ComfyUI loop nodes, so the state dict format could change under you. And if you're debugging a loop that stops early with frames still missing from the output, the "no progress" bail-out is your prime suspect - check whether each iteration is actually adding frames.