Cache Image For Loopback
The save-half of the poor man's self-refinement loop
- input_image
The name is honest about the job: this node takes whatever image you hand it and writes it to a PNG so a sibling node can read it back. No API, no key, no model download, no hidden service. It's a file-saver with exactly one trick - and that trick is the reason ComfyUI loopbacks don't melt down.
Why you'd reach for it is the same reason anyone ever reaches for "loopback": iterative refinement. Generate pass one, feed pass one back in as the input image for pass two (img2img, ControlNet reference, a detailer pass), repeat until it's good. ComfyUI has no native wire that lets a graph consume its own output - and even if it did, a graph that kept changing its own inputs would re-run itself forever. The community's answer is a disk cache: save the result, load it back, plug the loaded image where your input image used to go. This node is the save half of that pair; its sibling Image-Loopback-Load is the load half.
How it works
It takes a standard ComfyUI input_image tensor, converts it to a PIL image, and saves it as cached_img.png inside the pack's own install folder, under the cache_path you name (default loopback_cache). Before writing, it compares the new pixels to whatever's already on disk and skips the write if they're byte-identical. That comparison is the whole design. ComfyUI re-executes a graph whenever a node's input changes; if the cache wrote a fresh file on every run, the loop would keep kicking itself in the head. Only writing on real change is what lets the graph settle.
The three inputs that matter
input_image- the IMAGE you want to remember. Feed it a single image; the node squeezes the batch dimension, so a stack of frames isn't what it expects.cache_path- this is a folder name, not a path you choose. It's resolved relative to the pack's install directory (custom_nodes/image_loopback/...), which trips up a lot of people expecting ComfyUI'sinput/oroutput/convention. The file inside it is alwayscached_img.png, so one cache folder per workflow or they clobber each other.caching_enabled- master switch, default on. Flip it off and the node becomes a no-op that passes through nothing.
There are no outputs, and that's not a bug. It's flagged as an output node, meaning ComfyUI runs it as a terminal step; it does its job and produces nothing to wire anywhere.
Install
Easiest via ComfyUI Manager: search "Image Loopback" (the pack shows up under its title, image_loopback), install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/leocbehe/image_loopback
Restart ComfyUI and you're done. There are zero extra dependencies - it only uses torch, Pillow and numpy, which ComfyUI already ships - and no model files. This is a young pack, by the way: a single "initial working commit" from spring 2025, so there's no long track record behind it. That's fine for something this small, but it means "trust but verify" before you bake it into a production workflow.
Where people get burned
The repo ships a loopback_cache folder containing two ~1.5MB PNGs from the author's dev session. On a fresh install, before your Cache node has ever written anything, a Load node pointed at the default path will happily return one of those stale images - your "loopback" suddenly spits out a stranger's picture. Use your own cache_path name, or delete the folder after cloning.
Also remember where those files live. The cache sits inside the pack directory, not ComfyUI's output/, so a pack update or reinstall wipes your caches, and nothing there is safe to treat as a permanent artifact. It's a scratchpad for the loop, not a save button.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| input_image | IMAGE | — | |
| cache_path | STRING | loopback_cache | — |
| caching_enabled | BOOLEAN | true | — |
Outputs (0)
No outputs