Load CLIP (Quadruple)

Most models get by with one or two text encoders. HiDream I1 needed four, and that's the entire reason Load CLIP (Quadruple) exists. It's the most specialised loader in this category - a node with exactly one real use, added in April 2025 the day ComfyUI added basic HiDream I1 support, and still sitting there quietly for the handful of workflows that need it.

Why four encoders?

HiDream I1, the 17B sparse diffusion transformer that was April 2025's biggest open release, is famous for two things: exceptional prompt adherence and a brutal memory footprint. Both come from the same place - it throws four text encoders at your prompt. The node's own description spells out the recipe:

hidream: long clip-l, long clip-g, t5xxl, llama_8b_3.1_instruct

Two CLIP variants plus T5-XXL plus Llama-3.1-8B-Instruct. That's where the prompt following came from, and also where the weight came from - every one of those encoders has to be resident or swapped while the transformer runs, which is why HiDream I1 was the model that launched a thousand quantization threads.

How it works

Four required inputs, all dropdowns over models/text_encoders/:

• clip_name1, clip_name2, clip_name3, clip_name4 - pick the four encoder files. For HiDream I1, that's the long CLIP-L, long CLIP-G, T5-XXL, and Llama-8B-instruct files.

The node loads all four and fuses them into a single CLIP output. The interesting part is what you feed it into: CLIP Text Encode (HiDream), which doesn't take one prompt - it takes four, one per encoder (clip_l, clip_g, t5xxl, llama). That's the HiDream quirk made visible: the model treats them as separate voices and you address each one. In practice people typically put the main prompt in the LLM/T5 fields and keep the CLIP fields lighter.

The honest take

This is a niche node for a niche model, and the niche has a reputation. HiDream I1 was excellent at following instructions and, at 17B plus four encoders, miserable to run locally - most of its community energy went into quantizing it down to something a 16GB card could even attempt. If you're not running HiDream I1, this node is irrelevant: SDXL uses a dual loader, and the modern Flux/Z-Image line uses DualCLIPLoader or TripleCLIPLoader. But if you ever download a HiDream I1 workflow and stare at a loader with four empty dropdowns, now you know the drill: the four files, in the recipe order, from models/text_encoders/. It's the only workflow where this node makes sense - and the only place that workflow can get its text conditioning from.