Prompt Tokens Counter (Custom)

The 77-token wall, made visible

If you've run SD 1.5 or SDXL for more than an afternoon, you know the rule of thumb: CLIP's text encoder reads prompts in chunks of 77 tokens, and anything past that gets truncated. A huge, beautiful prompt might quietly be missing its last four tags and you'd never know from the image alone. brkp_CountTokens exists to remove the guesswork - feed it your text plus the CLIP model you're actually using, and it tells you exactly how many tokens that prompt costs.

It's a small thing. But when you're balancing a long tag list against that 77-token window, "exactly 74 or 78?" is the difference between a prompt that fits and one that silently loses its tail.

How it counts

The node calls the tokenize() method on whatever CLIP you wire in, then does the bookkeeping. A few details from the source that are worth knowing:

• It counts 75 tokens per full chunk - that's the 77-token window minus the START and END tokens CLIP appends to every chunk.
• The START, END, and padding tokens are filtered out of the count entirely, so you get the "useful" token count, not the padded one.
• For SDXL it uses the CLIP-g branch's tokens. The code notes both branches share a vocabulary, so the count is the same either way - it just picks one to keep it simple.
• The total is (chunks - 1) * 75 + last_chunk_count, which is exactly how CLIP's chunking behaves in practice.

Inputs are the two that matter: clip (wire it from a checkpoint loader or CLIPLoader - you can't fake it with a text box) and text (your prompt). Outputs: count as an INT for wiring into arithmetic, and count_str as a string for display or filenames. Same number, two formats.

The honest caveat: it's a CLIP counter

This node's whole math assumes the 77-token CLIP chunking, which is true for SD 1.5, SDXL and the SDXL lineage - Illustrious, NoobAI, Pony, all of them. It is not meaningful for the newer LLM-encoded models like Flux 2, Z-Image, or Anima, where your prompt is fed to a general-purpose LLM tokenizer and there's no 77-token boundary to overflow. For those, the count the node returns is a real token count, just not one that tells you anything about truncation. Know which encoder your checkpoint uses, and you'll know whether this number matters.

Installing it

Part of the barakapa-nodes pack. ComfyUI Manager → search barakapa → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/barakapa/barakapa-nodes

Then restart ComfyUI. No models to grab, no heavy dependencies - this pack rides entirely on ComfyUI's existing install.

Where you'll actually use it

Wire count into a comparison against 75 and you can build a prompt that warns you (or routes to a different node) when you're about to overflow the window. Or just keep it in the graph as an instrument while you iterate on a long prompt, and trim tags with confidence instead of guessing. If you're an SDXL tag-tweaker, that's a real quality-of-life win; if you've moved to a newer encoder, skip it.