Forge Compat Text

Type the same prompt into Forge and into a stock ComfyUI CLIPTextEncode and you are not getting the same conditioning. Forge runs its own prompt parser - emphasis syntax, comma backtracking, per-part weights, and prompts scheduled per denoiser call rather than per step. Forge Compat Text is the node that reproduces that pipeline for a spec built by Forge Compat Import / Spec.

What it takes and gives

Two required inputs: spec (the FORGE_GENERATION_SPEC from the importer) and clip (from any standard CLIP/text-encoder loader). Two outputs: conditioning, a FORGE_CONDITIONING bundle, and report, a JSON string.

The bundle isn't cosmetic. It carries the config hash of the spec, the model family, the text-encoder and LoRA binding hash, per-part weights, the prompt schedule keyed to denoiser calls, and the token/mask/weight trace hashes. That's why it's a custom type instead of a fake CONDITIONING: schedule data stuffed into a standard KSampler would get silently collapsed down to the last prompt, and you'd never know your prompt weight ever applied. Uglier type, honest behaviour. Wire conditioning into Forge Compat Sampler and nothing else.

Why your CLIP skip might do nothing

On Anima - the Circlestone Labs anime base with a Qwen text encoder - clip skip is meaningless, and the node says so: the report lists clip_skip under what wasn't applied rather than pretending. On SD 1.5 it's load-bearing. On SDXL it's mostly theatre, since both encoders already sit on the penultimate layer, which is the honest version of a debate that's been running since 2022. If you're coming from an A1111 habit of setting it to 2 everywhere, the report output is a good place to find out which habit you're carrying.

For Anima specifically, the node keeps Qwen output and the T5 token IDs and weights separate instead of flattening them - the model-side adapter handles them inside the sampler's execution path. Also worth knowing: nothing here mutates global CLIP behaviour. No monkey-patching, no shared state, which is deliberate, because that's the class of thing that makes two extensions fight over one runtime.

The LoRA trap

If you're used to writing <lora:name:0.8> in a Forge prompt and having weights appear, this node does not do that. The spec carries an explicit LoRA list, and the pack's contract is that LoRAs are applied through connected loader chains, once, at the binding that the importer recorded. Adding a tag to prompt text doesn't load anything. That's stricter than Forge, and it's the right call - silent nothing-happened LoRA tags are one of the ecosystem's most reliable sources of "why doesn't my prompt work".

Install and wiring

Same pack, same steps:

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

Restart ComfyUI, press F5. No pip at launch, no downloads. Manager → search "ForgeNeo Bridge" does the same thing.

A hand-wired Compat graph looks like this:

Forge Compat Import / Spec ──spec──┬──> Forge Compat Text  (clip from a CLIP loader)
                                   ├──> Forge Compat Noise (model from a UNET/checkpoint loader)
                                   └──> Forge Compat Sampler
CLIP loader ──clip──> Forge Compat Text ──conditioning──> Forge Compat Sampler

Both Text and Noise get the same spec object. Where they conflict - a different spec branch feeding the sampler - you'll get an explicit error rather than a quiet mismatch.

Troubleshooting

ASSET_BINDING_MISMATCH on the sampler: the text encoder or LoRA chain changed after encoding. Rebuild both branches from one importer, don't hand-swap the CLIP loader mid-wire.

"My negative prompt does nothing": read the report before blaming the prompt text. If it lists clip_skip as not applied, you're on a family where the encoder-layer settings don't exist - a good hint that other Forge-only knobs you're expecting are also sitting out.

Everything loads but output looks nothing like the source image: that's usually the sampler path, not text. A mismatched spec, a different checkpoint, or adjustments being off will all show up there first.

This is a thin node by design - it does one job and then insists the sampler honour the format it produced. If you just want to regenerate a Forge image, you probably shouldn't wire it manually at all: drop the image on the canvas and let the newer Bridge nodes build themselves.