♻📑 Loop Sequential (Integer)

Bjornulf's pack already has a "Loop Integer" node that iterates a range all in one workflow execution - set it up, hit run, and ComfyUI fires through the whole range in a single go. This one is the opposite kind of loop: it hands you exactly one integer per queue run, then remembers where it left off for next time. Run the workflow ten times and you get the numbers one through ten, one at a time, across ten separate executions - not one execution with ten outputs.

That distinction matters more than it sounds. A single-execution loop is fine when everything's local and fast. A sequential, one-per-run loop is what you want when each run is expensive, or when you're driving the workflow externally - clicking Queue repeatedly, or hitting it via the API - and want state to persist between calls without you having to track "which number am I on" yourself.

How it works

Set a range with from_this and to_that, and a jump to control the step size. On the first run, it outputs from_this. On the next run, from_this + jump. And so on, until it passes to_that - at which point, per the author, the node stops the workflow entirely, so nothing downstream executes on that final call. It's not a soft "done" signal you have to check for; it's a hard halt.

Under the hood this is a file, not in-memory state: the node writes its position to counter_integer.txt inside ComfyUI/Bjornulf. That's what lets it survive between separate runs - and it's also the node's one real landmine. The author is explicit: don't put more than one of these in a single workflow. They'd all read and write the same file and step on each other's counters.

The inputs and outputs that matter

• from_this / to_that - the range, 1 to 50,000 each. Defaults are 1 and 10.
• jump - the step size between runs, up to 1,000. Default 1 (every integer, in order).
• Output int_value - the number for this run. Wire it wherever you'd normally plug a manual seed or index: a KSampler's steps, a filename suffix, an index into another list.
• Output remaining_cycles - how many runs are left before the loop halts. Handy for a Show node if you want to watch progress without doing the math yourself.

How to install it

ComfyUI Manager → search Bjornulf_custom_nodes → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/justUmen/Bjornulf_custom_nodes
pip install -r Bjornulf_custom_nodes/requirements.txt

This particular node is pure Python file I/O - no model, no external service - so it works the moment the pack loads. The heavier dependencies in requirements.txt are there for other nodes in the pack, not this one.

Common issues & troubleshooting

The workflow stopped running and nothing errored. That's expected behavior once the counter passes to_that - the node deliberately halts the graph rather than looping back to from_this or erroring out. Reset by editing (or deleting) counter_integer.txt in ComfyUI/Bjornulf, or use the node's reset button, which the author added in a later update alongside a preview of the next counter value.

Two loop nodes are producing weird, inconsistent numbers. You've got more than one Loop Sequential (Integer) in the graph. They share one counter file, so running one advances the state the other reads too. Use only one per workflow - if you need two independent sequences, that's a known gap in the node, not something you can configure around.

Numbers aren't advancing between runs on comfy.icu / API calls. Because the state lives in a file on the executor's local disk, it depends on that disk persisting between calls. On a serverless or ephemeral executor, a cold container can reset the counter file, since there's nothing durable backing it beyond the local filesystem. If you need guaranteed persistence across API-triggered runs, treat this as a convenience for interactive, same-machine sessions rather than a reliable distributed counter.