Prompt Token Counter (Text-Driven)

Prompt Token Counter (Text-Driven) is the pack's reality check. It's a terminal node with no outputs - a gauge, not a pipe - that estimates how many CLIP tokens your prompt is about to burn and paints the node green, yellow, or red so you can see trouble coming before it reaches the sampler. The threshold it's watching for is the old 75-token wall: SD 1.5 and SDXL encoders process prompts in chunks of 75 tokens (77 counting special tokens), and anything spilled into a second chunk gets attended to far less reliably. The README's way of putting it: tokens pushed past 76 can "potentially cause image degradation or generation breakdown."

How it works

One input: prompt (a string, force-input, so it wants a wire, not typing). Wire it to the same prompt source that feeds your CLIP Text Encode - in this pack's sample that's the Join Strings output - and execute. The backend runs a deliberately fast approximation: it lowercases, strips out attention weights like :1.3, chops common word endings, and counts what's left, then adds a couple of tokens for safety. The result is pushed to the UI over a websocket message, and the node repaints itself:

• ≤ 65 tokens - green, you're comfortably inside chunk one.
• 66–75 - yellow, closing in on the edge.
• ≥ 76 - red, your prompt is being sliced into a second chunk.

The author is upfront that this is an estimate, not a tokenizer: the tooltip says a strictly accurate count "requires a massive dictionary," so this is a close approximation for reference. It's usually good enough to tell you which zone you're in, which is what matters.

Where the caveat lives

This node only makes sense on CLIP-encoded models - SD 1.5, SDXL, Illustrious, Pony, and friends. On those, the 75-token chunk boundary is real and exceeding it genuinely degrades adherence. On Flux and especially on the LLM-encoded models that now dominate (Z-Image, Klein, Anima, Krea 2), there is no chunk boundary at all; your prompt is read as a whole instruction, and attention weights are discarded outright. Putting this counter on a Flux graph is measuring a wall that isn't there. Know your text encoder before you trust the color.

Also worth knowing: it's an output node with zero outputs, so you can't chain anything off it. That's fine - it's a dashboard widget. Wire it in parallel to your prompt and leave it.

Install

Comes with the ComfyUI Text-Driven Workflows pack: ComfyUI Manager → search "ComfyUI Text-Driven Workflows" → Install, or

cd ComfyUI/custom_nodes
git clone https://github.com/kanryu/ComfyUI-Text-Driven-Workflows.git

then restart. No pip dependencies, no models to download. The pack does require a current ComfyUI with the V3 extension API - on an older build you'll get "Failed to load nodes" in the console and no Text-Driven Workflows category; update ComfyUI and it comes back.

Bottom line

If you're on SDXL-lineage checkpoints and you've ever shipped a red-zone prompt and wondered why a tag stopped landing, this gives you eyes on the problem instead of guessing. It's not a replacement for actually reading your token count in an editor, but it lives right in the graph where you need it, and the color feedback is honest and immediate.