Text Inspector

Before you burn a full context window on a prompt you never measured, put it through VLMTextInspect. This node passes your text straight through untouched while reporting a pile of deterministic metadata about it: character count, UTF-8 byte size, word count, line count, a rough token budget, and a SHA-256 hash. It's the "am I about to blow the context window" check, and it costs nothing.

Every VLM user has been here: you build a monster prompt with embedded context, queue it, and the model returns something truncated or nonsense. The first question is always "how big was that prompt, really?" - and until you can answer it in numbers, you're guessing. This node gives you the numbers, and because the first output is the unmodified pass-through, you can drop it into an existing chain without changing anything downstream.

What you get

• text - your input, byte-for-byte unchanged. The pass-through is the point: wire this in and the node is free.
• characters, utf8_bytes, words, lines - the size facts.
• approx_tokens - a rough token budget. The pack is upfront that this is an estimate computed from UTF-8 size, deliberately labeled approximate. For exact billing or context accounting, use the target model's real tokenizer; for "should this fit in 4K?" decisions, it's plenty.
• sha256 - a stable fingerprint of the exact text. Great for checking whether a workflow's output changed between runs, or whether a cached result is safe to reuse.
• stats_json - all of the above as one JSON string, for logging or API use.

All of it is computed locally with zero network calls. No model, no tokenizer download, no telemetry - pure Python.

When you'd actually use it

The genuinely useful pattern is chaining it before a VLM or hosted API call: take the assembled prompt, pass it through VLMTextInspect, and use the approx_tokens output to drive a decision or just eyeball the number before queueing. It's also the standard debugging tool for "why is this slow / why did this fail" - a 40,000-character prompt explains a lot of both, and now you can see it at a glance instead of squinting at the widget.

If you're combining text, do it after the assembly (VLMTextJoin / VLMTextTemplate), because that's the string that actually goes to the model.

Install

Part of ComfyUI VLM Nodes (gokayfem/ComfyUI_VLM_nodes). ComfyUI Manager → search "VLM Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI_VLM_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_VLM_nodes/requirements.txt

Run with ComfyUI's Python; the repo won't touch torch. Pure text handling, no models, works anywhere.

Gotchas

The approx_tokens number is a budget, not a bill - treat it as a sanity check, and trust the real tokenizer when you're right at a model's limit. And don't be seduced into counting characters as a proxy for tokens; multi-byte characters make those diverge fast, which is exactly why the node reports both.