Qwen Chat Bridge (Register CLIP)

If you work with Qwen-Image-Edit, you know the loop: describe an edit, run it, squint at the result, describe it again. The painless way to talk yourself through that loop is a chat assistant that also sees your image - but loading a second chat LLM (Ollama, LM Studio, whatever) means budgeting VRAM for two models at once, and it fights your 20B editor for the card.

Chat TE's answer is weird in the best way: you already have a language model loaded. Qwen-Image-Edit conditions through a Qwen2.5-VL text encoder, which is a 7B vision-language model sitting in VRAM doing one job. This node - Qwen Chat Bridge (Register CLIP) - hands that same model the chat's job too, and it's the piece that makes the whole pack honest about VRAM.

What it actually does

It's a CLIP → CLIP passthrough. You drop it directly after your CLIPLoader in a Qwen-Image-Edit workflow, and it registers the already-loaded CLIP as the backend for the Chat TE sidebar panel and the pack's OpenAI-compatible /v1/chat/completions endpoint. The model isn't rebuilt, copied, or duplicated - the node just says "this object is now the chat brain," then passes the CLIP through unchanged so your TextEncodeQwenImageEdit nodes keep working.

Here's why the wiring matters. If you load a text encoder from the panel directly, Chat TE shares VRAM via ComfyUI's normal offloading - no OOM, but every switch between chatting and generating reloads weights. Only this node gives you true zero-cost sharing, because one CLIP object is simultaneously the chat backend and the thing feeding your conditioning. One load, one set of weights, no reload dance. That's the whole point of reaching for the graph node instead of the panel's Load button.

The inputs and outputs that matter

This is the simplest schema in the pack - one input, one output:

• clip (required, CLIP): the output of your CLIPLoader, loaded with a Qwen2.5-VL-7B or Qwen3-VL-4B/8B text encoder. That's the only model this works with; 3B/32B/72B, non-VL Qwen3, and Qwen3-VL-32B are all rejected.
• CLIP (output, CLIP): the same object, passed through untouched. Wire it into your TextEncodeQwenImageEdit nodes.

That's it. All the actual chat control - model picker, thinking mode, max tokens, system prompt - lives in the sidebar panel, not on this node. The README's sample workflow (CLIPLoader → Qwen Chat Bridge → TextEncodeQwenImageEdit ×2) is the intended shape: bridge in the conditioning path, then chat.

How to install

ComfyUI Manager (search Chat TE), or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/ketle-man/comfyui-chat-te

Then restart ComfyUI. There are no extra Python dependencies - it uses only what ComfyUI ships. What you do need is a text encoder file in models/text_encoders/: Qwen2.5-VL-7B-Instruct or Qwen3-VL-4B/8B (.safetensors or .gguf). One catch on GGUF: it's optional, but only works if you also have ComfyUI-GGUF (city96) or gguf (calcuis) installed - and GGUF CLIPs must be loaded from the panel, not through this graph node, because the graph path skips the pack's lm_head fix.

You also need a recent ComfyUI - native CLIP.generate() text generation is new, and the pack verified against 0.33.1 (commit 72865f4). Old ComfyUI will fail with a clear message telling you to update.

Gotchas that actually bite

• "Could not find a supported Qwen language model inside this CLIP" - the README has a receipts-level warning here: some files are mislabeled. A filename that says fp16 7B can contain Qwen2.5-VL-3B inside. Verify the actual size before blaming the node.
• Thinking mode (Qwen3-VL only): leave it ON. Turning it off adds an empty <think></think> block to suppress chain-of-thought, and the author confirms that breaks generation on some tied-embedding models - Qwen3-VL-4B in particular.
• GGUF mmproj matching is filename-based and loose: a quantization-different text encoder can accidentally pair with the wrong vision tower. Both packs installed and it'll usually pick the right one, but mismatched names give you a model that can't see images.
• Rare junk token like addCriterion at the start of a reply - real, reported, cause unknown, harmless.

The one genuine trap: if your workflow loads a different text encoder than the one the chat registered, you're back to reload-on-switch. The node's promise only holds when the chat backend and the generation path share one CLIP. Wire it once, keep it that way, and you've got a vision chat that costs exactly the VRAM you were already spending.