Concurrent Submit | Zhenzhen_sora2_chat

Inside Comfyui-zhenzhen there are several roads to Sora 2, and they're not equal. The "chat" variant is the one the author tuned for speed and stability - it hits the endpoint in a chat-completions style format instead of the heavier generation API, and for a long stretch of the changelog it was the recommended everyday Sora 2 node. If your goal is "get a usable Sora 2 clip back fast and cheap," this is the wrapper you reach for.

This node is that chat node, rebuilt for the pack's concurrent system. Instead of running synchronously and freezing your graph while Sora churns, it submits the job to the shared video pool (ten workers) and hands you a task. You stack a handful of these, collect them in the Concurrent Collect Videos node, and all ten are generating in parallel. For a model whose generations take minutes, that's the difference between one draft an evening and a whole contact sheet.

What's different from the main Sora 2 node

Compare this to ComflyConcurrent_Comfly_sora2_Submit and the shape is noticeably simpler:

• orientation (portrait / landscape) instead of an aspect-ratio dropdown. Portrait is the default, and portrait output is historically where this node has been strongest.
• duration - 10, 15, or 25 seconds, same as the main node.
• model - just sora-2 and sora-2-pro. No sora-2-vip here.
• image - one reference image input, singular. The chat path doesn't do the multi-image reference the main node does with image1–image4; it's single-shot image-to-video.
• hd - a boolean, same as the main node.

Everything else you expect is there: prompt, apikey, seed, and skip_error. The output is a single COMFLY_VIDEO_FUTURE task, and it wires into exactly the same collect node as every other video Submit node in the pack.

How the concurrent mechanism works

Like all of the pack's Submit wrappers, this is auto-generated from the original Comfly_sora2_chat class in ComflyConcurrent.py. The wrapper copies the original inputs, runs the original validator, then pushes the real call onto a bounded executor - ten video workers, configurable via the COMFLY_VIDEO_CONCURRENCY environment variable if you ever want to raise it. The returned task is a future plus the original node key, so the collect node can report which slot succeeded and which failed in its status output. Set the collector's failure_mode to placeholder and a dead slot degrades to a blank video instead of aborting the batch.

Getting set up

Install the pack once - via ComfyUI Manager (search "Comfyui-zhenzhen") or:

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

Restart ComfyUI and you're done: no checkpoints, no LoRAs, no VRAM. The only real prerequisite is a key from the author's shop - ai.t8star.org (overseas) or api.seedance.nz (domestic, cheaper) - and enough credits, because every clip is a paid call.

Where people get burned

The usual Zhenzhen/Sora 2 caveats apply. A 500 is most often OpenAI being overloaded - rerun and move on. A node timeout doesn't mean the job died; check the async task page in your account and grab the MP4 there if it finished server-side. The overseas endpoint needs a reachable proxy from many networks (443 errors are the classic symptom). And the chat path is not the path for multi-image reference or the VIP model - for those you want the main Comfly_sora2 wrapper. Pick the node by what your shot needs, not by muscle memory.