Nodes/comfyui-clip-with-break/AdvancedCLIPTextEncode with BREAK syntax
ComfyUI Node

AdvancedCLIPTextEncode with BREAK syntax

BREAK plus A1111-accurate prompt weighting

By dfl·Created 3 years ago·Updated about a year ago· 19
AdvancedCLIPTextEncode with BREAK syntax
  • clip
  • CONDITIONING
text
token_normalization
weight_interpretation

This is the node to reach for when you're not just missing A1111's BREAK keyword - you're missing A1111's math. Plain ComfyUI weighting and A1111's (word:1.3) don't compute the same number under the hood, so a prompt that looked right in one can render noticeably different in the other. This node gives you BREAK segmentation and a choice of weighting formulas in one place, so you can actually match what you're porting from instead of eyeballing it.

Why it's the "advanced" one

Its plain sibling, CLIPTextEncodeWithBreak, splits your prompt on BREAK and runs each piece through ComfyUI's stock encoder. This node does the same split, but each fragment goes through advanced_encode() instead - logic ported straight from BlenderNeko's well-known ComfyUI_ADV_CLIP_emb pack (the README credits it directly, and the code is vendored into this repo rather than pulled in as a separate dependency, so you don't need to install that pack too). That's where the two extra controls come from: which formula turns (word:1.3) into an actual attention multiplier, and how to keep separate BREAK segments from throwing each other's magnitude off.

How it works

Same split-and-concat mechanism as the basic node - divide on the word BREAK, encode each fragment, chain the results - but each fragment's encoding now runs through the configurable path. Weighting math differs across tools: ComfyUI's own default, A1111's, the compel library's, and a couple of variants, all compute (word:1.3) differently. On top of that, boosting a word's weight also changes the overall magnitude of that segment's embedding, which is exactly the kind of imbalance that can make one BREAK block dominate or fade relative to the others - token normalization is the correction for that.

The inputs and outputs that matter

Four required inputs:

  • text - your prompt, with BREAK splitting it into sections, same as the basic node.
  • clip - the CLIP model to encode with.
  • weight_interpretation - which math converts (word:1.3)-style syntax into an actual multiplier. Choices are comfy (ComfyUI's own default - leave it here unless you have a reason not to), A1111, compel, comfy++, and down_weight. Pick the one matching whatever tool you're porting a prompt from; if you're not porting from anywhere in particular, comfy is the sane default.
  • token_normalization - whether and how to renormalize each segment's embedding after weighting: none, mean, length, or length+mean. If a heavily-weighted word is making one BREAK block overpower the rest of the image, this is the knob to try before touching the weight itself.

One output: CONDITIONING, feeding your KSampler exactly like any other encode node.

How to install it

Both nodes ship in the same pack, so there's one install for both. Via ComfyUI Manager: search "comfyui-clip-with-break" and install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/dfl/comfyui-clip-with-break

Restart ComfyUI. No extra pip installs and no models to fetch - the advanced-encoding logic is plain Python living inside this repo.

Common issues & troubleshooting

Same caveat as the basic node, and it matters more here. BREAK and CLIP-specific weighting syntax are both tools for CLIP's 77-token chunking behavior. On Flux, Z-Image, Anima, or any other LLM-encoded model, (word:1.3)-style weights aren't discarded gracefully - they're fed to the encoder as literal punctuation inside your prompt, which is worse than not writing them at all. This node is for SD 1.5, SDXL, Illustrious, NoobAI, and Pony-style checkpoints, not for anything with a Qwen or T5 text encoder under the hood.

Don't touch weight_interpretation unless you're actually porting something. It's tempting to try every option to see what changes, but the point of the setting is fidelity to a specific external tool's math, not a general "quality" dial. If you wrote the prompt fresh in ComfyUI, comfy is already correct for it.

Flat or washed-out results after weighting a word up. Try mean or length+mean normalization before you start second-guessing your weights - an unnormalized boost can throw off that whole BREAK segment's magnitude relative to the others, which reads as one block "winning" over the rest of the prompt.

Looking for full A1111 parity - alternating words, more exotic syntax? This pack covers BREAK and weighting, not everything A1111 does. If you need the complete set, the community's other go-to is ComfyUI_smZNodes, though that one asks you to switch your whole encoding pipeline to its way of doing things rather than sitting on top of native ComfyUI conditioning the way this node does. Which trade-off you want depends on whether you're porting one prompt or your entire workflow.

Categoryconditioning/advanced

Inputs (4)

NameTypeDefaultDescription
textSTRING
clipCLIP
token_normalizationCOMBO4 options: none, mean, length, length+mean
weight_interpretationCOMBO5 options: comfy, A1111, compel, comfy++, down_weight

Outputs (1)

NameTypeDescription
CONDITIONINGCONDITIONING