Nodes/ComfyUI-CloudAPI-worker/Cloud CLIP Loader
ComfyUI Node

Cloud CLIP Loader

The single text encoder, on someone else's GPU

By Dobidop·Created 5 months ago·Updated 5 months ago· 0
Cloud CLIP Loader
    • clip
    clip_name
    type
    device

    Some models get away with a single text encoder. LTX Video, Mochi, PixArt, Wan, HiDream, SD3-style setups - one encoder, one CLIP loader, done. Cloud CLIP Loader is the cloud-side version of that: it declares a CLIPLoader node in the workflow JSON that gets shipped to Comfy Cloud, and returns a CLOUD_CLIP handle. The text encoder itself never touches your disk. It lives in the cloud, gets loaded when your job actually runs, and its weights never cross the wire.

    This is the single-encoder path. If you're running SDXL, SD3, Flux, or Hunyuan Video - anything that needs two text encoders - you want Cloud Dual CLIP Loader instead, which produces the same CLOUD_CLIP output from two clip_name slots. The pack makes you choose at load time, exactly like stock ComfyUI.

    The inputs that matter

    • clip_name - the dropdown of cloud-side text encoders, cached from the text_encoders folder (the loader also falls back to the older clip cache). Same empty-dropdown gotcha as every loader here: run Cloud List Models and restart if it shows the placeholder.
    • type - the big one. This tells the cloud how to interpret the encoder, and it needs to match the model family you're sampling. The list is the full modern roster: stable_diffusion, stable_cascade, sd3, stable_audio, mochi, ltxv, pixart, cosmos, lumina2, wan, hidream, chroma, ace, omnigen2. Grab the LTX-Video-appropriate type for an LTX chain, wan for Wan, and so on.
    • device (optional) - default or cpu, mirroring the stock loader's device pinning. You almost never need to touch it; default is the right answer.

    Output: clip (CLOUD_CLIP) - wire it into Cloud CLIP Text Encode, then into your sampler's positive and negative conditioning.

    Mechanism, in one paragraph

    Every cloud node here works the same way: it appends one node spec to an accumulating workflow dictionary and returns handles that reference it. Cloud CLIP Loader adds {"class_type": "CLIPLoader", "inputs": {...}} with your clip_name, type, and device. Nothing runs until a terminal node - Cloud Fetch Images, Cloud VAE Decode, Cloud Save Video - POSTs the whole assembled graph to /api/prompt and polls it. Your machine is a clipboard, not a render farm.

    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 use ComfyUI Manager. Only requests, Pillow, and safetensors get installed - no text encoder downloads, no gigabytes of weights.

    Common issues

    • Wrong type. The most common mistake, because it doesn't always fail loudly - the cloud loads the encoder and the job just behaves oddly. Match type to the model family you're generating with.
    • Two encoders needed? Don't force a single loader. SDXL/Flux/Hunyuan Video chains want Cloud Dual CLIP Loader.
    • PoC expectations. The whole pack is an experiment from a single author; the LTX-video example workflow is the best-tested path, so start there if you're on LTX. For everything else, budget for rough edges and check the repo's issues before you trust it with a paid run.

    And the standing reminder: this is an API-wrapper pack, so your API key lives in a config file and your prompts are shipped to a server. Install from the official GitHub, and don't point it at a machine you wouldn't trust a stranger's script on.

    Categorycloud

    Inputs (3)

    NameTypeDefaultDescription
    clip_nameCOMBO1 options: <run Cloud List Models (text_encoders) to populate>
    typeCOMBO14 options: stable_diffusion, stable_cascade, sd3, stable_audio, mochi, ltxv, +8
    deviceoptCOMBO2 options: default, cpu

    Outputs (1)

    NameTypeDescription
    clipCLOUD_CLIP