Concurrent Submit | zhenzhen-grok-image

Grok's image model - the grok-4.2-image endpoint here - is the odd one out among the closed image APIs: it's an autoregressive MoE predicting visual tokens rather than a diffusion model, and it's genuinely good at multi-image editing. This node wraps that in the pack's concurrent pattern, so you can fire up to 30 image jobs in parallel instead of watching the queue crawl.

The realistic use is a big edit pass: drop a batch of reference images in, vary the prompt per submit node, collect all the outputs at the other end, pick winners. Or a style-consistency sweep across 20 character poses. Doing that with 30 workers is the difference between "comes back in a few minutes" and "I'll check tomorrow."

How the submit/await split works

Like every node in this pack's Concurrent Submit family, this one is a thin wrapper around the plain Comfly_grok_image node. Your inputs are identical to the non-concurrent version; the only change is the output. You get one task of type COMFLY_IMAGE_FUTURE instead of an image. The wrapper validates, drops the call into the shared image pool (default 30 workers, COMFLY_IMAGE_CONCURRENCY env var), and returns.

The task is a promise, not a picture. It has to flow into ComflyConcurrent_Image_Await, which waits for all connected tasks and returns the images in slot order (image_1 … image_30) plus a status JSON. Its failure_mode (fail_fast vs placeholder) decides whether one failure aborts the batch or leaves a blank slot. A Submit node wired straight into a preview node will show you exactly nothing, which is the most common first-run mistake with this whole family.

Inputs that matter

prompt is the only required input. model is fixed at grok-4.2-image. aspect_ratio is a plain string that defaults to 1:1 - the pack treats it as free-form, so try 16:9 or 9:16 as text.

The editing path is where Grok shines. image1–image4 take IMAGE tensors for multi-image reference editing; image_urls is a multiline field for public image URLs (newline or comma separated). image_way picks how references are sent: image_url (default) or base64. async_mode defaults to true, which means the node submits a task and polls - and if you have a task id from a previous run, task_id lets you query it instead of submitting fresh, which is handy after a timeout. poll_interval (default 5s) and max_poll_attempts (default 180, roughly 15 minutes) bound the wait. seed is cache-control only; Grok's API doesn't take a native seed.

Install and troubleshooting

Same pack story: ComfyUI Manager → search Comfyui-zhenzhen, or git clone https://github.com/T8mars/Comfyui-zhenzhen into ComfyUI/custom_nodes, restart. No model downloads - everything runs on Zhenzhen's servers, and you still need an API key (set once in the pack's API Settings node; api_key here can stay blank).

Grok's moderation filter is baked into the model, not the node - there's no local abliteration for a closed API, so expect refusals on anything the filter objects to. A 500 is usually upstream Grok load, and re-running is the documented fix. If the Await node reports a failed slot but the image exists, the render finished and the download timed out - grab it from the site's task page. And since this is the reseller layer of the API ecosystem, it's a node that carries a key and phones home by design: it's a widely-used open pack, but glance at the source before you trust it.