SP_SaveLatent

ComfyUI already ships a Save Latent node, so the first question is why you'd want a second one. The answer is in SP_SaveLatent's one string field: filename defaults to abs_filepath.latent, and that default is the whole pitch. This node wants an absolute path, not a name that gets dropped into ComfyUI's managed output folder with an auto-incrementing counter tacked on. If you need a latent to land at a specific, predictable location on disk - because some other script or tool is going to go looking for it there - this is the node for that.

What it does

Two required inputs: samples (a LATENT, same as any other latent-consuming node) and filename (a string, defaulting to that abs_filepath.latent placeholder). It has no outputs and is an output node - meaning it's a terminal step in the graph, something that happens as a side effect rather than something you wire further downstream. Point it at a full path - something like /home/you/latents/run042.latent - and when the node executes, that's where the tensor lands.

Why you'd reach for it

The core use case is bridging ComfyUI to something outside ComfyUI. If you've got an external script polling a folder, or a pipeline that expects the latent from step one to be sitting at a known path before step two kicks off, ComfyUI's built-in save/load-latent pair (which name files inside its own output directory) makes that awkward - you'd have to go find the file it actually wrote. SP_SaveLatent skips that indirection: you tell it exactly where, and that's where it goes. It pairs naturally with caching a latent mid-workflow so you can reuse it later without regenerating - useful if a slow first pass feeds several different downstream experiments and you don't want to re-run it each time.

Installing it

Part of the SP-Nodes pack:

• ComfyUI Manager: search "SP-Nodes", install, restart ComfyUI.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/bananasss00/ComfyUI-SP-Nodes, restart.

No models, no extra dependencies - this is a plain file-write operation using Python's standard tooling under the hood.

Troubleshooting

The failure mode to watch for is exactly what you'd expect from any node that writes to an absolute path: the directory has to already exist, and the ComfyUI process needs write permission to it. If you're running ComfyUI inside Docker or on a remote/cloud executor - which is common if you're used to running workflows through an API rather than the desktop app - "absolute path" means absolute inside that container or box, not on your local machine. A path that works fine when you run ComfyUI locally will silently fail (or write somewhere you didn't expect) if you paste the same value into a workflow running on a different machine. If the node errors out or you can't find the file afterward, that mismatch is the first thing to check, well before assuming the node itself is broken.