🗑️ Unload All Models
Kick every loaded model out of VRAM in one click
- message_in
- message_out
- string_out
This node exists because of a very specific kind of pain: you're running a local LLM in LM Studio and diffusion models in ComfyUI on the same GPU, and they will not share nicely. The typical routine on a 16GB card is load the LLM, generate a batch of prompts, unload it, then switch back to ComfyUI and run your images - by hand, every time. 🗑️ Unload All Models automates the "unload it" part: when the workflow reaches it, it tells LM Studio to drop every loaded model and free the VRAM before the diffusion half of your graph runs.
If you're building an "LLM writes the prompts → diffusion draws the image" pipeline, this is the node that makes that chain actually fit on one card.
How it works
The interesting bit: it doesn't use the HTTP API at all. It shells out to the LM Studio command-line tool, lms, running:
lms unload --all
(lms.exe on Windows.) That's the entire mechanism - a subprocess call that asks LM Studio to unload all currently loaded models. Which means there's exactly one prerequisite that trips people up: the lms CLI has to be installed and on your PATH, or this node silently does nothing.
LM Studio doesn't install the CLI by default. You get it from inside the app - click the </> icon in the bottom status bar, or run:
# macOS / Linux
~/.lmstudio/bin/lms bootstrap
# Windows (CMD or PowerShell)
%USERPROFILE%\.lmstudio\bin\lms.exe bootstrap
Then close and reopen your terminal and check it with lms -v. If you see a version number, you're set.
It's a passthrough node
The inputs and outputs are the whole story: optional message_in (a MESSAGE) and string_in, and message_out / string_out that just echo whatever came in. Nothing gets consumed or transformed. That's deliberate - it means you can drop this node anywhere in a wire without breaking the graph. Chain it at the end of your workflow as a cleanup step, or place it between the LLM section and the image section so the unload happens at exactly the right moment.
Where people get burned
- The lms CLI isn't installed, so the unload silently never happens. The node catches the
FileNotFoundError, prints a message to the ComfyUI console, and passes the data straight through. No red error on the node - the workflow "works," but your VRAM stays full. This is the #1 gotcha, and the error is easy to miss. lmsisn't on your PATH (common on Windows) even though it's installed. Fix it the usual way - add the.lmstudio/bindirectory to PATH and restart everything.- You're expecting it to unload a specific model. The command is
--all; it doesn't take a model argument. Every loaded model goes.
Install
Same as the rest of the pack: ComfyUI Manager (search "LM Studio Tools") or
cd ComfyUI/custom_nodes
git clone https://github.com/Hazukiaoi/ComfyUI-LM_Studio_Tools
then restart ComfyUI. The pack's only Python dependency is requests, and it downloads nothing. The extra dependency is the one that actually matters for this node: the lms CLI described above. Everything else in the pack talks to LM Studio over HTTP and doesn't need it - this is the only node that does.
One honest caveat: because the failure mode is "silent no-op," test this node once in a small workflow and watch the ComfyUI console for the lms command output before you trust it mid-pipeline. Once you've confirmed it prints the unload confirmation, it's a genuinely handy little cleanup node - the sort of thing you'll miss the moment you go back to juggling VRAM by hand.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| message_inopt | MESSAGE | — | |
| string_inopt | STRING | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| message_out | MESSAGE | — |
| string_out | STRING | — |