CLIP Text Compare 🔍

You've got two prompts and you think they're basically the same idea, or you're not sure how far apart they really are. CLIP Text Compare settles it with a number: it encodes both prompts with the same CLIP model, compares the pooled embeddings, and hands back a cosine similarity score between 0 and 1. No visual diffing, no guesswork - a 0.98 means "nearly identical" and a 0.4 means "these are different concepts."

This is a prompt-A/B-testing tool first and a diagnostics tool second. The classic use: you're trying to pick between two phrasings of the same subject and you want to know whether they'll behave differently before burning a queue run on each. Or you're checking whether a negative-prompt addition actually changed the semantic direction of your conditioning. A quick similarity read tells you whether you're comparing distinct concepts or wasting time on near-duplicates.

How it works

The mechanics are simple and visible. It runs both prompts through the same CLIP pipeline (tokenize → encode_from_tokens with pooled output), then computes cosine similarity between the two pooled vectors. Output is a similarity FLOAT plus a similarity_label STRING that buckets it for you: very similar (>0.9), similar (>0.75), moderate (>0.5), or different. Wire the label into a show-text node and you get a human-readable verdict without doing mental math on a float.

The useful bit is that it doesn't just give you the score. It also outputs both conditionings - conditioning_a and conditioning_b - so the node doubles as a two-way prompt encoder. You can compare two prompts, see the score, then wire whichever conditioning you liked straight into a KSampler without adding a separate encode step.

The honest caveats

Two things to keep in mind. First, similarity here is measured on the pooled CLIP embedding, which is a summary vector - two prompts that share vocabulary but differ in structure (ordering, emphasis) can score closer than you'd expect. It's a directional tool, not a truth oracle. Second, this works on the same caveat as all CLIP-era tooling: on LLM-encoded models like Flux or Z-Image the score reflects whatever those encoders produce, and the numbers aren't directly comparable to SDXL's. For the SD1.5/SDXL/Illustrious family it's solid.

One take: don't overuse it. If you're iterating visually on a single prompt, this adds nothing - you'll see the difference in the renders. Where it earns its keep is batch workflows and deciding between prompt variants before you spend the generation time.

Install

ComfyUI Manager → search OmniNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/TensorVizion/OmniNodes

Restart ComfyUI; find it under TensorVizion/Model Utilities. Pure PyTorch, no extra dependencies.