Concurrent Submit | zhenzhen-MiniMax-H3-Multimodal-Video-lowprice

This node is the same MiniMax-H3 video call as its parent, with one crucial difference: it doesn't block. Concurrent Submit | zhenzhen-MiniMax-H3-Multimodal-Video-lowprice hands your job to the pack's shared video pool (10 workers by default) and immediately returns a task handle, so you can queue up a whole batch of H3 generations and only wait for all of them at the end. It's the "fire ten clips, go make tea, collect ten clips" workflow.

You reach for it when the plain node leaves you serial: every MiniMax-H3 clip is a full round trip - upload any media, submit, poll until the remote job finishes, download - and if you're auditioning shots, angles or variations you'd otherwise sit there watching one job at a time. The concurrent variant fires them in parallel up to the pool limit. It costs the same per clip - this isn't batching for a discount, it's batching for wall-clock time.

How it works

Read this once and the whole family makes sense: when the pack loads, ComflyConcurrent.py walks every eligible image/video node it ships and auto-generates a ..._Submit twin for each one, filed under a Concurrent Submit subcategory. The twin copies the original node's exact inputs, but its one job is to run the original generate() inside a thread from a bounded executor and hand back a future - a COMFLY_VIDEO_FUTURE task, not a video.

The pool is configurable via environment variables: COMFLY_VIDEO_CONCURRENCY (default 10 workers) and COMFLY_VIDEO_PENDING (how many jobs wait before the pool refuses more). There's a separate image pool of 30 for the image nodes; videos get 10 because each one is a heavyweight remote job. If the pool is full, the submit waits its turn rather than throwing.

How you wire it

The output is a single task port. You don't plug that into SaveVideo - you plug it into the pack's collector, ComflyConcurrent_Video_Await ("Concurrent Collect Videos (10)"), which takes task_1 through task_10 and returns video_1 through video_10 plus a status string telling you which slots succeeded, failed or were never connected. It waits for every task you fed it, so nothing shows up until the last clip lands. One knob: failure_mode - fail_fast (default) cancels the remaining queue the moment any task errors, while placeholder lets the failed slot come back empty and the rest finish.

All the inputs you'd set on the plain node are here, identical: prompt (required), duration, resolution (480P/768P), ratio, and the media slots - first/last frame, up to 9 reference images, 3 reference videos with videoN_start_seconds, reference audio and drive_audio. Set each submit node as if it were its own standalone generation, because that's exactly what it is. Wire each one's task into a numbered slot on the collector and let the collector own the ordering.

Installing and the shared caveats

Same pack as the parent node - T8mars/Comfyui-zhenzhen. If you don't have it: ComfyUI Manager → search "Comfyui-zhenzhen" → install, or:

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

Restart, and the concurrent nodes appear automatically - there's nothing extra to enable. You still need the API key wired through T8Zhenzhen_API_Settings (or SEEDANCE_API_KEY), because ten concurrent submits mean ten paid jobs against the same cheap-shop account.

The real gotcha is billing discipline. A batch of ten is ten charges the moment they land in the pool, and if one submit times out the pack deliberately won't auto-retry it - the server may already have created the paid task. When a run goes quiet, check the shop's async-task page for the task_id before re-firing. The seed on each submit node is cache control only (not sent to the API), and fixed reuse is actually your friend here: it stops a re-run from silently creating ten more paid jobs. And note the pool isn't infinite - queue more than 10 concurrent jobs and later ones sit pending until a worker frees up, which is exactly the wall you installed this node to avoid.