CLIPTextEncodeSDXL_motorway_edition

SDXL doesn't use one prompt - it uses two, run through two different text encoders and blended into a single conditioning. Plain CLIPTextEncodeSDXL is the node that does that work. This _motorway_edition clone does the same job, except the CLIP model arrives from a shared "motorway" bag and the finished conditioning gets written back into it, all keyed by strings instead of wires.

If you've never met the original node: text_g is the prompt for the big OpenCLIP-G encoder, text_l is the one for the smaller CLIP-L encoder, and SDXL's whole trick is that those two reads of the same scene get averaged together. Practically nobody writes two truly different prompts - most workflows just put the real prompt in text_g and a truncated or identical copy in text_l. The pack's clone leaves all of that alone; it only changes where data comes from and goes to.

What you actually set

The schema is the core SDXL encode node plus the motorway plumbing:

• MOTORWAY 🚌💨 - the bag this node reads from and writes to.
• INPUT_clip_key (default clip) - the bag key holding the SDXL checkpoint's CLIP. As long as you stored it under clip upstream, this works untouched.
• text_g and text_l - the two prompts, both multiline. The pair you'll actually write.
• width, height, target_width, target_height, crop_w, crop_h - the crop/scale hints SDXL uses to encode. Defaults are 1024×1024 with zero crop, which is fine for most output sizes; if your image doesn't match, the encode math still works, it just isn't tuned to your target.
• OUTPUT_CONDITIONING_key (default CONDITIONING) - where the blended result lands in the bag.

Its only output is the motorway itself, which is the whole point of the _motorway_edition family: one bus connection carries everything, and downstream nodes pull values out by key.

Install and reality check

It's in the same pack as every other _motorway_edition node, installed the same way - pure Python, nothing to pip, no models to download:

cd ComfyUI/custom_nodes
git clone https://github.com/agilly1989/ComfyUI_agilly1989_motorway

Then restart ComfyUI (or search ComfyUI_agilly1989_motorway in ComfyUI Manager).

Now the part worth reading twice. This clone is one of dozens generated automatically in pack v1.1.0, and it's a beta project from a single author whose README opens with "BIG BROKEN WITH ASYNC WILL FIX WHEN I GET THE TIME/MOTIVATION." In current releases the generated nodes are disabled - the __init__.py that used to register them now has the import commented out, and the prestartup script that made the pack load last is shipped as .disabled. So a fresh install today likely gives you the MotorwayStart + Motorway AxB ramps but not this node. If you see it in your menu, great; if not, that's expected, and honestly the plain CLIPTextEncodeSDXL plus two Motorway 0x1 ramps does the same thing more reliably.

The usual pipe gotchas apply: keys are case-sensitive, and if you get 'MotorwayClass' object has no attribute 'hash_', the key you referenced was never written into the bag - typo, or an upstream node that never ran. That failure mode is precisely the tradeoff the community argues about with "Anything Anywhere"-style routing: fewer wires, harder debugging. Fine for a fun experiment, stressful for a workflow you share.