⬡ Polyhedron Load CLIP

One text-encoder loader for one to four encoders — and it checks the family before loading

By PolyhedronAI·Created 3 months ago·Updated a day ago· 2

model

clip
info

◄clip_name▾►

◄typeauto►

◄devicedefault►

◄clip_name_2— none —►

◄clip_name_3— none —►

◄clip_name_4— none —►

⬡ Polyhedron Load CLIP is a text-encoder loader that replaces the separate single/dual/triple/quadruple loaders with one node, and adds the check the others skip. Instead of a hard-coded table of encoder types, the type list is read from the ComfyUI installation that's actually running - so when core learns a new text-encoder family, this node knows the day you update, not the day the pack author gets around to it.

What beginners notice first is the self-sizing: a slot appears only once the one before it is filled. Load one encoder and the node is small; load four and it grows. That matches how the encoders actually behave - a slot you fill isn't an either/or, it's an addition. Slot 1 plus slot 2 is what core's dual loader does, and so on up.

How it works - the part that saves you a debug session

Before any weights are read, each file is identified from its safetensors header and checked against the expected recipe. A wrong combination - say, a t5xxl where an SDXL pair expects clip_l + clip_g - fails immediately and by name, instead of loading happily and surfacing as garbage conditioning three nodes downstream where nothing points back to the encoder. That "fail early, name the culprit" behavior is the real value of this node over the stock loaders.

type defaults to auto: connect a model and the encoder family is read from it. The filename alone can't carry this - the same t5xxl file serves sd3, Flux, and LTXV - so "auto" only resolves unambiguous filenames and otherwise asks you to pick rather than guessing.
With three encoders, ComfyUI always builds sd3 (clip_l + clip_g + t5xxl) and ignores type; with four, it builds hidream (long clip_l + long clip_g + t5xxl + llama). The count decides, and the node's readout says so.
device - set cpu to keep the encoder off the GPU; applies to every loaded encoder. Real VRAM relief on 14B video workflows where the text encoder would otherwise compete with the UNet.

What comes out

clip (CLIP) - the loaded text-encoder stack, a native CLIP type that wires into any encode node.
info (STRING) - a readout naming each file, the resolved type, device, size, and what each slot was identified as. Wire it into a note for a "what's loaded" panel.

Installing it

Part of the ⬡ Polyhedron Suite pack. ComfyUI Manager → "Polyhedron Suite", or:

cd ComfyUI/custom_nodes
git clone https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack.git
# restart ComfyUI

No extra dependencies.

Gotchas

The most common trip: wiring a model into model but expecting type to magically resolve for multi-encoder setups - auto needs a single unambiguous family, and for three/four-encoder graphs the count wins regardless. And if you move the encoder to CPU, remember it affects all loaded encoders, which is what you want but is worth stating. As with the rest of the pack, a blank-looking node under Nodes 2.0 (Modern Node Design) is the renderer, not your workflow - disable it in Settings and the node redraws.

CategoryPolyhedron/Loaders

Inputs (7)

Name	Type	Default	Description
clip_name	COMBO		Text encoder file (models/text_encoders).
type	COMBO	auto	Encoder architecture. The list is pulled live from core CLIPLoader AND DualCLIPLoader, so new types appear after a ComfyUI update. 'auto' (default): connect the model and the family is read from it; otherwise only unambiguous filenames resolve. Never guesses -- it errors and asks you to pick. With THREE or FOUR encoders this field is ignored: ComfyUI derives the family from the count alone (3 = sd3, 4 = hidream), and the readout says so.
device	COMBO	default	cpu keeps the encoder off the GPU (VRAM relief). Applies to every loaded encoder.
modelopt	MODEL		Optional: with 'type = auto' the encoder family is resolved FROM THIS MODEL -- swap the model and the CLIP type follows. The filename alone cannot carry this (t5xxl serves sd3, flux, ltxv, ...).
clip_name_2opt	COMBO	— none —	Text encoder 2. Encoders load TOGETHER -- this is not an either/or switch; slot 1 plus this one is what core's dual loader does. Order does not matter, each file is identified by its own weights.
clip_name_3opt	COMBO	— none —	Text encoder 3. With three encoders ComfyUI always builds sd3 (clip_l + clip_g + t5xxl) and ignores the 'type' field -- the count decides.
clip_name_4opt	COMBO	— none —	Text encoder 4. With four encoders ComfyUI always builds hidream (long clip_l + long clip_g + t5xxl + llama) and ignores the 'type' field -- the count decides.

Outputs (2)

Name	Type	Description
clip	CLIP	The loaded text encoder stack (native CLIP type).
info	STRING	Readout: files \| resolved type \| device \| size \| what each slot was identified as.