Scorpiov Batch Prompt Runner π
Checkpoint Γ wildcard-line batches without touching the queue
This is the odd one in the scorpiov pack, and it might be the most useful. Scorpiov Batch Prompt Runner is a control panel, not a generation node. It doesn't connect to anything - no inputs, no outputs, no wires. Instead it finds three other nodes already sitting in your graph and drives them, queuing one job per checkpoint-and-wildcard-line combination while you watch.
Here's the scenario it's built for. You're on a wildcard kick: you've got a prompt like a __hairstyles__ woman in a {studio|street} setting, you've loaded it into a Wildcard Prompter in serial mode, and you want to run every hairstyle at every checkpoint you care about, each image saved into its own folder with a clean sequential name. Doing that by hand means clicking queue a hundred times and renaming files. This node does it in one click.
What it actually does
Press the π Run Batch button on the node (a DOM widget, not a socket) and the frontend:
- Locates exactly one
ScorpiovWildcardPrompter, oneScorpiovMultiCheckpointLoader, and oneScorpiovSaveImagein your graph - if it finds zero or two of any of them, it refuses and tells you. - Reads the
__wildcard__token from the prompter's text and asks the backend how many lines that file has. - Loops every checkpoint slot Γ every line, setting the checkpoint index and the wildcard's serial position, and queueing each job. It names files as
%date:yyyy-MM-dd%/{checkpoint_tag}/{line:03d}-{checkpoint_tag}, so output lands in date-stamped subfolders with zero rename chore.
The internal bookkeeping is where the author earned their keep. Serial-mode wildcard state only reads serial_start_line the first time it's asked, then auto-increments; because the runner submits the whole batch up front, it resets that state exactly once at the start (via a /scorpiov/wildcard/refresh endpoint) instead of before every submission - otherwise jobs would race ahead of the GPU and silently land on the wrong lines. A comment in the source says this was verified live against a real 43-line wildcard file. That's the kind of detail that separates a node that works in your workflow from one that works in the demo.
Setting it up
Four requirements, all enforced by the node with clear error messages:
- Wildcard Prompter in serial mode - the runner controls which line runs, so random mode is right out.
- A
__wildcard__token in the prompter's text (it uses the first one if you have several). - At least one checkpoint configured on the Multi-Checkpoint Loader via its "+ Add Checkpoint" button.
- No wire into Save Image's
filename_prefix- the runner needs to set that string itself, and a live upstream wire would silently override it. This one trips people up more than the others.
One honest caveat: the node submits every job to the queue at once, so the batch runs sequentially through ComfyUI's own queue. The status text says it plainly - don't submit anything else to this graph until it drains, or your runs will interleave. Also note it's strict about finding exactly one of each node, so a graph with two Wildcard Prompters (say, positive and negative) needs the negative one left out of the broadcast or the runner errors. In practice people chain positive and negative through the same prompter's siblings or accept the limitation.
Installing
Part of scorpiov-nodes. Either search "scorpiov-nodes" in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/vikramudyawar/scorpiov-nodes
Restart ComfyUI after. No extra Python dependencies, no models to download - the whole batch machinery is JS on the front plus a couple of tiny backend endpoints. It's a niche node, but if "test this wildcard file against every checkpoint in my library" is a recurring chore for you, it's the difference between a lunch break and a click.
Inputs (0)
No inputs
Outputs (0)
No outputs