ForgeNeo Bridge Text Encode

Most prompt nodes in ComfyUI hand you a CONDITIONING tensor the moment the graph runs. ForgeNeo Bridge Text Encode refuses to, and that refusal is the feature. It takes a CLIP and your prompt text and outputs a FORGE_TEXT_INPUT - a promise, not a tensor. The actual encoding happens later, inside ForgeNeo Bridge KSampler, once the Settings node has been read.

Why defer it

Everything that makes Forge's text handling different from ComfyUI's lives in Settings: clip_skip, emphasis, comma_padding_backtrack, the per-denoiser-call prompt schedule, layer policy, and whether compatibility is even on. Encode early and you've already baked all of those to their defaults - and a prompt schedule is the worst possible thing to bake wrongly, because a standard conditioning tensor collapses it to the last prompt without saying a word. So the encode is postponed until the sampler knows which mode it's in.

The upside for you: this node has no options to get wrong. Two inputs, one output.

Inputs and output

clip - from any standard CLIP or text-encoder loader. text - the prompt, multiline, empty by default.

Output: text, of type FORGE_TEXT_INPUT. Wire it into the positive or negative slot on ForgeNeo Bridge KSampler. You want two of these nodes in a normal graph: one carrying your positive prompt into positive, one carrying the negative into negative.

Two consequences of the custom socket type, both worth knowing before you assume something's broken:

• It will not plug into a stock KSampler. Custom type, custom consumer. It goes in the Bridge sampler's prompt slots, and the Bridge sampler hands the result to the text stack. There's no standard-conditioning conversion, deliberately - a converter would have to throw away the schedule, which is the thing the pack is here to preserve.
• The prompt you edit lives here, not in Settings. Settings carries the policy for how text is processed; this node carries the text itself.

The LoRA thing

If you're in the habit of writing <lora:someLoRA:0.7> in a prompt and having weights materialize, expect nothing here. The pack's contract is explicit: LoRAs are applied through the loader chain that was connected, and a tag in the text field does not load anything. That's stricter than Forge and it's the right trade - a LoRA tag that silently does nothing is one of the more reliable ways to waste an afternoon, and this way you find out at the loader instead.

Also worth setting expectations on: an Anima graph ignores clip_skip entirely, because its Qwen text encoder has nothing for that parameter to attach to. The sampler's report will list clip skip as not applied rather than quietly pretending.

Install

It's part of the same pack:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-ForgeNeo-Bridge.git

Restart ComfyUI and press F5. No requirements.txt, no pip at startup, no model downloads - the pack uses the torch/numpy/scipy/Pillow/tqdm already in your ComfyUI install, and vendors its Lark prompt parser in a private namespace instead of touching a system install. Update with git pull --ff-only, then restart and reload.

If you opened this page on purpose

You probably have a graph with this node in it and wondered why there's no CLIP-skip widget. There isn't one. Set clip_skip in ForgeNeo Bridge Settings and change the prompt here; that's the division of labour. If you're building a Bridge graph by hand rather than by dropping a Forge image, the minimum shape is: loader → Text Encode (positive), loader → Text Encode (negative), Settings, and a KSampler taking all four plus a latent - then VAEDecode and Save Image, because the sampler hands you a latent, not pixels.