Concurrent Submit | zhenzhen-image-g-v2.5-official（Flare/Sunburst）

The official G v2.5 route is the strict, more expensive one - quality tiers, output formats, up to four images per call. It's also still a cloud job that spends most of its life queued. That combination is exactly when you want the concurrent twin instead of the standalone node: many prompt variations, submitted in parallel, results collected in order.

This is the submit half. It takes the identical input set to zhenzhen-image-g-v2.5-official（Flare/Sunburst） and returns a single task handle of type COMFLY_IMAGE_FUTURE. It renders nothing.

The pair, and why the ordering matters

Wire each submit node's task output into the collector - Concurrent Collect Images (30), class ComflyConcurrent_Image_Await. It has thirty task sockets, a failure_mode dropdown, thirty image_* outputs and a status string. It blocks until everything it was handed has resolved, then emits results in slot order: whichever submit node you plugged into task socket seven produces image_7, finished first or last.

That's the reason to use the packaged version rather than rolling your own with a Queue node. Batching cloud calls is easy; getting the images back matched to the prompts that made them is the annoying part.

The collector is also deliberately marked always-run - it uses the float("NaN") IS_CHANGED idiom, which is how a ComfyUI node declares "never skip me" because NaN never equals itself. The waiting happens once, at the end of the graph, instead of inside each of your submit nodes.

failure_mode decides what a bad slot costs you. fail_fast throws on the first error and cancels whatever is still queued. placeholder returns a blank image in that slot and names it in status. Fail fast while you're dialling in prompts; placeholder for the unattended run.

Inputs

All of them are copied straight from the standalone node, and the validator comes with them, so nothing invalid ever reaches the pool: model (flare or sunburst), prompt, size (eighteen options including preserve_reference, custom and auto), custom_size, resolution (1k/2k/4k), quality, n (1–4), output_format, output_compression, background, moderation, plus optional image1–image16 references, api_config, skip_error and seed.

The one that matters for batching is n. Each submit node can already return up to four images per call, so twelve submit nodes at n=4 is forty-eight billed images with thirty in flight. The pool is a polite abstraction over a rate limit, not a discount.

And the api_config input on every one of them: the Settings node's output fans out to as many inputs as you have submit nodes, one wire each. Miss one and that slot fails in its worker thread rather than at the node, so you'll be reading the collector's status string to find out which one.

Pool sizing

Two bounded thread pools are created when the pack imports - one for images, one for video, since video jobs hold a slot for minutes. Images get thirty workers by default.

export COMFLY_IMAGE_CONCURRENCY=12   # workers, default 30
export COMFLY_IMAGE_PENDING=12       # queued slots beyond the workers

Both accept 1–128 and ignore nonsense values with a console note. If the relay starts answering 429 or 500 - the vendor's own docs call those upstream overload - dropping the worker count is the actual fix. The pool only knows about your machine; the provider's limits live at the other end of the wire.

The seed, again

Each submit node still carries seed, and it's cache control only, exactly as its tooltip says. With fixed and no other change, ComfyUI serves the cached result and never re-submits the task - so re-running a wide graph after editing one prompt doesn't re-bill the finished jobs. Switch to randomize and all of them fire again. This is ordinary ComfyUI caching, but it's worth being deliberate about when every re-run has a price.

Install

Same pack as everything here:

cd ComfyUI/custom_nodes && git clone https://github.com/T8mars/Comfyui-zhenzhen

Manager route: search Comfyui-zhenzhen, install, restart. No weights, no extra services, no queue broker - the concurrency is concurrent.futures inside the pack.