π FW Count Tokens
Find out how many tokens your prompt is actually using
- clip
- INT
If you're running a CLIP-based checkpoint - SD 1.5, SDXL, Illustrious, Pony, NoobAI, anything in that lineage - your prompt has an invisible ceiling: 77 tokens per CLIP chunk. Go over it and nothing crashes, nothing warns you. CLIP just truncates the tail and quietly stops reading. The back half of your carefully written prompt never makes it to the model. CountTokens is the fix for not knowing where that ceiling actually is: feed it your CLIP model and your prompt text, and it tells you the real token count, not a word-count guess.
That "not a guess" part matters. Words and tokens aren't the same thing - CLIP's tokenizer splits on subwords, so a longer or unusual word can cost two or three tokens on its own, while short common words are often one. Eyeballing a prompt and estimating "that's probably under 77" is exactly how people get silently truncated. CountTokens runs the actual tokenizer from the transformers library against your actual loaded CLIP model, so the number it gives you is the number that will really apply at encode time - not an approximation.
How it works
You wire in the CLIP model you're already using elsewhere in your graph (from a checkpoint loader or CLIPLoader) and the text string you want checked. The node tokenizes that string with CLIP's own tokenizer and counts the tokens. That's the whole job - it doesn't touch your prompt, doesn't encode anything for sampling, it just measures.
The inputs and outputs that matter
There are only two inputs, both required:
clip(CLIP) - the same CLIP model yourCLIPTextEncodeis using. It has to be the actual model in your pipeline, since different CLIP variants tokenize slightly differently.text(STRING) - the prompt (or any string) you want measured.
The output is a single INT - the token count. Wire it into a text/int preview node to read it, or use it as a gate elsewhere in your graph if you want to branch on "is this prompt too long."
How to install it
Two ways, same result:
- ComfyUI Manager - search for "Fearnworks Nodes" and install.
- Manual:
then restart ComfyUI.cd ComfyUI/custom_nodes git clone https://github.com/fearnworks/ComfyUI_FearnworksNodes
That's it per the pack's own README - no requirements.txt step, no model downloads. It's a small utility pack (four nodes total, split between text/token tools and one file-system node) that piggybacks entirely on the CLIP model you've already loaded, so there's nothing extra to fetch.
Common issues & troubleshooting
It's silent (or meaningless) on modern LLM-encoded checkpoints. Flux, Z-Image, and other models using a T5 or general-purpose LLM text encoder don't have the 77-token CLIP chunk ceiling at all - there's no comparable truncation point to measure against. CountTokens is a CLIP-era tool for CLIP-era checkpoints; if you're on one of the newer LLM-encoder models, this node isn't the one you need.
The author's own caveat: tested on SDXL 1.0 only. The README explicitly notes it hasn't been validated on 1.x models and that "an additional switch is needed" to handle them properly. If you're running SD 1.5 and the count looks off, that's a known, stated gap rather than something you're doing wrong - worth double-checking the number against your own expectations before trusting it blindly on 1.x.
Node doesn't show up after cloning. Standard custom-node checklist: make sure you did a full ComfyUI restart (not just a browser refresh), and check the console log on startup for an import error from ComfyUI_FearnworksNodes - that's where a failed load will actually surface.
Pair this with TrimToTokens once you know you're over budget, or TokenCountRanker if you want to see which part of the prompt is the actual culprit instead of just the total.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | β | |
| text | STRING | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| INT | INT | β |