CLIPTextEncodeSDXL (auto-split-and-merge)

CLIP's text encoder only reads 77 tokens at a time. SDXL has two of them (CLIP-L and CLIP-G), and if your prompt runs long, the stock encoder does the dumb thing: it chops at the hard 77-token boundary, wherever that lands, and the last chunk of your carefully-written prompt becomes a stub or just gets dropped. This node is a drop-in replacement for the stock SDXL text encoder that splits the text before tokenization, at sensible boundaries, and lets you choose what happens to the resulting chunks.

It ships in the unified-conditioning-merge pack from RandyHaylor - a bit of a weird home for a text encoder, but the pack is really "prompt/conditioning choreography," and this is the prompt end of it.

How the splitting works

The node does its own text splitting before tokenizing, which avoids the classic "tiny last chunk" problem - a 4-token tail gets wildly over-weighted in average mode and looks broken in combine mode. Split marker priority, highest first:

1. BREAK - uppercase whole word, same convention as A1111/Forge. Hard boundary.
2. comma ,
3. line break \n
4. any whitespace
5. character force-split (last resort)

Each BREAK-separated segment gets split into roughly equal 75-token chunks via greedy bin-packing, so no chunk is ever a sad orphan.

The two dropdowns

split_and_merge_g and split_and_merge_l control what happens per CLIP stream, each with concat / truncate / combine / average:

• concat (default) - feeds all chunks to one encode call, returns one CONDITIONING entry. This matches stock SDXL's own long-prompt handling, so the default is safe.
• truncate - keep only the first 77-token chunk; drop the overflow.
• combine - each balanced piece becomes a separate CONDITIONING entry (parallel branches the sampler handles independently).
• average - encode each piece, then blend token tensors and pooled outputs into one entry.

If the two streams disagree, the highest-priority mode wins and dictates the whole pipeline: combine > average > concat > truncate. So g=combine, l=concat runs the combine pipeline, not a weird hybrid. And whichever pipeline runs, the shorter stream gets padded to match - same logic as the stock encoder.

Inputs and outputs that matter

Inputs: clip, the usual SDXL size fields (width, height, crop_w, crop_h, target_width, target_height), text_g and text_l, plus the two dropdowns above. Outputs:

• conditioning - wire to your sampler's positive or negative.
• debug_info (STRING) - how many balanced pieces per stream, the modes, per-pair token counts, and the reduction strategy that actually ran. Wire it into a ShowText node; it's the only way to know whether your "average" actually averaged.

Install

ComfyUI Manager → search "Unified Conditioning" or "auto-split-and-merge". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/RandyHaylor/unified-conditioning-combine-with-timestep-range.git unified-conditioning-merge

Restart ComfyUI; the node lives under the unified-conditioning-merge category. No models to download, no extra pip deps.

Troubleshooting

• If you just want stock behavior, leave both dropdowns on concat - it's deliberately the default because it reproduces the stock encoder.
• combine produces a multi-entry conditioning, which is parallel-branch territory. Don't feed that into a flat concat-style merge downstream, or you'll hit the pack's blocked-configuration error.
• Use debug_info. Guessing which pipeline ran is how you burn an hour. It tells you exactly what happened, chunk by chunk.