BMAB Prompt

If you've ever pasted a prompt from CivitAI into ComfyUI's stock CLIP Text Encode and had (masterpiece:1.4) behave differently than it did in the screenshot, this node is the fix. ComfyUI's native prompt weighting doesn't parse things exactly the way Automatic1111, SDXL's own conventions, or Compel do - they're genuinely different parsing and normalization rules dressed up in similar-looking ()/[]/:1.2 syntax. BMAB Prompt lets you pick which ruleset to interpret your prompt with, so text written for one ecosystem actually means what its author intended in another.

This isn't a BMAB-original idea - it's the same reasoning Fooocus's author gave for deliberately adopting "A1111's prompt-emphasis normalisation... so prompts pasted from CivitAI behave as written." Different tool, same underlying problem: prompt weighting syntax looks portable and isn't, and enough of the ecosystem's prompt-sharing culture assumes A1111 semantics that a translation layer earns its keep.

How it works

It's a BMAB bind-consuming node like the pack's other sampler-category entries - it reads the bind, encodes your text under the interpretation rules you pick, and writes the result back into the bind for whatever samples downstream. weight_interpretation picks the parsing dialect: original (ComfyUI's own default), sdxl, comfy, A1111, compel, comfy++, and down_weight. token_normalization controls how the resulting embedding magnitude gets rescaled after weighting is applied - none, mean, length, or length+mean - which matters because pushing a token's weight up or down changes its magnitude relative to the rest of the prompt, and normalization decides whether that gets corrected back toward a consistent scale or left as-is.

The inputs and outputs that matter

• bind (required) - the pipeline object from BMAB Import Integrator or upstream.
• text (multiline, required) - your prompt, written in whatever weighting syntax matches the weight_interpretation you select.
• weight_interpretation (enum, required) - pick the dialect that matches where the prompt came from. If it's a CivitAI-sourced prompt with (word:1.3) syntax, A1111 is almost always the right choice.
• token_normalization (enum, required) - mean or length+mean are the common picks when you have several heavily-weighted terms and don't want the strongest one to dominate disproportionately.
• Output: bind - pass to the next BMAB node.

How to install it

ComfyUI Manager: search comfyui_bmab. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/portu-sim/comfyui_bmab.git
cd comfyui_bmab
pip install -r requirements.txt

No model download needed for this node specifically; it's a text-encoding behavior change, not a new model.

Common issues & troubleshooting

A prompt that looked right in A1111 still doesn't match. Double-check you actually set weight_interpretation to A1111 - the default in the schema isn't guaranteed to be that value, and leaving it on ComfyUI's own original dialect while writing A1111-style weights is the single most likely cause of a mismatch.

Weighting one term seems to wash out or overpower everything else. That's a normalization question, not a weighting one - try switching token_normalization to mean or length+mean before you start second-guessing your weight values.

You're not sure which dialect a prompt you copied was written for. If it came from a CivitAI model card or an A1111/Forge screenshot, assume A1111. If it came from another ComfyUI workflow's JSON, it's likely already in ComfyUI's own comfy conventions and doesn't need translation at all.