Papcorns - Simple Memory Manager

Papcorns - Simple Memory Manager is the "little brother" version of the pack's Memory Manager node, and here's the first thing you should know: the name is a lie. The code comment says it's supposed to "clear the cache only if no model is connected." It doesn't. There is no model-connection check anywhere in the implementation - the only thing that decides whether it clears is a clear_cache boolean, and when that's on, it runs an aggressive multi-stage cleanup that reaches deep into ComfyUI's internals. "Simple" is doing a lot of work in that name.

What it does

You wire an image through it, and it acts as an inline memory-cleanup trigger. Inputs:

• image - a passthrough (required, unchanged on the way out).
• clear_cache - the real on/off switch. Default true.
• model_names - an optional comma-separated string that appears in the status report for no reason other than record-keeping.

Outputs: the passthrough image and a status STRING that reports what happened.

When clear_cache is true (and RAM isn't over ~85%, where it bails out to avoid OOM), it runs the same family of "memory pressure" tricks as the full node - allocating and freeing big bytearrays to nudge the OS, gc.collect(), malloc_trim, container-safe variants - and then it goes further than its bigger sibling. It pokes at comfy.model_management.current_loaded_models and models_to_load directly (clearing those lists), walks sys.modules looking for modules whose names contain "model", "diffus", "unet", "vae", or "clip" and tries to delete torch-looking attributes off them, and finishes with a battery of torch.cuda.empty_cache() calls plus the memory-fraction reset trick.

Why that's a double-edged sword

On one hand, this is exactly the kind of hard reset that rescues a mid-batch OOM spiral when ComfyUI's own offloader is juggling too many loaded models. On the other hand, it's manually reaching into ComfyUI's bookkeeping and deleting attributes off live modules. The moment a ComfyUI update changes what current_loaded_models is or how modules hold their tensors, this node can break things in ways that aren't its fault and you won't immediately diagnose. There's a reason the code wraps all of it in try/except and prints encouraging 🍿|MEMORY| messages even when methods fail - a lot of the aggressive paths are best-effort and quietly no-op.

Where it fits

For a low-VRAM user running long video or batch workflows who wants a "press the reset button mid-graph" node, this works as a blunt tool: stick it in front of your heaviest node, let it clear, move on. If you're on a comfortable card, you don't need it, and the KB's troubleshooting material is clear that ComfyUI's own VRAM management plus a GGUF-quantized model is the sane lever - not graph-side memory hacks. Between the two Papcorns memory nodes, the full Memory Manager at least gives you thresholds and configurable behavior; this one gives you a single toggle and a lot of trust in internal APIs.

Install

Same pack, same ritual:

cd ComfyUI/custom_nodes
git clone https://github.com/papcorns/Papcorns-Comfyui-Custom-Nodes
cd Papcorns-Comfyui-Custom-Nodes
pip install -r requirements.txt

Restart ComfyUI (or search "Papcorns" in ComfyUI Manager). Needs psutil from the pack's requirements.

The honest bottom line

Use it for rescue runs, not as a permanent fixture. And if a ComfyUI update starts behaving oddly after you've run this node in a workflow, remember what it does under the hood before you blame the update. It's a useful sledgehammer with a documentation problem - expect the behavior, not the description.