ComfyUI Node

AIHub Utils Load CLIP

A CLIP loader you can drive with a string — and it remembers what it loaded

By otavanopisto·Created about a year ago·Updated 22 days ago· 7
AIHub Utils Load CLIP
    • CLIP
    clip_1
    clip_2
    typestable_diffusion
    devicedefault

    ComfyUI's built-in CLIP loader asks you to pick a file from a dropdown at graph-build time. AIHubUtilsLoadCLIP, from the otavanopisto ComfyUI-aihub-workflow-exposer pack, takes the file as a string input instead. That one change is the whole reason the node exists: a string can be built at runtime from an expose, a stored file, a selection dropdown - anything. The author's README is blunt about the motivation: "The reason it exists as a separate utility is that it takes a string as the input, ensuring that you can dynamically load this from stored files or exposes, or so on."

    The second feature is caching. Load a CLIP once and the node keeps it in memory across workflows - the source tracks the last-loaded file, type, and whether it was a dual clip, and reuses the object instead of re-reading the file from disk. For a client app that runs workflows repeatedly with the same text encoder, that's a real speedup.

    The inputs that matter

    • clip_1 - the text encoder file as a string (empty means "don't load").
    • clip_2 - an optional second encoder; give both and the node builds a Dual CLIP, which is how SDXL pairs its two encoders and how some modern model stacks merge two text encoders.
    • type - the big one to get right. The dropdown has 18 entries covering the modern landscape: stable_diffusion, sdxl, sd3, flux, stable_cascade, stable_audio, mochi, ltxv, pixart, cosmos, lumina2, wan, hidream, chroma, ace, omnigen2, qwen_image, hunyuan_video. The type has to match your model family - a Flux model wants flux, an LTXV video workflow wants ltxv, and getting this wrong means garbled or broken conditioning, not a clean error.
    • device - default or force cpu. The CPU option is there for workflows where you want the text encoder off the GPU, which matters on tight VRAM.

    Output: a single CLIP, ready for a CLIPTextEncode.

    How it works under the hood

    The source routes to ComfyUI's CLIPLoader for a single file or DualCLIPLoader for two, and it's GGUF-aware - if the file lives in the model_gguf folder it uses the GGUF clip loader instead (worth knowing if you're running quantized text encoders, which have been a fixture of the ecosystem since GGUF jumped species in 2024). It caches based on file + type, so switching types invalidates the cache.

    Gotchas

    An empty clip_1 silently loads nothing - the source just prints "No CLIP specified" and returns None. That's a foot-gun in a dynamic workflow: a client sends a blank string and downstream conditioning fails in confusing ways, so validate that string upstream. And the type cache means that if you load the same file with two different types in one session, you'll get the cached (possibly wrong) object - restart or use distinct files to dodge it.

    Install

    No Python requirements, nothing to download - the pack runs on ComfyUI's own internals:

    cd ComfyUI/custom_nodes
    git clone https://github.com/otavanopisto/ComfyUI-aihub-workflow-exposer
    

    Restart ComfyUI. If you're building an AIHub workflow where the client picks a model family at runtime, this is the loader that makes the text encoder follow along.

    Categoryaihub/utils

    Inputs (4)

    NameTypeDefaultDescription
    clip_1STRINGThe CLIP to load
    clip_2STRINGThe Second CLIP to load, if given, a Dual CLIP will be created
    typeCOMBOstable_diffusionThe type of the CLIP to load
    deviceCOMBOdefaultThe device to load the CLIP on

    Outputs (1)

    NameTypeDescription
    CLIPCLIP