String Cycler [LP]

The classic use case for a node like this: you've got a batch of prompts, filenames, or tags - one per line - and you want to queue up a run for each one without manually swapping the text field between queue presses. String Cycler is built for that: feed it a block of multiline text and it steps through the entries as you queue runs, rather than treating the whole block as one static string every time.

What it does

Give it multiline text, where each line is treated as one entry in a list, and two numbers controlling the stepping behavior: repeats, for how many times each entry gets used before the cycler advances to the next one, and loops, for how many full passes through the whole list happen before it's done. It's the same automation pattern that shows up across the ComfyUI ecosystem for batch prompt cycling - the specifics of exactly how repeats and loops interact aren't spelled out on the node itself, so if you're relying on precise counts, queue a handful of test runs first and watch the output order rather than assuming.

The output type is a wildcard (*) rather than a fixed STRING, which means ComfyUI will let you wire it into more than just text inputs - useful if you're cycling through something that gets interpreted downstream rather than displayed directly, though for most people this will simply be feeding a prompt.

Inputs and outputs that matter

• text (multiline, defaults to empty) - your list, one entry per line.
• repeats (default 1, up to 99999) - how many times to use each entry before moving to the next.
• loops (default 1, up to 99999) - how many times to cycle through the entire list.

Output: STRING, wildcard-typed and list-capable - the current entry (or entries) for this step.

Installing it

Through ComfyUI Manager, search "ComfyUI Level Pixel" or "ComfyUI-LevelPixel." Or:

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

Restart ComfyUI. No models or extra dependencies.

Where people get burned

The biggest practical gotcha with any cycler-style node: it advances based on queue runs, not on anything happening within a single execution. If you're testing it by re-running the exact same queued job (Comfy's "run again" rather than a fresh queue add), you may not see it advance the way you expect - the cycling state depends on how ComfyUI treats successive queue entries, and that's worth confirming empirically before you build a big batch around it.

The other thing worth double-checking with numbers this large (repeats and loops both go up to 99999): it's easy to typo an extra digit and accidentally queue a wildly longer cycle than intended. If a batch seems to be taking far longer to finish than the number of prompt lines would suggest, check those two fields before assuming something else is wrong.