☁️BizyAir Load CLIP

Most of the time you get your CLIP for free, bundled into a checkpoint loader's clip output. This node exists for when that's not true - when you're working with a base model that ships its text encoder(s) as separate files rather than baked into one checkpoint, which is the norm for anything Flux-family, SD3-family, or newer. It's BizyAir's cloud equivalent of ComfyUI's stock "Load CLIP" node: pick an encoder file, tell it what architecture to interpret those weights as, and get back a BIZYAIR_CLIP you can feed into a text-encode node further down the chain.

The one field that actually matters is type. Text encoders aren't interchangeable across architectures - a CLIP-L file means something different loaded as "stable_diffusion" versus loaded for "sd3" or "hidream," because different architectures condition on different layers, combine multiple encoders differently, or expect a completely different encoder family (T5, an LLM like Qwen, whatever). Pick the wrong type and you won't get an error, you'll get conditioning that's silently wrong - garbled or ignored prompts, not a crash. The dropdown here covers a wide spread: stable_diffusion, stable_cascade, sd3, stable_audio, mochi, ltxv, pixart, cosmos, lumina2, wan, hidream, chroma, and a couple more beyond that. Match it to whatever base model you're actually building a graph around - check that model's own docs or example workflow rather than guessing, since this list spans several genuinely different text-encoding schemes wearing the same dropdown.

clip_name is, like everything else in this pack, a pick from BizyAir's cloud catalog rather than a file on your disk - sample entries include things like t5xxl_fp16.safetensors, clip_l.safetensors, and umt5_xxl_fp8_e4m3fn_scaled.safetensors, which tells you the catalog covers both classic CLIP checkpoints and the heavier T5/UMT5 encoders that Flux- and Wan-class models lean on. There's also an optional device switch (default or cpu) - on a normal local setup this is the classic VRAM-saving move of keeping the text encoder off the GPU while the diffusion model runs on it, since text encoders can be several gigabytes on their own. Here, since the actual weights live on BizyAir's servers rather than your machine, don't expect it to change anything about your own hardware usage - it's there because this node mirrors the stock loader's shape, not because your local VRAM budget is what's being managed.

Output: a single BIZYAIR_CLIP, which only plugs into other BizyAir nodes - a downstream conditioning/text-encode node, most likely, not a stock CLIP Text Encode. Same type-boundary rule as the rest of the pack.

Install: search "BizyAir" in ComfyUI Manager and install, git clone https://github.com/siliconflow/BizyAir.git into custom_nodes and restart, or comfy node install bizyair. It's one pack install, not a per-node download - and you still need a registered BizyAir account with your API key set before this loader's catalog dropdown will populate or run at all.

Where this trips people up: picking the wrong type for your base model is the single most common mistake, and because it fails silently, the symptom looks like "my prompt isn't doing anything" rather than an obvious error - if that happens, double-check the type against whatever model you're pairing this with before you start second-guessing your prompt wording. Beyond that, treat any stall or generic failure notice the same as elsewhere in this pack: check your API key first, since an unauthenticated node just can't reach the catalog or run the encode.