Template Influence Analyzer

Here's a question that sounds trivial and isn't: when you slap a system prompt or a style template in front of your prompt, does it actually change the conditioning the model sees - or does it get dropped, ignored, or averaged away to nothing? TemplateInfluenceAnalyzer answers that empirically. It encodes the same test prompt under two different templates and measures whether the resulting embeddings genuinely differ. No image; just a verdict on whether your template is pulling its weight.

This is the intellectual heart of the whole pack. The repo exists to poke at modern LLM text encoders - the shift from CLIP to Qwen3/Qwen2.5-VL that quietly rewired how prompting works - and one of the least-understood knobs in that world is the system prompt. On an LLM encoder the prompt is wrapped in a chat template and read like an instruction, so in principle a system prompt should steer it. In practice, these encoders also drop a fixed chunk of leading template tokens before the real prompt begins, and it's genuinely unclear how much of your carefully-worded template survives that. Rather than guess, this node lets you measure.

How it works

You give it a clip (the loaded text encoder) and a test_prompt, then define two templates - template_a and template_b - and it encodes the test prompt under each and compares the embeddings, reporting how different they actually are. The interesting parameter is drop_idx, defaulting to 34 - the number of leading template tokens the Qwen text encoder drops, matching the token-drop count the pack documents for its encoder. That default is a real, load-bearing number, not a placeholder: it's where the encoder starts paying attention.

The inputs and outputs that matter

• clip - your loaded Qwen/Z-Image text encoder. The comparison runs through the real encoder, which is the point.
• test_prompt - the content prompt held constant across both templates so the only variable is the template itself.
• template_a / template_b (with their _name labels) - the two system prompts you're pitting against each other. The defaults compare an empty template against a cinematic one, which is a fine first experiment.
• drop_idx (default 34) - how many leading tokens to treat as dropped. Change it only if you're testing a different encoder's drop behavior; 34 is correct for the pack's Qwen path.
• run_full_comparison - do the deeper, slower analysis rather than a quick check.

Output is a single analysis_output string with the findings. Read it; don't wire it into a sampler.

How to install it

ComfyUI Manager → ComfyUI-QwenImageWanBridge → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/fblissjr/ComfyUI-QwenImageWanBridge

then restart. You need a text encoder loaded to pass into clip - the same Qwen or Z-Image encoder your generation graph uses - but no diffusion model, since nothing is sampled.

Common issues & troubleshooting

The two templates come back nearly identical. That's a real result, not a bug - it's the node doing its job. If a template barely moves the embedding, it's barely affecting your image, and you've just learned to stop paying the token cost for it. This is the most useful thing the node tells you.

Big embedding difference, no visible change in output. Embedding distance and perceptual change aren't the same thing; a template can shift the numbers without shifting the picture much. Treat this node as one input to your intuition, then confirm with actual generations.

It behaves oddly on a non-Qwen encoder. The drop_idx default of 34 is specific to the pack's Qwen encoder path. Point it at a different encoder and that number may be wrong, which will skew the comparison. And keep the usual caveat in mind: this is a research sandbox, so it's a lens for understanding your encoder, not a production step in a generation graph.