Cloud KSampler Advanced

Cloud KSampler Advanced is the graph-style cloud node for when one plain sampling pass isn't enough. It mirrors the stock KSamplerAdvanced exactly, which means it carries the four controls the basic KSampler doesn't: add_noise, start_at_step, end_at_step, and return_with_leftover_noise. Those are what let you chain two sampling passes into one coherent job - the pack's own docstring names the canonical use: two-stage Wan 2.2 sampling, high noise first, low noise second, inside a single cloud submission.

Where does that leave you? If your workflow is one-and-done text-to-image, Cloud KSampler Graph (the plain cloud KSampler) is the right node - fewer dials, fewer ways to trip over yourself. This one is for the workflows where the local graph had a KSamplerAdvanced in it and you're porting it faithfully: two-stage sampling, inpainting-style chains where the second pass starts partway through the step schedule, or anything that needs leftover noise carried between passes.

The inputs that matter

• model / positive / negative / latent_image - the standard four cloud handles (CLOUD_MODEL, CLOUD_CONDITIONING ×2, CLOUD_LATENT).
• add_noise - enable or disable. First pass enables it; a second pass that resumes from the first usually disables it (the noise is already there).
• noise_seed - the seed for the noise you're adding.
• steps / cfg / sampler_name / scheduler - the usual sampler controls. Notice the defaults: steps 4, cfg 1. Those aren't typos - they're the flow-matching/guidance-distilled defaults that Wan and similar modern models actually want, which tells you this node was built for that world, not for SD1.5-style cfg-7/20-step habits.
• start_at_step / end_at_step - the window of the schedule this pass covers. Defaults are 0 and 10000 (meaning "to the end"). For the second of two passes, set start_at_step to where the first stopped.
• return_with_leftover_noise - enable when you want the next pass to inherit unfinished noise; disable when this pass finishes the latent.

Output: latent (CLOUD_LATENT) - the sampled latent, ready for the next pass, a decode, or a materialize.

How it works

Like every graph-style node in the pack, it appends a KSamplerAdvanced spec to the accumulating workflow JSON and returns a handle. It does not submit anything - only a terminal (Cloud VAE Decode, Cloud Fetch Images) does. Everything in this chain - both sampling passes included - runs in a single cloud job, which is the whole appeal: your machine assembles, the cloud executes.

How to 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. ComfyUI Manager works too. Dependencies: requests, Pillow, safetensors.

Common issues

• Second pass restarting from zero - if you chained two Advanced nodes but the second one still has start_at_step=0, you're sampling the same window twice. Set the second pass's start to the first pass's end.
• Using it when you don't need it - more dials, more failure modes. Single-pass workflow? Use the plain cloud KSampler.
• PoC expectations - two-stage chains are exactly where an experimental pack shows its seams. The Wan 2.2 example workflow in the repo is the reference; start from it.