SDFX Clip TextEncode (Prompt)
The CLIP Text Encode that pretends to be an SDFX node (and brings A1111 prompt editing along)
- clip
- CONDITIONING
First, the reassuring news: the "SDFX" in this node's name is doing a lot of marketing. This is, functionally, the stock ComfyUI CLIP Text Encode node with A1111-style prompt editing bolted on. It doesn't call any SDFX API, it needs no SDFX account, and it will happily run in a completely vanilla ComfyUI graph with the whole SDFX stack absent. If you found it in someone else's workflow and just want to know whether to wire it up - yes, wire it up like a normal CLIP Text Encode.
Why it exists
SDFX is a separate project (by the sdfxai/ArtificialLab folks) that wants to run ComfyUI as its backend instead of reinventing a renderer. The bridge pack it lives in does three things to make that work: it injects ComfyUI launch flags from a sdfx.config.json file, it adds /sdfx/* HTTP routes for galleries and media, and it ships this conditioning node plus a patched SaveImage so SDFX's own workflows and templates produce exactly the conditioning format SDFX expects. If you run SDFX, this is just the conditioning node its templates use. If you don't, it's still a perfectly good text encoder.
How it works
Under the hood it's a two-step trick. First, a lark-grammar parser (ported from A1111's prompt_parser.py) splits your text into per-step segments based on prompt-editing syntax. Then each segment is tokenized and encoded through your CLIP model exactly the way stock ComfyUI does it - clip.tokenize() plus encode_from_tokens() - and stamped with start_percent/end_percent so the sampler knows which conditioning applies at which point. The output is a single CONDITIONING fed to KSampler's positive or negative input.
That means the one genuinely new thing over stock CLIPTextEncode is prompt editing: [from:to:when], which swaps the concept at a point mid-generation. a [red:blue:0.5] car renders "a red car" for the first half of sampling and "a blue car" for the second half. A one-sided [word:when] form works too - [smoke:0.6] adds smoke at 60%.
The inputs that matter
Only two, both required:
- clip - the CLIP output of your checkpoint loader (or a dedicated CLIP loader). Same as every other text encode node.
- text - your prompt, a multiline box.
Output is a single CONDITIONING. That's the whole surface. No hidden toggles, no strength knobs.
Installing it
ComfyUI Manager - search for SDFXBridgeForComfyUI - or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/sdfxai/SDFXBridgeForComfyUI
cd SDFXBridgeForComfyUI && pip install -r requirements.txt
Then restart ComfyUI. There are no model files to download - it's all code. The only pip dependency is lark, a small parsing library that ComfyUI itself already installs, so you'll usually have zero extra deps. The README also demands ComfyUI-Manager as a "mandatory dependency," but that's about how SDFX bootstraps a ComfyUI instance, not about running this node.
Where people get burned
Three real traps, all verifiable in the source:
- The step values are fractions, not A1111 integers. A1111's
[word:3]means "after step 3 of 10" - 30%. Here the schedule runs 0 to 1.0, so write[word:0.3]. Write[word:3]and the swap silently never fires, because nothing in the schedule ever passes step 3... or, worse, the segment gets clamped to the tail end of sampling. This one will cost you real debugging time if you're an A1111 refugee. {a|b}alternation is a lie. The grammar parses it, but the code that expands schedules doesn't handle the alternation nodes, so the literal text{a|b}goes straight into the tokenizer. Don't use it.- The pack patches the built-in SaveImage node (rewrites its inputs, defaults the filename prefix to "SDFX") for the entire ComfyUI instance, not just SDFX runs. Harmless, but it's why you'll see SDFX-flavored SaveImage nodes after installing.
Also: if you install the pack and haven't created sdfx.config.json, startup logs print "FATAL" lines about the missing file. Scary, ignorable - it only matters if you actually run SDFX.
Plain prompts behave identically to stock CLIPTextEncode, so this is a safe drop-in. Just remember the fractions, and it'll do its one clever thing - mid-generation prompt editing - without drama.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| text | STRING | — | |
| clip | CLIP | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | — |