In this article
Jan needs a loadable local model to start its API server; remote routing after startup does not remove that prerequisite.
Jan’s API server needs a local model it can load before starting, even if you configured a remote provider for later requests. A remote model entry does not replace the local startup prerequisite documented for the Desktop server.
The concrete application boundary
This failure happens before ordinary application requests are routed. The default-model picker offers supported local llama.cpp models and MLX models on Apple Silicon. On macOS, the current documentation requires Apple Silicon for these local engines; the bundled llama.cpp engine does not load models on Intel Macs as of the documented release boundary. Therefore a configured remote provider cannot repair a missing loadable startup model. Keep platform eligibility, local loading, server startup, and later provider routing as separate stages. This article concerns the Desktop API server; Jan Agent is separately distributed preview software and should not be used as evidence that Desktop startup requirements disappeared (Jan Desktop documentation) (Jan Agent documentation).
A practical route
Download or import a supported local model in Jan. Open Settings > Local API Server and select it under Default Model Local API Server. Click Start Server. Jan uses an already loaded model if one is running; otherwise it loads the selected default before starting. Wait for Server Status to show running and inspect Server Logs if loading fails. The documented default endpoint is http://127.0.0.1:1337/v1, but use your current configured host, port, and prefix for the actual client (Jan Local API Server).
A worked example
A user adds a remote provider and tries to start the server with no local model available. The corrective action is not to rotate the remote credential. First supply a supported local startup model, select it as default, and confirm the running status. Only then test a request that explicitly chooses the configured remote model. That later request is not offline or confined to the computer.
| Check | Record |
|---|---|
| Before startup | A loadable local model exists and is selected as the server default. |
| Startup evidence | Server Status is running, with loading failures inspected in Server Logs. |
| Routing evidence | Any later request to a remote provider is recorded as remote execution. |
Reading the failure correctly
If the selected local model fails to load, inspect the documented platform support and the loading error before modifying API credentials. If the server starts but a client fails, investigate that client’s address or requested model separately. Execute Tools on Server is disabled by default and controls dispatch ownership; it does not remove the startup model requirement.
What completes the check
The important distinction is startup versus subsequent routing. A working server can route selected requests remotely, but its ability to start still depends on the documented local-model prerequisite.
Related background: llama.cpp server: a local API from a GGUF model, VRAM for LLMs: why model size is only part of the calculation.