GGUF DualCLIP Loader

A lot of modern architectures don't run on one text encoder - they run on two, stitched together. Flux pairs a CLIP-L with T5-XXL; SDXL pairs CLIP-L with OpenCLIP-G. GGUF DualCLIP Loader is what loads both files and combines them into the single CLIP your sampler expects, and it'll take gguf or safetensors versions of either file.

Why two encoders

This isn't a GGUF-specific quirk - it's how these architectures were built from the start. One encoder tends to carry style/composition-level understanding, the other carries stronger language grounding for detailed prompts. SDXL's CLIP-L + OpenCLIP-G split set the pattern; Flux swapped the second slot for T5-XXL, which is why Flux prompts respond so much better to natural language than SD1.5-era ones did. The type selector on this node is what tells the loader which pairing convention it's looking at.

Inputs and outputs

• clip_name1, clip_name2 - the two encoder files. Order matters for some architectures, so match whatever convention your specific type expects rather than assuming it's arbitrary.
• type - the architecture pairing: sdxl, sd3, flux, hunyuan_video, hidream, hunyuan_image, hunyuan_video_15, kandinsky5, kandinsky5_image, ltxv, newbie, ace. Twelve options - pick the one matching your diffusion model, not either encoder file individually.
• device (optional, default / cpu) - forces the combined encoder onto CPU. Since text encoding only happens once per prompt rather than every sampling step, this is close to a free VRAM win if you're tight on it.

Output: one CLIP, wired into CLIP Text Encode the same as any single-encoder setup - the dual-loading is invisible downstream.

Installing it

ComfyUI Manager: search gguf, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/calcuis/gguf

No extra pip installs on the current version - the decoding engine ships with the node. Both encoder files go in ComfyUI/models/text_encoders, same folder regardless of which one is gguf and which is safetensors.

Common issues

Wrong type doesn't crash, it just quietly breaks output quality. This is the trap with this node specifically - picking the wrong architecture pairing usually still runs; you just get conditioning that's subtly or badly mismatched with what your diffusion model expects, and it looks like a bad prompt or bad model rather than a config error. If output quality tanked right after touching this node, check type before anything else.

Mixing this pack's loader with another GGUF pack's files. calcuis's gguf and city96's far more widely used ComfyUI-GGUF are separate codebases that happen to read the same file format - they're not guaranteed interchangeable. There are real reports of a text encoder loading cleanly through one pack's nodes and throwing a hard int64-type error when the same or a related file gets run through the other pack's loader instead. If you're mixing GGUF packs in one workflow and hit a type error on a text encoder specifically, that's a known friction point - try loading that particular file with the same pack's own loader end to end.

Clip order swapped. If output looks wrong specifically for clip_name1/clip_name2 but the type is right, double-check you haven't put the two files in the wrong slots - not every type treats the two positions symmetrically.

Empty dropdowns. Files aren't in text_encoders, or were added after ComfyUI was already running - restart to pick up new files.