Concurrent Submit | Zhenzhen_sora2_openai

Most of the Sora 2 nodes in Comfyui-zhenzhen talk to OpenAI through the author's own relay formats. This one is different: it's the "official format" node - the one that speaks OpenAI's native Sora API shape directly, and for a long time it was the image-to-video specialist in the family. The README states it plainly: this node was only for image-to-video at launch. You feed it a reference image and get Sora 2 animating it, using the exact model names OpenAI ships (sora-2, sora-2-pro, sora-2-vip).

This is its concurrent wrapper. Instead of blocking the graph for however long Sora takes, it submits the job to the pack's shared video pool (ten workers) and returns a task immediately. Stack several, drop them into Concurrent Collect Videos, and you've got parallel Sora 2 image-to-video drafts instead of a queue.

Inputs that matter

• model - defaults to sora-2-vip, which is notable. This node is the one that expects the premium sora-vip token group; the README says OpenAI's rate limiting is tight enough that the VIP group is what stays stable. sora-2 and sora-2-pro are there too.
• image - the reference frame for image-to-video. The whole point of the node.
• seconds - 10, 15, or 25. Same 25s caveat as the rest of the family: slow, and not to be combined with HD where that applies.
• size - instead of an aspect-ratio dropdown you get exact resolutions: 1280x720, 720x1280, 1792x1024, 1024x1792. You pick the pixel box directly, which is the official API's native way of doing it.
• prompt, apikey, seed, private, skip_error - the usual suspects. private defaults to true; the pack hides generated videos from public listing, and the changelog mentions leak-protection built into the Sora 2 nodes.

Output is a single COMFLY_VIDEO_FUTURE task, same as every video Submit node here.

How the concurrent half works

Like all the Submit wrappers, this is generated in ComflyConcurrent.py from the original Comfly_sora2_openai class: same inputs, original validator, then the real call goes onto a bounded executor with ten video workers. The task you get back is a future plus the source node key, so the collector (ComflyConcurrent_Video_Await) can tell you per-slot whether it succeeded, failed, or was never connected. Its failure_mode lets you degrade failed slots to blank videos (placeholder) instead of aborting the whole batch.

Setup

Install the pack once - ComfyUI Manager, search "Comfyui-zhenzhen", or:

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

No models, no VRAM. You need a Zhenzhen key from ai.t8star.org (overseas) or api.seedance.nz (domestic) with the sora-vip group enabled on the token if you're using the default model. Paid per call, so the group you pick shows up on the bill.

Where people get tripped up

The default sora-2-vip model means this node requires the sora-vip group on your token - if you set the group wrong, you'll get auth-style failures that look like a bad key. If you get 500s, that's OpenAI's load, not yours; rerun. A timeout can still mean the job finished server-side - check your async task page and grab the MP4 there. And remember you're sharing the ten-slot video pool with every other video node in the pack, so a full queue just waits its turn.