Comet 异步图像提交

The synchronous Comet 图像 node blocks your whole ComfyUI queue while the cloud thinks. That's fine for a quick single image, but it's a liability when you're running a longer pipeline or a slow model. "Comet 异步图像提交" fixes it the way any sane async system does: it submits the job, gets a ticket, and returns immediately. The actual image shows up later, and a separate node collects it when it's ready.

The name is a hint about the whole design - submit and receive are deliberately split into different nodes, so your workflow can keep running while the generation happens in the background.

How it works

This node inherits the whole image-calling engine from Comet 图像, but its submit() path does three things: uploads your reference images, fires off the request to the selected channel, and registers the task in the pack's internal async task list. It returns a query_info string - that's your ticket, containing the task ID and a human-readable status line like "异步图片提交成功 | <task_id> | 模型: ... | 子任务数: N".

It does not wait, and it does not download anything. That's the receiver node's job.

The inputs mirror Comet 图像 almost exactly: channel (default grsai), model (28 choices, default nano-banana-pro), prompt, concurrency (1–10), aspect_ratio, image_size, quality, reasoning_effort, and background_mode. With concurrency set above 1, the node registers that many subtasks under one task ID, so one submit can spawn several candidate images - and the receiver will hand back the full batch.

Reference images work the same way as the sync node: images plus the virtual-wire image_1 through image_16 inputs, which the frontend compiles from whatever you dragged to the unified ref entry point. Max references are capped by the channel+model, same as everywhere in this pack.

Wiring it up

You'll almost always pair this with a CometAPIAsyncImageReceiver. The common pattern:

1. Submit node → capture query_info (or just leave it unconnected; the task list is internal to the pack).
2. Do other work in the graph - an LLM call, a local upscale, whatever.
3. Receiver node → pull the ready results and hand the image batch to your preview/save nodes.

One thing to know: the query_info output is a status string, not a machine-readable ID you must wire anywhere. The receiver keeps its own task list, so on a fresh queue it knows what's pending even without seeing the submit node's output. That means the two nodes are siblings, not a strict input/output chain.

Install and caveats

Same pack install as everything else: ComfyUI Manager (search "ComfyUI-CometAPI") or git clone https://github.com/jieg9341-lab/ComfyUI-CometAPI into custom_nodes, restart, key in the 设置中心. Dependencies are just requests and aiohttp.

The caveats, briefly:

• Submitted doesn't mean finished. If you run the receiver before the cloud is done, it reports "暂无可用图片结果" and hands back a placeholder - it won't fabricate a result. Re-run the receiver (or run it with a higher run_count) once the job's done.
• The bill is the same as sync. Async just decouples your queue from the latency; it doesn't make the call cheaper. concurrency is still concurrency.
• Your references still get uploaded to the reseller, so the data-leaves-your-machine rule applies exactly as it does on Comet 图像.
• Task state lives in the pack's process memory plus the data folder - restarting ComfyUI mid-task can orphan a job, so don't rely on async tasks surviving a full restart.