TESTNODE_TOKEN ♾️Mixlab

Like its neighbor TESTNODE_, this one sits in the pack's "Test" category, has no description on the node itself, and gets no mention anywhere in the README or changelog. Treat it the same way: almost certainly an internal tool the author uses while developing the pack's prompt and text-encoding nodes, left visible in the public node list rather than built as a feature for end users.

What sets it apart from the plain TESTNODE_ is its signature, which is specific rather than a wildcard: it requires text (a STRING) and clip (a CLIP model), and returns a single STRING. That combination - raw text paired with a loaded CLIP model, feeding out a string - is the shape of a tokenization check, not a generation or encoding step. Mixlab ships several prompt-focused nodes elsewhere in the pack (PromptSlide with its per-token weighting, ChinesePrompt for translating and encoding non-English prompts), and a node that takes exactly text plus a CLIP model and hands back a string is a very plausible internal harness for checking how a given piece of text actually tokenizes or encodes against a given CLIP before wiring that logic into one of those user-facing nodes.

That said, the node's own description is blank, so treat the paragraph above as an informed read of the schema rather than a documented spec - there's no way to confirm from the README what the output string actually contains (a token count, the tokenized sequence, an echo of the input) without opening the pack's source directly. If precise tokenization behavior for your prompt matters to your work, a dedicated, well-documented tool built for that job - or checking against ComfyUI's own CLIP Text Encode behavior directly - is the more reliable path than leaning on an undocumented test node.

Install is the pack-wide standard:

cd ComfyUI/custom_nodes
git clone https://github.com/shadowcz007/comfyui-mixlab-nodes.git
cd comfyui-mixlab-nodes
install.bat

or via ComfyUI Manager (search "comfyui-mixlab-nodes"), or pip3 install -r requirements.txt in a venv. No dedicated model download for this node itself - it needs a CLIP input, which means loading a checkpoint that provides one, same as any prompt-encoding node.

There isn't much of a troubleshooting story for a node this undocumented - if it errors, the most likely cause is simply a missing or mismatched clip input, the same failure mode as any node that requires one: make sure you've got a checkpoint loader (or CLIP loader) actually feeding it a valid CLIP object rather than leaving that socket unconnected. Beyond that, if you're here because this node showed up unexpectedly while browsing the pack's node list, that's expected - it's registered the same as every other Mixlab node, it's just not one that was ever meant to headline a workflow.