⬡ Polyhedron Token Counter
How close is your prompt to the 512-token wall? This one counts.
- clip
- latent
- report
- positive_tokens
- negative_tokens
- over_limit
- trigger_tokens
Here's a failure mode that produces no error at all: WAN's UMT5-XXL text encoder has a hard 512-token limit, and when you exceed it, the prompt just gets truncated. Silently. The last LoRA trigger, the careful style block, the motion description - the end of your prompt simply never reaches the model, and you're left staring at output that "ignored" half your prompt with no crash to blame. The Polyhedron Token Counter exists to make that visible.
It's a diagnostic utility: you give it a prompt (or two), it counts tokens against the text encoder's limit, and it tells you how close you are. Set model_limit to match your target: 512 for WAN 2.1/2.2 (UMT5-XXL) and FLUX (T5-XXL), 75 per CLIP chunk for SDXL. Leave it at 512 for WAN. warn_threshold is the fraction of the limit where it starts shouting - 0.90 means "warn at ≥460 of 512 tokens", which is where you actually need to hear about it, because truncation is silent.
The inputs that matter
positive_promptandnegative_prompt- the prompts to count. You can wire these from the pack's CLIP Text Encode (positive_text/negative_text), which is the natural pairing.trigger_words- optional, and the interesting one. Wire the LoRA Stack'strigger_wordsoutput here and you see how much of the budget the auto-collected triggers alone consume. That's diagnostic gold in a 15-LoRA stack: if your triggers eat 300 tokens before you type a word, you will lose the end of your own prompt.
Outputs: report (a readable summary → Show Text), positive_tokens and negative_tokens (INT), over_limit (BOOLEAN - drive a warning with it), and trigger_tokens.
The node also distrusts its own inputs, which is a nice touch: if trigger_words is handed a serialized config string instead of actual triggers, it says so on the number itself rather than printing a count it doesn't believe. Same spirit as the CLIP Text Encode's footer - this pack treats token counts as a promise, and the two nodes share the same counting function so they can't disagree.
Installing it
It's part of the Polyhedron Suite pack, one install for everything:
cd ComfyUI/custom_nodes
git clone https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack.git
# restart ComfyUI
Or ComfyUI Manager, search "Polyhedron Suite". No dependencies. It's a plain-widget node, so it renders fine under the new "Modern Node Design" renderer.
The practical habit to build: wire it into your working WAN graph and glance at over_limit before every long queue. Truncation isn't a bug you can catch by reading output - the output always looks like a prompt. It just isn't yours.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| model_limit | INT | 51264–8192 | YOUR token budget -- a self-set guide rail, not the encoder's cap. Measured against core v0.32.0, no modern text encoder truncates: 512 on WAN is a pad FLOOR. Wire `clip` and the report names the real limits. 512 is still the right number for kijai's WanVideoWrapper, whose buffer really is fixed. Old guidance: SDXL = 75 per CLIP chunk. Leave at 512 for WAN. |
| warn_threshold | FLOAT | 0.900.5–1 | Fraction of the limit at which to warn. 0.90 means warn at ≥460 of 512 tokens. |
| positive_promptopt | STRING | Positive prompt to count. | |
| negative_promptopt | STRING | Negative prompt to count. | |
| trigger_wordsopt | STRING | Optional: wire the Stack's trigger_words output here to see how much of the budget the auto-collected triggers alone consume. Diagnostic only — these are normally already part of the positive prompt, so they are NOT added to over_limit. | |
| clipopt | CLIP | Optional but recommended: the same CLIP that encodes this prompt. The count then comes from the tokenizer that will actually run -- exact for WAN, MiniMax H3, Flux2 and everything else -- and the report names that encoder's REAL limits instead of assuming WAN's. Without it the node falls back to UMT5-XXL, which is only correct for WAN. | |
| latentopt | LATENT | Optional, MiniMax H3 only: wire the same latent the sampler gets. H3 puts text and video on ONE position axis, so the prompt's length decides where the video sits on it. With the latent the report says how far the prompt pushes the clip -- the only 'too long' that means anything on H3, since its encoder never truncates. |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| report | STRING | — |
| positive_tokens | INT | — |
| negative_tokens | INT | — |
| over_limit | BOOLEAN | — |
| trigger_tokens | INT | — |