Load Checkpoint (SDXL Long 248)

The story behind this node is worth knowing before you install anything. SDXL's CLIP encoders cap out at 77 tokens, and every SDXL user has hit that wall - you write a gorgeous prompt, and the model quietly ignores the tail end of it. This loader is the second half of a two-step hack that tries to blow that wall out to 248 tokens, and here's the part the README won't tell you: the author openly described the whole thing as "vibecoded" in the Reddit thread where it launched, and the community's best-received comment called the premise dubious. It's a genuinely clever experiment, not a proven fix. Treat it accordingly.

What it actually does

By itself this node is just a checkpoint loader - same job as ComfyUI's built-in one. The trick is what it detects. When you feed it a checkpoint that the pack's converter script has already processed, the loader reads the state dict with safe_open, looks for position-embedding tensors that are longer than 77, and if it finds them it does something surgical:

1. Saves the full 248-row embeddings.
2. Truncates them to 77 so the standard ComfyUI loader can load the checkpoint without choking.
3. Loads normally, then patches the CLIP's position embeddings, position_ids, and max_length back up to the full length on both encoders (CLIP-L and OpenCLIP-G).
4. Prints a verification block to the console with PASS/FAIL lines for every embedding.

Feed it an ordinary, un-converted checkpoint and it just loads it normally - no harm, no extended context. The node itself is competently built; the loaded question is whether the embeddings the converter extrapolated mean anything to a model that was never trained on positions past 77. LongCLIP is the research that actually trained CLIP out to 248 tokens; this project borrows the number without the training.

The one input and the outputs

There's exactly one input that matters: ckpt_name, a dropdown of every checkpoint in your models/checkpoints folder. Pick the _long248.safetensors file the converter produced. No optional inputs to fiddle with.

The outputs are the standard three - model, clip, and vae - and they wire into your workflow exactly like any other loader's: model into the sampler, clip into CLIPTextEncode for positive and negative prompts, vae into VAEDecode. The example workflow in the repo is just a plain SDXL pipeline with this loader swapped in for the usual one. Use the standard text-encode nodes afterward; you don't need any special long-prompt node.

How to install it

The README's flow is Windows-portable oriented: download the repo as a ZIP, copy the scripts folder next to ComfyUI_windows_portable, edit convert_learned.bat and set CKPT_NAME to your checkpoint's filename, then double-click it. It writes yourmodel_long248.safetensors into ComfyUI\models\checkpoints, auto-installing safetensors, numpy, and scipy along the way if they're missing. Then create ComfyUI/custom_nodes/sdxl_long_context, drop __init__.py and nodes.py in there, restart, and the loader appears as Load Checkpoint (SDXL Long 248).

On a normal setup, git clone https://github.com/brahianrosswill/ComfyUI_SDXL_LongContext into custom_nodes works the same, and ComfyUI Manager may list it by pack title. Either way, the node itself has no extra Python dependencies - it rides on ComfyUI's own safetensors and torch. The scipy requirement is only for the converter, not the node.

Where people get burned

The README is its own first trap: it tells you to edit convert_spectral.bat, but no such file ships - the actual converter is convert_learned.bat (and its docstring references a convert_spectral.py that doesn't exist in the repo either). Also read the IMPORTANT block: always convert from the original checkpoint, never from an already-converted one, and stick to 248 tokens - the author reports 512+ breaks the model. Keep an eye on the console during load; that verification block with all-PASS is the only signal you'll get that the patch took. If you see FAIL lines or a WARNING about a missing position_embedding, the conversion or the checkpoint is the problem, not your workflow.

The bigger caveat is expectations. The launch comparison images got reactions ranging from "placebo" to "something is definitely different, but I can't say better." Several commenters pointed out that ComfyUI already handles long SDXL prompts by chunking them into multiple 77-token segments, and that trained LongCLIP models (or the newer LLM-based SDXL adapters) are the proven path to real long-context understanding. This is the fun, fiddly experiment you try when you want to tinker with positional-embedding math - not the tool you'd stake a production workflow on.