# Jan server will not start: check the local startup model

Fix Jan API server startup by selecting a loadable local default model, while keeping later remote-provider routing as a separate behavior.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/jan-local-server-startup-model-required/
Language: en

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](https://docs.jan.ai/desktop)) ([Jan Agent documentation](https://docs.jan.ai/agent)).

## 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](https://docs.jan.ai/desktop/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](/journal/llama-cpp-server-launch/), [VRAM for LLMs: why model size is only part of the calculation](/journal/vram-and-models/).