Stop llama.cpp Server

Stop llama.cpp Server is the pack's off switch, and the name is doing precise work: it stops only the local llama-server process tree that this node pack started. It will not touch a server you launched yourself, and it will not target an attached endpoint. That ownership discipline is the whole design of the pack - "positively owned process trees" is a feature, not a limitation, because it means you can never run this node and accidentally kill someone else's llama-server that happens to be listening.

A thin node, but the stopping behavior is genuinely thoughtful about edge cases: it uses deterministic stop barriers, and on Linux it has kernel-backed abrupt-owner cleanup while Windows uses Job Objects when available. It never sweeps processes by name - if the pack didn't start it, it doesn't stop it.

How it works

Give it a trigger to sequence it, and it shuts down the owned process tree. For an owned direct server, that's the whole runtime. For an owned router, it stops the router's process tree too. The outputs tell you whether it worked: success (did the owned process tree stop completely?) and message (the shutdown result or failure detail). It's an output node, so results render for you.

If you're wondering where this fits next to the other two teardown tools: Release llama.cpp VRAM unloads models but keeps the router alive when it safely can; Unload Model drops one exact model; Stop is the full stop - the process tree is gone. Comfy's native Unload Models action also stops an owned direct server, so you have multiple paths to the same end; this node is the one you put explicitly in the graph.

Wiring it

Two sensible spots. End of a workflow: after the LLM's last generation, sequence Stop so the VRAM is freed and nothing idles in the background. In a conditional or "cleanup" branch: stop the server when a generation fails, so a hung or misbehaving runtime doesn't sit there holding memory for the rest of the session.

The honest version

For most people this node is a "nice to have" rather than essential - Comfy's Unload Models and the Release node cover the common teardown cases, and if you never run Stop, the server still gets cleaned up when ComfyUI exits. Where it earns its place is in explicit lifecycle control: you want the shutdown to be a visible, sequenced step in the workflow, and you want a success Boolean you can actually read. Also worth knowing: it reports success only when the process tree is completely gone, so a stubborn subprocess means a false success that's actually a clue to check Server Status.