Concurrent Submit | zhenzhen-video-g-omni-1.1-flash-lowprice

The plain zhenzhen-video-g-omni-1.1-flash-lowprice node is easy to use and painful to batch: every generation blocks the graph for the whole submit→poll→download ride, and API video jobs are not fast. If your plan is "ten clips for a shot list," you don't want ten of those serially. This node is the pack's answer - Concurrent Submit - and it splits the job in two: you submit instantly and collect later.

What it actually does

"Concurrent Submit | zhenzhen-video-g-omni-1.1-flash-lowprice" is the same omni video node, mechanically auto-generated from the original, with one crucial difference: instead of running the generate and waiting, it validates your inputs and drops the job into a shared worker pool, then hands back a single task handle (COMFLY_VIDEO_FUTURE). ComfyUI moves on. Your job is now being run in a background thread, not on the graph's main thread.

That's the first thing to internalize: this node doesn't download anything. It returns a task. The piece that actually fetches your finished clips is its sibling, Concurrent Collect Videos (10) (ComflyConcurrentVideoAwait) - wire up to ten task_N inputs into it, and it waits for all of them, restores slot order, and hands back video_1 through video_10 plus a status JSON string. Submit now, collect later. That's the whole pattern.

Why the pool is the point

The pool is bounded, and that's deliberate. By default 10 video jobs run at once and up to 10 more queue (COMFLY_VIDEO_CONCURRENCY and COMFLY_VIDEO_PENDING env vars if you want to tune it). Submit beyond that and the node just waits for a slot. So you get real parallelism without hammering the API with unlimited concurrency - unlimited concurrency is how you burn credits and hit the shop's rate limits in the same afternoon. The pool is shared across all zhenzhen video nodes, not per-model, so a busy image batch and this video batch don't double-dip.

The Collect node also decides failure handling: failure_mode = fail_fast aborts and cancels the remaining jobs the moment one fails; placeholder keeps going and leaves an empty clip in the dead slot. For a shot list you'll usually want placeholder - one bad clip shouldn't kill the other nine. The status string tells you which slots succeeded and which died.

Inputs, outputs, wiring

Inputs are identical to the parent node - mode (text/frame/reference_images/reference_video), prompt, seconds, resolution, aspect_ratio, nsfw_check, plus optional image1..3, input_video, video_url, api_config, skip_error, and the cache-only seed. Only the output changes to that single task. The API Settings node (Comfly_api_set) is unchanged - one settings node feeds every submit node.

Comfly_api_set ──▶ Concurrent Submit (task) ──▶ Collect Videos (10) ──▶ SaveVideo
                        (task) ────────────────┘

Install and gotchas

Same as the parent: install Comfyui-zhenzhen via ComfyUI Manager or git clone https://github.com/T8mars/Comfyui-zhenzhen into custom_nodes, restart, and paste an API key from the shop (api.seedance.nz / ai.t8star.org) into the settings node. No model files anywhere.

Three traps:

• Don't forget the Collect node. A loose submit output does nothing visible - no video, no error, just a task handle floating in the graph.
• A big batch looks frozen. If you submit 30 jobs, the last ones block until slots free. The graph isn't dead; it's waiting for a queue slot.
• Strict validation still applies. Same mode rules as the parent: frame wants exactly one image, reference_images wants one or three, reference_video wants exactly one video source. Validation runs before submit, so bad wiring fails fast - which is honestly nicer than discovering it mid-batch.

If you're doing more than a clip or two of this model, the concurrent split is the one I'd reach for. It turns a queue of slow API jobs into a fire-and-forget batch, and the pool cap keeps you honest about cost.