Multi-Checkpoint (Auto Incremental Name)

The name is honest, and that's the point

The "Auto Incremental Name" in the display name is the most boring-sounding feature in ComfyUI, and it's secretly the whole reason this node exists. You feed it up to five checkpoints, it runs the exact same prompt, seed, steps, cfg, sampler and scheduler on each one, saves every result as its own PNG (with _01, _02… so it never overwrites the previous run), and hands you a stacked IMAGE batch to flip through. It's a checkpoint A/B tester with zero setup.

Why does that matter? Because the community's #1 rule for comparing models is change one variable at a time, lock the seed - it shows up in every troubleshooting thread for a reason. This node bakes that discipline in: one seed, one settings block, five contestants. The "incremental namer" part is what makes repeated passes usable, because re-running the same comparison doesn't clobber your earlier results. If you've ever squinted at four near-identical realistic merges trying to decide which one does skin right, this is the tool for the job. It's also handy as a sanity gate: downloaded a new merge? Punch it in next to your current favorite and let it answer for itself.

How it actually works

Under the hood it's a miniature KSampler pipeline, not a wrapper around the standard nodes. For each checkpoint it calls ComfyUI's own load_checkpoint_guess_config (the same loader Load Checkpoint uses), tokenizes your prompts through that checkpoint's CLIP, samples from a blank latent with common_ksampler, and decodes with the model's own VAE. Then it permutes the tensor to ComfyUI's [B,H,W,C] preview order, saves the PNG with your full workflow metadata embedded (drag it back into ComfyUI to reproduce), and returns the whole batch as one IMAGE.

The part worth knowing about is the hygiene. Between models it drops all references, forces a garbage collection, and calls soft_empty_cache() - so loading five checkpoints back-to-back won't quietly OOM you the way a hand-wired workflow with five Load Checkpoint nodes can. And it wraps each model in its own try/except: a corrupt file or a model that doesn't fit just prints a traceback in the console and moves on. If every model fails you get a black placeholder image instead of a crash.

The inputs that matter

Most of these read exactly like a KSampler node, and you'll only touch a handful:

• ckpt_name_1 (required) - the first checkpoint; you can't leave it blank.
• ckpt_name_2 … ckpt_name_5 (optional) - the other contestants. Default is None, meaning skip.
• positive_prompt / negative_prompt - the test scene. The defaults (1girl, cinematic lighting) are anime-flavored; change them to whatever you actually make.
• seed - the fairness knob. It's the same for every model, which is the entire point.
• steps, cfg, sampler_name, scheduler, denoise, width, height - standard KSampler fare; the sampler list is the full 44-entry one, schedulers the usual nine.

Output is a single IMAGE: a batch of all the runs you can preview right on the node, or wire into a viewer if you want the strip saved. Note there's no Save Image in the graph - the node saves the per-model PNGs itself, straight to your ComfyUI output folder, named after each checkpoint.

One trap: keep denoise at 1.0. There's no source image input here, so this is pure text-to-image; lowering denoise just means sampling from a half-blank latent, not refining anything.

Installing it

It's genuinely trivial - the whole pack is a single node, and it has no requirements.txt and downloads nothing; it only needs the checkpoints already sitting in ComfyUI/models/checkpoints and the torch/numpy/PIL that ship with ComfyUI. No dependency hell for once. Either way, then restart ComfyUI:

cd ComfyUI/custom_nodes
git clone https://github.com/g7b2/ComfyUI-MultiCheckpoint-Tester.git

Or in ComfyUI Manager, search for the pack title ComfyUI-MultiCheckpoint-Tester and hit Install.

When it bites

The files "disappear" - they're not going through a Save Image node, so look in ComfyUI/output under the checkpoint's name. If a run ends up shorter than the number of models you picked, one of them failed to load; check the console for the ❌ traceback naming it. And don't reach for this when your test needs LoRAs, ControlNet, or a refiner - there are no inputs for those, and it won't respect any mid-graph setup you try to route through it. It's deliberately the bare checkpoint-versus-checkpoint test. For that one job it's the fastest honest answer I've used.