FL Clip Scanner (Kytra)

FL_ClipScanner doesn't generate anything. It's an inspector: paste in a prompt, pick which model's tokenizer you want to check it against, and it tells you exactly how that prompt gets chopped into tokens - count included. Small node, genuinely useful, and it answers a question that trips up a lot of people who've never actually looked under the hood of CLIP.

That question is the 77-token limit. CLIP text encoders - the ones behind SD 1.5, SDXL, and half of Flux's dual-encoder setup - hard-truncate at 77 tokens. Not 77 words; 77 tokens, and tokenization splits on subwords, punctuation, and weird boundaries in ways that don't map cleanly to what you typed. Go over, and ComfyUI doesn't error - it just silently truncates or chunks depending on your setup, and you never find out your carefully-tuned tail-end prompt clause never made it into the actual conditioning. FL_ClipScanner exists so you can catch that before you burn a generation on it.

The inputs are simple. model_type is an enum with three choices, and picking the right one matters because different models use genuinely different tokenizers with different vocabularies:

• SDXL (ViT-G/14)
• SD 1.5 (ViT-L/14)
• FLUX (ViT-L/14)

The Flux option is worth a beat of explanation, because Flux doesn't use CLIP the way SD 1.5 or SDXL do. Flux pairs a CLIP-L encoder (tags-style, 77-token limit, same lineage as SD's CLIP) with a T5-XXL encoder that reads the natural-language half of your prompt and has no 77-token ceiling. FL_ClipScanner's Flux mode checks the CLIP-L side only - so if you're scanning a long, sentence-style Flux prompt and it reports truncation, that's telling you about the tag-style portion your workflow feeds to CLIP-L, not about the T5 side, which can run much longer without hitting this wall.

text is just your prompt, multiline. Feed it in, run the node, and the single STRING output - which prints right on the node since it's an output node - shows you the token count and the decoded breakdown of what CLIP actually saw.

Installing it is the same as every node in this pack: search "Fill-Nodes" in ComfyUI Manager, or clone it by hand -

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

• then restart. FL_ClipScanner doesn't need a GPU or any model weights beyond the tokenizer files themselves, which are tiny and typically cache after the first load, so it's about as lightweight as this pack gets. (Its own display name in the node menu credits it to "Kytra" - a nod from the pack's author, not a separate install.)

Where people get tripped up. The most common confusion is picking the wrong model_type and being surprised by the count - SDXL's ViT-G tokenizer and SD 1.5's ViT-L tokenizer don't produce identical token counts on the exact same string, so if you're sanity-checking a prompt you're about to run on SDXL, make sure you actually selected SDXL and not SD 1.5 out of habit. And if you're running a big batch job and something looks subtly wrong in the output - a phrase that should've influenced the generation clearly didn't - run the prompt through this node first before assuming the model's ignoring you. Nine times out of ten, it's not ignoring you; the token budget ran out before it got there.