字符串切换

A/B testing a prompt in ComfyUI normally looks like this: two text nodes, a switch node, two wires into the switch, one wire out to your CLIP Text Encode. Four objects to hold two strings. And every time you fiddly-edit a variant you have to remember which of the two boxes you're editing.

QG_StringSwitch puts both strings on the node itself. Top box is the true branch, bottom box is the false branch, a boolean picks. That's the whole node.

What it is

Three required inputs, one output:

• boolean - the condition. True takes the top text, false takes the bottom.
• on_true - multiline STRING. Type directly into it, or wire an upstream string over it.
• on_false - same thing, the other branch.
• output string - whichever one was selected.

Both text fields are lazy in the ComfyUI sense, and the node implements check_lazy_status to only request the branch that's actually going to be used:

@classmethod
def check_lazy_status(cls, boolean=False, on_true=None, on_false=None):
    if boolean and on_true is None:
        return ["on_true"]
    if not boolean and on_false is None:
        return ["on_false"]

Why care? Because lazy evaluation is what stops the branch you didn't pick from running at all. If on_false is fed by an LLM call, a wildcard file read, or a "load text from disk" node, it never executes when the boolean is true. On a graph where a prompt branch costs you a 20-second text generation, that's the difference between a switch and a tax.

Beyond that, this is a widget-overriding-inputs design, which is the standard ComfyUI behaviour: the moment you drag a wire onto on_true, the upstream value wins and your typed text becomes irrelevant. Keep that in mind - a wired branch that looks like it has text in it isn't using that text.

When to reach for it (and when not to)

The good use case is prompt variants you flip while iterating. Photoreal pass vs illustration pass. "with the jacket" vs "without the jacket". A detailed prompt for hero shots and a short one for fast drafts. You keep both alive, glance at both, and toggle.

The honest limitation: two branches is two branches. If you're maintaining six prompt variants, this node becomes six of these nodes and a mess. That's what prompt libraries and wildcard systems are for - the community's older wildcard-syntax habit (A1111-era __wildcard__ files, still supported by a few ComfyUI extensions) exists exactly because inline switching doesn't scale past a couple of options.

Also worth being clear about the division of labour inside the pack: this node switches two strings you type on the card. It doesn't switch arbitrary typed sockets - images, latents, models. If you need "if the high-res model is loaded use this, otherwise use that" over a MODEL socket, that's a different node in the same family. Confusing the two is the usual first mistake.

And the condition has to come from somewhere: this is an A/B switch, not a fallback switch. Fallback switches ("use the first non-empty input, I'm not choosing") are a different shape entirely - rgthree's Any Switch is the canonical one - and they solve the "optional upstream branch" problem, not the "flip between two prompts" problem. Don't expect this node to pick a winner for you.

Installing

Part of ComfyUI-QG-tools. No dependencies; the repo's requirements.txt is a comments-only file on purpose so Manager skips pip entirely.

cd ComfyUI/custom_nodes
git clone https://github.com/live1617/ComfyUI-QG-tools

Restart ComfyUI fully. Console banner confirms 32 nodes loaded from v0.9.4. It lives under QG-tools/逻辑 and searches as string, switch, prompt or 字符串.

Gotchas

• Empty is a valid answer. Both boxes default to "". If you only filled the true branch, flipping the boolean gives you an empty prompt and a successfully-generated image of nothing in particular. No error, no warning. Fill both.
• Wiring overrides typing. Once on_true has an incoming link, the text visible in the box is stale decoration. The author's tooltip says this explicitly; people still get caught by it.
• It's lazy per branch, not lazy overall. The boolean itself is always evaluated - it has to be, or the node can't decide. So putting an expensive computation upstream of boolean saves nothing.
• One string out. No list, no batch. It's a single STRING, which is exactly what a CLIP Text Encode wants.