llama.cpp Load Model

In router mode, models can load themselves the first time you ask for them - that's models_autoload, and it's the default. Load Model is for when you don't want to wait for that first-request hit, or when you want the load to be an explicit, sequenced step in the workflow with a guarantee attached. Its whole reason for existing is the guarantee: it waits for the router to reach a terminal loaded state before it reports success. HTTP acceptance alone doesn't count.

That "wait for terminal state" behavior is the pack's signature move and it's the thing that makes router workflows actually deterministic. You don't guess whether the model is ready; you gate the next node on success.

How it works

You pick a model from the router's catalog (model_name), and the node resolves it against the active router catalog and issues the load. It then polls until the router reports the model in its terminal loaded state, or the operation_timeout expires (default 300 seconds). The result comes back as a success Boolean and a message string explaining the outcome - the message is the part to read when something fails, since it carries the failure detail.

Inputs

• model_name - the model to load, from the router catalog. If the dropdown reads "No models found - add .gguf files to models/LLM/gguf/", the router has nothing to work with; fix the models directory first. The tooltip is blunt about the right workflow: use List Models to confirm the authoritative ID and residency before relying on this dropdown, since router identities can differ from the direct-mode listing.
• trigger - a dependency input for sequencing (e.g. load after the router has started).
• operation_timeout - how long to wait for the terminal state.

Outputs: success (Boolean) and message (STRING).

Wiring it

In a router workflow you typically chain: Start llama.cpp Router → Load Model → then your prompt node. Gate the prompt on success so a failed load never triggers a generation against an unloaded model. You can also sequence several loads - one after another - with the router's models_max as your upper bound on resident models.

Issues to expect

• Timeout - a big model on a slow disk can exceed operation_timeout; raise it. A genuinely stuck router (hung load) will also time out, and since the node waits for terminal state, a stuck router means a stuck workflow - that's the tradeoff for determinism.
• Wrong model name - the dropdown is built from the router catalog at node-creation time. If you've since added models, run List Models with reload_catalog to rescan, then pick the current identity.
• Already loaded - loading a resident model is a no-op that reports success; harmless.