KLingAI Multi-Image to Image

Most "reference image" nodes want exactly one picture. KLingAI Multi-Image to Image wants two to four, and that changes what you can do with it. Feed it several shots of the same product, character, or person and it composites them into a single new image that holds all of them consistent - Kling's multi-reference image API. Think "here are four angles of this shoe, now render the whole scene" rather than "here's one picture, now vary it."

This is the one node in the pack that isn't a pure async fire-and-forget. It still submits a task to /v1/images/multi-image2image, but then it polls internally - up to 10 minutes - and hands you actual IMAGE tensors when the job succeeds, saved to disk. That's a real difference from the video nodes: no separate Query Status + Downloader hop required. One node, images out.

Inputs that matter

• api_token (required) - the JWT from the API Key node.
• prompt (required) - what to generate, using the subjects from your reference images.
• subject_image1 (required) - the first subject reference, an IMAGE input. subject_image2, subject_image3, subject_image4 are optional, so "2–4 images" means you must provide at least the first two for a true multi-reference result.
• scene_image - optional; an image that defines the environment.
• style_image - optional; an image that defines the art direction.
• model_name - exactly one choice here: kling-v2. This API is v2-only, so no version picker.
• n - 1 to 9 images per task.
• aspect_ratio - eight options, same menu as the image-generation node (16:9 through 21:9).
• filename_prefix - default kling_multi_image2image; controls the saved file names.
• output_dir - optional; defaults to ComfyUI's output folder when left blank.
• seed - local, for re-run control as usual.

The output

Four outputs: image (a list of IMAGE tensors, one per generated image), image_url (matching list of result URLs), task_id, and output_dir (where the files landed). The images are already downloaded and converted, so you can preview them or pipe them straight into the image2video node. That's the workflow this node was built for: multi-reference still → Kling video.

The internal wait

Because it polls to completion, this node blocks the queue for however long Kling takes - the code gives up after 600 seconds. A typical run is a couple of minutes. It's the trade for getting real images out the other end instead of a task ID. If you'd rather not block, you'd want the async variant - there isn't one in this pack, so either accept the wait or build the manual Query Status pattern yourself with the raw API.

Where people get burned

• One reference image isn't enough. It's "multi" for a reason; with just subject_image1 you're basically doing a plain i2i call. The API and the node really want 2–4 subjects to do their thing.
• The 10-minute cap. Long queues or slow servers can hit the internal timeout, and you get back empty tensors plus an error string rather than a clean failure. Re-run with the same inputs to retry.
• Blocking surprises. Because it waits internally, a graph that "never finishes" is often just this node sitting on a slow Kling render. Check the console for the polling logs.
• Expecting the full async treatment. You might reach for Query Status out of habit - unnecessary here. It returns files, not a task ID (the task_id output is a bonus for your records).