Prompt with Token Counter

Here's a failure mode that never throws an error: you write a nicely detailed prompt, queue the render, and the back half of it just... doesn't show up in the output. Nothing crashes. ComfyUI doesn't warn you. Your text encoder simply stopped listening partway through. This node exists to catch that before you burn a render finding out the hard way.

What's actually going on. Flux runs two separate text encoders, and they have wildly different budgets. CLIP-L - the same encoder family SD1.5 and SDXL use - hard-caps at 77 tokens. Go past that and it doesn't error, it just chunks or truncates, and the extra detail either gets diluted across chunks or dropped outright. T5-XXL, Flux's other encoder, is a genuine language model and handles a much longer prompt comfortably - commonly run out to several hundred tokens in practice. So the same 100-word paragraph can be totally fine in one box and quietly gutted in the other, and there's no visual cue in the UI telling you which. This node's whole job is putting a number on that before you find out from the output.

The inputs that matter:

• clip - wire in the same CLIP loader your real CLIPTextEncode node uses. If this doesn't match, the count you're staring at doesn't reflect your actual bottleneck.
• text - your prompt, multiline. Supports dynamic prompts and embeddings per the node's own description.
• model - a toggle between clip_l and t5xxl, telling the node which tokenizer to count against. Check both if you're sending different text to each encoder, which is common practice in Flux workflows (tags for CLIP, natural language for T5).

Outputs: token_count as a string, and text passed through unchanged - so you can chain this directly upstream of your real encode node instead of running it as a disconnected side-branch, and still get the live count on the way through. One detail worth knowing: the count explicitly excludes padding and special tokens, so it won't match a naive word count, and it's already accounting for the invisible tokens CLIP adds under the hood - treat the printed number as the real cost, not an approximation.

Installing it. Search "ComfyUI-42lux" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/42lux/ComfyUI-42lux

Restart ComfyUI. No models to download - this one's pure tokenizer logic, using whatever CLIP you've already loaded.

How to actually use the number. For clip_l, treat 77 as a wall, not a target - leave yourself margin rather than writing right up to it, since the number already includes the special tokens CLIP adds behind the scenes. For t5xxl, you've got a lot more room, but "more room" isn't an invitation to write an essay; a long, padded-out prompt dilutes the model's attention regardless of the hard limit, so tight and specific still beats long and vague.

Common issues:

• If your renders seem to be "ignoring" the second half of a long prompt, that's almost certainly CLIP-L truncation, not a bug in your workflow - this is exactly the node that would have told you in advance.
• Because this node is flagged as an output node, it runs and reports its count every time you queue the prompt, even if nothing downstream consumes its outputs - so don't be surprised it executes even when you've only wired the text passthrough nowhere.
• Checking the wrong encoder's count is the easy mistake: if your actual concern is your long, natural-language T5 prompt, glancing at a clip_l count tells you nothing useful about it.