llama.cpp List Models

The router start node gives you a server that can hold several models. List Models is how you find out what that server actually knows about - its full model catalog and each model's residency state. Think of it as the router's /models endpoint with a friendly face, and the pack is explicit that this is the authoritative catalog, not the direct-mode dropdowns. Direct-mode dropdowns scan recursively across all configured roots; the router's one-level scan sees less, so the two can disagree, and List Models is the one you trust.

It's a pure inspection node: nothing it does changes the server's state, unless you ask it to.

How it works

List Models queries the running llama-server and returns the catalog in two flavors:

• models_json - the complete router model catalog as formatted JSON. The machine-readable version; pipe it into anything that consumes JSON.
• models_list - a human-readable list of model identities and residency states. The one you want on screen.

Both outputs are STRINGs, and the node is an output node, so results render for you - or run them through Prompt Output if you want them styled.

The one input that does do something is reload_catalog. Set it and the node asks the router to rescan its configured model sources before listing. That's genuinely useful after you drop a new GGUF into the models directory - the router won't pick it up on its own. But read the tooltip before you lean on it: rescanning can unload models that were changed or removed while running, reload waits for an idle managed runtime, and it serializes with lifecycle operations. If you have a model mid-generation, don't poke the rescan.

Inputs

• trigger - a dependency input to sequence the listing after something else (like a model load) completes.
• reload_catalog - off by default; on forces a rescan before listing.

Wiring it into a workflow

The natural spot is in a router-based workflow alongside Load Model and Unload Model. Two patterns work well: after a Load Model succeeds, trigger List Models to confirm the residency state actually flipped to loaded; or at the start of a workflow, run it once and read models_list to see whether the model you want is already resident or will need an autoload. If you're scripting a folder of models, models_json is the parseable inventory. The honest caveat: for a single-model direct server this node isn't very interesting - the router is where a catalog of multiple models and residency states is a thing you actually need to check.