SeaArtLongXLClipMerge

SDXL has two encoders, and only one of them can be long

SDXL's prompt side isn't one CLIP, it's two: the small clip-L (the SD 1.5-style encoder) and the big clip-G. Long-CLIP has a trained version of the small one, and as of this writing there's still no LongCLIP-G - so you can't do the clean whole-encoder swap that SeaArtLongClip does for SD 1.5. SeaArtLongXLClipMerge is the workaround: it merges Long-CLIP-L into your SDXL's existing CLIP, keeps the original clip-G, and runs both together.

How the merge works

Under the hood it clones the CLIP you feed in - your checkpoint is never modified - then swaps the clip_l inside that clone for LongCLIP-L. The code pins the long encoder to hidden layer -2, which conveniently matches the penultimate-layer setting SDXL already conditions on by default. Your checkpoint's clip_g stays exactly as the model author intended.

The combined encoder then does something clever. It encodes your prompt with both halves, concatenates the l and g feature vectors, and trims both to the shorter token run. The tokenizer pads whichever side is shorter so both encoders see the same prompt length. Net result: the CLIP-L side gets a 248-token context, and the stack still hands ComfyUI a CLIP with the exact shape it expects.

The README is refreshingly honest about the catch: since clip-g carries more weight in SDXL, the win here isn't "my long prompts finally work." It's "noticeably more detail," because a longer CLIP-L run feeds the model more granular text signal than it's used to seeing.

Inputs and outputs

• clip_name - pick the LongCLIP-L weights file (the same models/clip dropdown as the pack's other nodes).
• clip - a CLIP input. Wire the CLIP output of your CheckpointLoaderSimple here.

Output: one CLIP. Feed it to CLIPTextEncode for both your positive and negative prompts - the same merged CLIP drives both, exactly like the checkpoint CLIP would.

Installing it

Same pack as SeaArtLongClip - ComfyUI Manager (search "ComfyUI-Long-CLIP"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/SeaArtLab/ComfyUI-Long-CLIP

Restart, then grab longclip-L.pt from BeichenZhang/LongCLIP-L and put it in models/clip (or models/text_encoders on newer ComfyUI). Not models/checkpoints - the README says that, and it's wrong; the node reads the clip folder. No extra Python deps; the pack ships no requirements.txt.

Common issues

• The clip_name dropdown won't show your file unless it's in the clip/text_encoders folder. This is the #1 support question, and it's always a misplaced file.
• Token warnings - the encoder prints "shape mismatch... embedding will be ignored" if a prompt embedding's vector doesn't match this tokenizer's dims. Your embeddings folder still loads; mismatched vectors just get skipped.
• No risk of corrupting the checkpoint - the node clones your input CLIP, so a bad experiment can't poison the model. Rerun with a different file and move on.

Worth it? If you write SDXL prompts that spill past 77 tokens, yes - and the clone-and-merge design means there's zero downside to testing. Just manage expectations: with clip-g dominating, treat this as a detail-and-quality tweak rather than a prompt-adherence revolution.