🌀 Warp

Every serious ComfyUI workflow eventually turns into spaghetti. A checkpoint, a CLIP, a VAE, two conditioning branches, a latent, a seed, steps, CFG, a sampler, a scheduler - that's a dozen wires before you've even added a LoRA or an upscale pass. The Warp node from the WarpPipe pack is the tidy-up: it bundles all of that into a single object that travels down one wire and gets unpacked later by its sibling, Unwarp. Same idea as rgthree's Context nodes, but it swallows data - models, tensors, and sampling parameters - not just connections.

How it works

Under the hood, Warp is doing something sneaky but simple. Every Warp node you place gets a unique ID when the workflow loads. When it executes, it copies whatever you fed in (models, latent, conditioning, prompts, numbers) into a global in-memory store keyed by that ID, then returns a small WARPPIPE object that is really just that ID. The wire you drag across the canvas is a handle, not the data itself - the data lives server-side in a thread-safe dict with a 1-hour expiry and a 256-entry cap so it can't leak memory on a long session.

That design gives you two genuinely useful behaviors. First, chaining: feed one Warp's output into another Warp's warp input, and the second one starts with a copy of everything the first bundled, then applies its own values on top. Build a base "model + seed + sampler" Warp, branch it into two more that only override steps or CFG, and you've got a cumulative bundle without re-wiring. Second, fast model switching: because every input is optional, you can keep several Warp nodes, one per style or checkpoint, and swap which one feeds your Unwarp. The pack's own example workflow does exactly this - two Warp Providers running different sampler/scheduler pairs.

The inputs that matter

Every input is optional, which is the point: a Warp bundles only what you connect. The ones a beginner actually sets:

• model_1 (and model_2) - your MODEL, straight from a checkpoint/LoRA loader. model_2 exists for merge-style workflows.
• conditioning_positive and conditioning_negative - what you'd normally wire into KSampler.
• latent - the noise you'd otherwise generate with Empty Latent Image.
• seed, steps_1, cfg, sampler_name, scheduler - the sampling parameters you want carried along.
• warp - the chain input for extending an existing bundle.

It also takes image, mask, clip, clip_vision, vae, prompt_positive/prompt_negative (plain text), steps_2/steps_3 for multi-pass setups, and width/height. One output, warp, which feeds straight into an Unwarp.

One honest warning: sampler and scheduler values get coerced on the way in. If you feed an exotic scheduler ComfyUI doesn't know (say, OSS FLUX), Warp silently remaps it to a safe one (karras) rather than erroring. Handy, but don't be surprised when your unusual scheduler comes out the other end renamed.

Installing it

Install once for the whole pack - it's a single repo with zero external dependencies (the requirements file literally says so; it only uses ComfyUI's built-ins):

cd ComfyUI/custom_nodes
git clone https://github.com/gregory-richard/ComfyUI-WarpPipe.git

Then restart ComfyUI. ComfyUI Manager users can just search "WarpPipe"; Registry users can run comfy node install warppipe. No model downloads, no pip step.

Where people get tripped up

The data store is per-session and in-memory, so a saved workflow that reloads and re-runs from Warp to Unwarp is fine, but the bundle only exists while ComfyUI is running. And if you're loading an old pre-v3.0 workflow, the internal type was renamed from CONTROL to WARPPIPE, so you may need to re-drag a couple of Warp→Unwarp links once. That's cosmetic, not broken.