llama.cpp Server Status

The pack's own troubleshooting doc starts with the same advice I'm about to give you: start with Server Status. When a llama-server won't launch, or launches and dies, or the router won't load a model, this node is the instrument panel - ownership, lifecycle state, process identity, capabilities, model residency, and a bounded redacted log tail, all in one place. It's the difference between "server won't start, I guess" and "here's the exact binary identity, the capability check that failed, and the last lines of the log."

You don't configure anything here. There are no inputs at all. You drop it in the graph, queue, and read.

What you get out

Three outputs, all read-only:

• is_running - Boolean: is the owned llama-server process actually running?
• status - the current process lifecycle state. This is the terse machine-readable answer.
• info - the human-readable payload: ownership mode, which binary and version is running, PID/process group/Windows Job state, supported capabilities, pending release status, model residency, the last error, and a bounded redacted server-log tail.

The info string is the one that earns its keep. The pack records the exact binary identity when it launches, so when a build is too old for router mode or a capability check failed, the reason is right there. And because logs are bounded and redacted, you get the tail of llama-server's own output without a wall of noise - and without leaking the API key you configured.

When to use it

Diagnosis is the headline use, but it's also just good hygiene in any workflow where the server's state is load-bearing. A few concrete moments:

• Server starts and immediately exits - the #2 troubleshooting section in the README exists for this. Server Status shows the log tail, and the usual causes are a model architecture the build doesn't support, insufficient VRAM/RAM for weights + context + KV cache, an incompatible VLM projector, or missing GPU backend DLLs. The log tail tells you which.
• Port refused or wrong binary picked up - the status payload shows the binary identity and mode, so you can confirm the pack launched the build you think it did, not some other llama-server on PATH.
• A Release that said "accepted" but VRAM looks busy - status reports pending release and the lifecycle state, resolving the deferred-release confusion.
• Router behaving oddly - model residency and capabilities are right there.

The honest version

It's a debugging node, which means on a good day it does nothing for you and on a bad day it saves you an hour. Since it's not an output node, run its strings through llama.cpp Prompt Output if you want the payload readable on the canvas rather than in the inspector. And remember the boundary it reports on: this node reports on the owned runtime. If you attached to a server you started yourself, the pack treats it as externally owned and Server Status won't be the window into it - that's the Connection/Model Info path instead.