SP_Name_Clip

Newer architectures increasingly load their text encoder as its own separate file rather than baked into a single checkpoint - Flux ships CLIP-L plus a separate T5-XXL file, and a growing number of 2026-era models use a standalone LLM (Qwen, Mistral-derived) as the encoder, distributed on its own. SP_Name_Clip picks one of those encoder files from your models/clip (or equivalent) folder and hands back its filename as text - no loading, no VRAM cost.

Why you'd want just the name

The main use is the same as its sibling nodes: label your outputs by which text encoder actually produced them, or drive conditional logic off the choice without paying the cost of loading a multi-gigabyte encoder file just to read its own filename. This matters more here than for some other model types, because text encoder choice genuinely changes output quality on models where it's swappable - a quantized encoder versus a full-precision one is a real, sometimes visible tradeoff - so being able to record which one was in play for a given batch is worth more than it sounds.

Inputs and outputs that matter

• name - a dropdown of whatever's in your CLIP/text-encoder folder. Enum-driven, not free text.
• Output: STRING - the selected filename.

How to install it

Through ComfyUI Manager: search "SP-Nodes," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Restart ComfyUI once it's cloned. No extra dependency - it reads your existing folder, same as the rest of the SP_Name_* family.

Common issues & troubleshooting

The dropdown is empty or missing a file you know is there. ComfyUI scans model folders at startup, so a file added while it was running won't show up until you restart. Also double-check it landed in the folder ComfyUI actually expects for CLIP/text-encoder files - naming and folder conventions have shifted as more architectures ship separate encoders, and a file in the wrong subfolder simply won't appear here.

Not sure which file is "the" CLIP for your checkpoint. That's a modeling question this node can't answer - it only reflects whatever's already sitting in the folder. If your checkpoint bakes its own text encoder in and doesn't need a separate CLIP file at all, you likely don't need this node in that part of the workflow.

Mistaking this for an actual text-encoding step. This node never runs the encoder and never produces a CONDITIONING output - it's strictly a filename picker. If you need the encoder actually loaded and applied to a prompt, that's a normal CLIP loader plus a CLIP Text Encode node elsewhere in your graph.

Picked a file that turns out to be the wrong encoder type entirely. CLIP folders can end up holding a mix of things - CLIP-L, T5-XXL, a standalone LLM encoder - that aren't interchangeable even though they all live in the same folder and all show up in this same dropdown. This node has no way to tell you which is which beyond the filename itself, so name discipline when you download these files (or checking the source page before saving) saves real confusion later.