Prompt SDXL Bus
The four strings SDXL actually needs
- positiveG
- positiveL
- negativeG
- negativeL
SDXL doesn't take one prompt, and that's why the plain Prompt Bus isn't enough for it. SDXL's text encoder runs two prompts: a "global" (G) prompt that captures the overall scene and style, and a "local" (L) prompt that handles the finer details and composition - and you need both for the positive and the negative side. That's four strings floating around a workflow. The Prompt SDXL Bus collects all four in one node and hands them back out as separate string outputs.
The README describes it as "Positive and negative prompt text strings in the SDXL text_l and text_g variants," which is precisely what it is. It's a pure pass-through - nothing is merged, parsed, or transformed - and its whole value is giving the four SDXL prompt variants one home at the top of your graph, so you edit all of them in a single place instead of four scattered text boxes.
The inputs and outputs
positiveG(STRING, multiline) - the positive global prompt: overall scene, style, lighting.positiveL(STRING, multiline) - the positive local prompt: fine detail, subject specifics.negativeG(STRING, multiline) - the negative global prompt.negativeL(STRING, multiline) - the negative local prompt.
All four come back out under the same names - positiveG, positiveL, negativeG, negativeL - as plain STRING ports, ready to feed your SDXL text encoders. The exact wiring depends on which encoding path you use, but the pattern is the same either way: the G string goes where the global prompt is expected, the L string where the local prompt is expected, for both positive and negative. Keep the conventions straight - G vs L swapped will silently change the result's character.
A practical note: if your SDXL workflow only ever uses the same text for G and L, you can just type it twice here and be done. The two variants only earn their keep when you actually exploit them - short punchy L prompts, descriptive G prompts - which is the common SDXL wisdom anyway.
Installing it
Same pack as every other bus node. ComfyUI Manager: search "comfyui-bus-plugin", Install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/rhdunn/comfyui-bus-plugin
then restart. No dependencies, no model downloads - the entire pack is a handful of small Python files.
Common issues
The trap is forgetting this passes strings, not encoded conditioning. If you wire these outputs straight into a KSampler expecting them to work, you're missing the CLIPTextEncode steps in between - this bus is the front end of the prompt pipeline, not the end of it. And if you're on SD1.5 or Flux, this node is overkill and its four fields are just confusing; grab the two-field Prompt Bus instead. It's a niche organizer, and it works best when the workflow actually needs the G/L split.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| positiveG | STRING | — | |
| positiveL | STRING | — | |
| negativeG | STRING | — | |
| negativeL | STRING | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| positiveG | STRING | — |
| positiveL | STRING | — |
| negativeG | STRING | — |
| negativeL | STRING | — |