Cloud Materialize Latent

Most cloud nodes build JSON and let the terminal node run the job. Cloud Materialize Latent breaks that pattern: it actually runs the cloud chain so far, downloads the result, and hands you a real local LATENT tensor plus the cloud job's prompt id. It's the pack's bridge from "running on someone else's GPU" back to "running on yours," and it exists for one specific workflow shape - inserting a local-only operation, like a third-party latent upscaler, into the middle of a cloud chain.

The mechanism is neat. The node takes your accumulated CLOUD_LATENT chain, appends a SaveLatent node to the workflow JSON, submits the whole thing to Comfy Cloud, polls until it's done, downloads the saved .latent blob, and deserializes it into a local LATENT tensor. From there it's a normal local tensor: run your local upscaler or other local-only node on it, and the result can't go back into the cloud chain - the author is explicit that Comfy Cloud has no LoadLatent support, so this bridge is strictly one-way.

Inputs

• samples - the CLOUD_LATENT chain you want to pull down. The node detects whether it's been initialized yet (its IS_CHANGED hashing guards against re-submitting before the handle exists).
• poll_interval - FLOAT, default 3 seconds. How often to check job status while waiting.
• timeout - INT, default 600 seconds (max 3600). If the cloud job runs longer than this, the node gives up. For long video latents, bump it - the pack's own notes warn that heavy Wan 2.2 jobs can take 8–10 minutes.

Outputs:

• samples - a real LATENT tensor, the downloaded result.
• prompt_id - STRING, the cloud job id. Handy if you want to look the job up in Comfy Cloud's history.

Installation

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/Dobidop/ComfyUI-CloudAPI-worker

Copy config.json.example to config.json, paste an API key from https://platform.comfy.org/profile/api-keys, restart. Manager-installable as "ComfyUI-CloudAPI-worker"; deps: requests, Pillow, safetensors.

Gotchas

• One-way, remember. You can pull a latent from the cloud and process it locally, but you cannot push the processed latent back into a cloud chain. Plan your graph so the local detour is a terminal-ish side path, not something the cloud sampler depends on.
• This node submits a job on every run, so it bills cloud time. Use it deliberately, not as an always-on intermediate.
• If the job times out, raise timeout before retrying - 600 seconds is fine for images and short clips, insufficient for big video work.
• Proof-of-concept pack: the node handles multiple returned latent blobs by taking the first, which is fine for the intended use but worth knowing.