Checkpoint Name Cycler

You've got forty checkpoints, you only actually use five of them, and you have no idea which five. That's the exact situation this node exists for. CheckpointNameCycler is the heart of the Checkpoint Handpicker Suite: you drop it in front of your checkpoint loader, queue a hundred jobs, and it rotates through your models for you while you go make tea.

The setup is a two-wire change to a workflow you already have. Wire the Cycler's ckpt_name output into CheckpointLoaderSimple.ckpt_name, wire ckpt_name_safe into your image saver's filename/label, set the mode, queue. No rebuilding the graph, no new loaders. That "non-invasive" design is deliberate - the README sells the whole suite as something you bolt onto existing workflows, and this is the bolt.

Modes

Four ways to pick the next checkpoint, chosen by the mode dropdown:

• fixed - a plain selector. The chosen checkpoint is always used, no rotation. Useful when you want the Cycler in the graph but don't want it cycling yet.
• increment - walk the checkpoint list in order, one step per cycle. This is the default.
• randomize - pick from the current set at random. Repeats allowed, no cleverness.
• shuffle_once - build a shuffled deck and work through it. This is the mode the README recommends for a serious review run: set it, queue 500 jobs, and each checkpoint gets run before any of them repeat. When the deck empties, a fresh one is built.

change_every (default 1) decides how many executions each checkpoint gets before advancing. Set it to 5 and increment mode runs each model five times, which gives you a real sample per checkpoint instead of one lucky seed. Want all five batches of a given checkpoint to use different prompts/seeds too? That's on you - this node only swaps models, not prompts.

How it works

The trick that makes the cycling actually happen: the node's IS_CHANGED always returns NaN, which tells ComfyUI "this node changed, re-execute it" on every queue run. So even with identical inputs, each run advances the internal state. That state is kept per tab and per node, which is why two browser tabs don't stomp on each other - a detail the suite cares a lot about (every node in the pack carries tab-scoped state).

There's also a Local List: if you push checkpoints into it from the suite's Checkpoint List Selector, the Cycler processes those first and pauses normal cycling. It's per-tab and per-Cycler, consumed one entry per execution, and ignores change_every and the filter - so it's the "run this specific one right now" queue. And since it overrides even fixed mode, it's also the thing that will confuse you the most. If your Cycler looks like it's ignoring your settings, check the Local List first.

The hidden inputs (hps_filter_statuses, hps_use_local_list, hps_settings_revision, hps_tab_id) are how the frontend talks to the backend. You won't normally touch them - they're the wiring behind the on-node controls.

Outputs

• ckpt_name - feed this into your checkpoint loader. The one that matters.
• ckpt_name_str - the checkpoint name as a plain string, for the Tagger and other string inputs.
• ckpt_name_safe - the name scrubbed to filename-safe characters (spaces become _, extension stripped). Feed this to your saver's label or filename_prefix so images land in checkpoint-aware folders.

Install

Same as the whole suite - no pip dependencies, no model downloads. ComfyUI Manager (search "Checkpoint Handpicker Suite"), or:

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

Then restart ComfyUI.

Where people get burned

If nothing ever changes between runs, you're almost certainly in fixed mode or there's junk in the Local List. If a checkpoint got deleted from disk, a refresh falls back to a valid one. And don't expect increment to feel fair - it's a straight walk, so you'll stare at the same first checkpoint for a while if change_every is high. For review runs, shuffle_once really is the one you want.