Conditioning Token Count (CCN)

The CLIP era had one number everyone knew: 77 tokens, and past it your prompt got chunked. Then LLM-encoded models showed up and threw that out - Qwen-encoded models don't have a hard 77-token boundary, and "how long is my prompt actually" became a real question again. Conditioning Token Count (CCN) answers it the honest way: it reads the sequence length straight off the conditioning tensor - the actual number of token positions your encode produced - and shows it on the node. No tokenizer guessing, no character estimates. It measures what you actually generated.

How it works

ComfyUI conditionings are [batch, sequence_length, embedding_dim] tensors, so the sequence length is just shape[1]. The node reads that, reports it as an INT, and also emits an info string with the hidden dim and full shape. It takes a conditioning (not text), so it works for any encoder - CLIP, T5, Qwen, vision-conditioned pipelines like Krea2 - because it's measuring the tensor, not re-tokenizing your words. debug prints the same info to the console. It's marked an output node, so the result shows up in the UI.

Why you'd reach for it

Pair it with the pack's token-counter or your own prompt experiments and you can see how long conditionings actually are per model - which matters when you're writing long prompts and want to know whether you're feeding the model 40 tokens or 400. Community wisdom on LLM-encoded models is that attention cap is real (drift past roughly 75–100 effective tokens), so knowing your real sequence length is a genuinely useful debugging data point. It's also handy for comparing two conditionings before you lerp or subtract them - the pack's own nodes handle mismatched lengths, but it helps to know they're mismatched.

Install

Standard for this pack. ComfyUI Manager → search ComfyCollectorNodes → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/valkymaera/ComfyCollectorNodes

Restart, no pip step. It's under the (CCN) suffix.

The honest note

This is a measure-and-read node - it tells you the token count of the conditioning you have, which is not the same as the token count of the text you typed (padding, BOS/EOS, chunking all show up in the tensor length). For per-encoder content counts you want the pack's Token Counter, which takes text and tokenizes it properly. And since it only needs the conditioning, it's the one you drop on an existing workflow without touching the prompt side. Small, specific, and it does exactly what it promises - no more, no less.