Cloud KSampler Select
63 samplers, none of them running on your machine
- sampler
Cloud KSampler Select is the cloud-side version of the stock KSamplerSelect, and its one job is to pick a sampler from a list and hand back a CLOUD_SAMPLER handle. What makes it interesting is the size of that list: 63 samplers, hardcoded from the cloud's own /api/object_info - not just the familiar euler and dpmpp_2m, but the whole modern roster: euler_cfg_pp, dpmpp_2m_sde_heun, res_multistep, sa_solver, seeds_2, gradient_estimation, rk_beta, and plenty more you've never seen in a stock KSampler dropdown.
That list is the giveaway that this node isn't for the standard workflow. It's a sampling primitive - the pack's README groups it with Cloud CFG Guider, Cloud Random Noise, Cloud Manual Sigmas, and Cloud Sampler Custom Advanced. Those five are the pieces you assemble when you want a custom sampler pipeline: a CLOUD_SAMPLER from this node, a guider, a sigma schedule, a noise source, all fed into Cloud Sampler Custom Advanced. If you're building that assembly, this is how you choose which sampler the whole thing uses. If you're not, you don't need it - Cloud KSampler Graph already carries a perfectly good 22-sampler dropdown.
Inputs and output
- sampler_name - one dropdown, 63 choices. That's it.
Output: sampler (CLOUD_SAMPLER) - into Cloud Sampler Custom Advanced (or wherever a cloud custom-sampler chain expects it).
How it works
Same handle mechanics as everything in this pack: it appends a KSamplerSelect spec to the accumulating workflow JSON and returns a handle referencing it. The sampler is instantiated cloud-side when the chain runs - you're choosing it, not running it. And since the sampler choice is baked into the submitted workflow, changing it means a fresh cloud submission when you re-run.
One thing to keep in mind about that long list: the cfg_pp variants and the res_multistep/rk families are tuned for flow-matching and guidance-distilled models - the modern Wan/LTX/Flux generation - not for SD1.5 habits. Not every sampler plays nice with every scheduler, and with 63 options the failure mode is "you picked something exotic and got a bad or failed job," not an error message explaining why. Stick with the names you recognize until you have a reason not to.
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. Or install via ComfyUI Manager. Dependencies: requests, Pillow, safetensors.
Common issues
- Exotic sampler, bad result - you're in flow-matching territory now; pick familiar samplers unless you know what the exotic one is for.
- Wiring it into a plain KSampler - a
CLOUD_SAMPLERgoes into the custom-sampler assembly, not into thesampler_namewidget of a KSampler node. Different sockets. - PoC expectations - a hardcoded list in a single-author experimental pack. If the cloud adds samplers later, this node won't see them until the pack is updated (the source has a comment to exactly that effect).
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| sampler_name | COMBO | 63 options: euler, euler_cfg_pp, euler_ancestral, euler_ancestral_cfg_pp, heun, heunpp2, +57 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| sampler | CLOUD_SAMPLER | — |