Nodes/ComfyUI illumorae/Display Token Count
ComfyUI Node

Display Token Count

How Long Is Your Prompt, Really? A Token Counter That Puts the Number on the Node

By CorvaeOboro·Created 8 months ago·Updated 2 days ago· 1
Display Token Count
  • clip
  • token_count
text
threshold700

The number ComfyUI never shows you

Prompt length is invisible in ComfyUI. Nothing on screen tells you whether that paragraph is three concepts or fourteen. On the SD 1.5 / SDXL lineage that matters a lot, because CLIP truncates at 77 tokens - everything past the window is silently dropped, and the prompt you think you wrote isn't the one you're running. The BREAK trick exists purely to work around chunk boundaries at 75.

On LLM-encoded models (Flux, Z-Image, Qwen, Anima) the hard wall is gone, but attention is still finite, and the community's read from a few hundred Z-Image generations is blunt: "past about 75-100 effective tokens the model starts to drift." The advice there is 3-5 strong concepts, not a wall of text.

Either way you want a gauge, and this node is one. It counts your prompt and draws the number big, on the node face, in grey - or red once you cross a threshold you set.

How it counts, and why the answer varies

Which number you get depends on whether you wire clip:

  • CLIP wired - it asks the tokenizer for real tokens, trying clip.tokenizer.tokenize(text) and falling back to clip.tokenize(text). That's the honest count, the one matching what your encoder actually consumes.
  • CLIP not wired - it estimates: word count plus len(text) / 4. That double-counts a typical English prompt (roughly 2.2 "tokens" per five-letter word where CLIP would spend about 1.3), so read it as a paranoid upper bound, not a measurement.

The clip input is optional and there's no error if it's unusable - the tokenizer call is wrapped in a try/except that quietly drops to the estimate. Silent fallback is the node's one real flaw: if the number looks like an estimate, it probably is one.

threshold doesn't touch the count. It's what the on-node display compares against; cross it and the digits turn red. The stock default of 700 is a "you've pasted a novel" warning - on an SDXL anime checkpoint, set it to 75 and treat red as "you just lost the tail of this prompt."

What you actually wire

text is the field you count, so make one box the source of truth: put your prompt in a string node (core's PrimitiveString/multiline primitive, or this pack's own multiline text node), then right-click the text widget on both your CLIP Text Encode and this node, choose Convert widget to input, and wire both from that one source. Now the counter measures the exact string the sampler is running, not a copy you forgot to update.

The output is token_count, a STRING - wire it to a PreviewAny/display node, a filename path, a note. It is deliberately not an integer, so you can't do arithmetic on it without a string-to-int converter from elsewhere. This node is built to be read, not computed with. It's also registered as an output node, which in ComfyUI means it always executes even with nothing wired downstream, like Preview Image. Park it in the corner as a permanent HUD and it refreshes every queue.

Installing it

Manager first: search "illumorae" and install the pack. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/CorvaeOboro/ComfyUI_illumorae

then restart. This node is completely self-contained - no model files, no downloads, no extra Python packages. If you want only it, copy the ComfyUI_illumorae_DisplayTokenCount/ folder into custom_nodes on its own; the pack's root __init__.py scans subfolders for nodes, so single-folder installs are supported here, not a hack. Keep the folder's web/*.js in place - that's what draws the number.

Where people get burned

Wiring the wrong CLIP. A count belongs to a tokenizer, and an SDXL CLIP's tokenizer and a T5 or Qwen encoder's disagree wildly on the same sentence. A count from the checkpoint's CLIP tells you nothing about how many tokens a T5-encoded model is chewing through. Wire the CLIP from the encoder you're actually prompting with, or skip it and read the estimate for what it is.

Long prompts and chunking. The node counts the first entry of whatever the tokenizer hands back - the chunk the encoder consumes first. Exactly right for "am I over the 77-token window," wrong to quote as a total for a 400-word paragraph.

Non-Latin prompts. The fallback's len(text) / 4 heuristic assumes spaces, so CJK text is badly underestimated without a CLIP wired. With a real tokenizer attached it's accurate again.

Expecting it to fix anything. It won't chunk your prompt or warn you when the model truncates - it shows you the count so you can trim, or use BREAK on a CLIP model to split a long prompt across the chunks the encoder pads for.

Trusting the pack README's node list. It still lists this node under its old name ("Text Token Count") and points at a folder that no longer exists; the class in the tree is illumoraeDisplayTokenCountNode. The code is the truth.

Categoryillumorae

Inputs (3)

NameTypeDefaultDescription
textSTRING
thresholdINT7000–99999
clipoptCLIP

Outputs (1)

NameTypeDescription
token_countSTRING