Five common Ollama errors and the fixes that actually work.

Local AI is a different first impression than cloud AI. No signup, no API key, no token counter ticking in the background. Just a binary, a model file, and a daemon. That friction-free promise holds — until the first time the daemon refuses to start, the model fails to download, or a port is already in use. Every local-AI newcomer hits the same five errors on day one. None of them are caused by a bug in the model or the app. All of them have a one-line fix once the right log line is read.

The five errors below cover roughly 95% of "Ollama will not talk to my app" reports. Each section has the exact error string, the most common cause, and the shortest working fix. The fix is a single command in every case. The post is short on purpose: the goal is to clear the wall, not to teach Ollama from scratch.

The error string varies by app: Error: could not connect to ollama, connection refused, dial tcp 127.0.0.1:11434, or simply a never-ending spinner. The cause is always the same: the Ollama daemon is not running.

Ollama is a long-lived background process, not a CLI tool invoked per request. The ollama command in a terminal is the client; the daemon is ollama serve. On first install, the daemon may not auto-start on every platform. macOS gets a launchd entry, Linux gets a systemd unit when installed via the official script, Windows gets a Scheduled Task. Sometimes those registrations fail silently after a reboot, an OS update, or a permission change.

The fix is to start the daemon by hand and watch the log line that confirms it bound to a port.

ollama serve

Expected last line: Ollama API listening on 127.0.0.1:11434. When that line appears, the client side will connect on the next attempt. To make it stick across reboots, follow the platform-specific install instructions on the Ollama download page; the official script handles the auto-start registration on macOS, Linux, and Windows in one step. If a second instance is already running, the daemon prints bind: address already in use — that is the port-conflict error, covered below.

For app-side debugging, the response is usually a raw HTTP error, not a friendly string. Apps that surface that response in a status bar make the fix a one-search lookup; apps that swallow the response into a spinner make the fix a guess.

The error string: Error: model 'gemma3:4b' not found, try pulling it first, or 404 not found from the API, or no such file or directory in the log. The model name was typed, sent to the API, and the API said it did not have it.

Ollama stores models in a local registry. The first reference to a model in any config — gemma3:4b, llama3:8b, qwen2.5:7b — must be paired with a successful ollama pull at some point. Apps that "remember" a model from a previous session still need that model to be present in the registry; uninstalling and reinstalling the app does not pull the model.

Common typos that trigger this error:

• gemma instead of gemma3 — the older gemma:2b and gemma:7b exist, but the newer gemma3:4b is the one most apps ship a default for.
• qwen2.5 (with a dot) is correct; qwen2-5 or qwen25 is not.
• llama3.1 requires a colon and a tag (llama3.1:8b); llama3.1 alone fails.
• mistral vs mixtral — one letter, two different models, different sizes.
• phi3 vs phi-3 — the hyphen is wrong; the family is phi3 with size tags.

The fix:

ollama pull gemma3:4b

The pull prints a progress bar and the final line success. The next request from the app will find the model and return a response. To list everything already in the local registry:

ollama list

That output is the source of truth — not the dropdown in the app UI, not the config file. If the name is in the registry, the app will find it; if it is not, no amount of app-side config will help.

The error string: model requires more system memory (X GiB) than is available (Y GiB), or CUDA out of memory, or llama_model_loader: failed to allocate memory, or the process simply dies with no output and the app shows model failed to load.

Local models are bound by VRAM on the GPU and system RAM on the CPU. The model size in the registry name is a rough lower bound on the memory required to load it, plus a working buffer for the context window. A gemma3:4b model file is roughly 3 GB on disk; loading it for inference needs about 4 GB of VRAM or RAM. A llama3:8b model file is roughly 5 GB; loading it needs about 8 GB. A qwen2.5:14b model file is roughly 9 GB; loading it needs about 12 GB. A llama3:70b model file is roughly 40 GB; loading it needs a multi-GPU rig or a server.

The most common cause of the out-of-memory error on a single-machine setup is choosing a model that is too large for the available hardware. The fix is to pick a smaller model that fits. The Ollama model library tags each model with a recommended size; the tags are not aspirational — they are the working memory the model actually consumes.

ollama pull qwen2.5:3b

That is the smallest model that still produces useful output for chat and code. It fits in about 2 GB. On a 4 GB GPU or a 4 GB-RAM laptop with no GPU, it is the default that works.

On a machine with a discrete GPU that has more VRAM than the laptop ships with system RAM (a common configuration on gaming laptops), Ollama prefers the GPU and reports GPU available, using it on startup. To force CPU mode for testing, set the OLLAMA_NUM_GPU environment variable to 0:

OLLAMA_NUM_GPU=0 ollama serve

To see how much memory Ollama actually has at runtime, the /api/ps endpoint returns a JSON dump with the loaded model size and per-layer placement:

curl http://127.0.0.1:11434/api/ps

The error string: Error: listen tcp 127.0.0.1:11434: bind: address already in use, or the app reports Ollama is unreachable even though ollama serve printed Ollama API listening on 127.0.0.1:11434 ten seconds ago. The cause: another process on the machine owns port 11434, or a stale Ollama process is still bound to the port.

The default Ollama port is 11434. Two common cases lead to a conflict:

1. A previous Ollama instance is still running. A reboot, a crash, or a stuck ollama serve window can leave the daemon holding the port. Killing the old process and starting a new one clears it.
2. A second AI server is bound to the same port. LM Studio and other local-model front-ends sometimes default to 11434 for OpenAI-API compatibility.

The fix on the Ollama side is to set a different listen address via the OLLAMA_HOST environment variable, then restart the daemon:

OLLAMA_HOST=127.0.0.1:11435 ollama serve

The app must be reconfigured to point at the new port. Most local-AI apps accept the base URL as a setting; the format is http://127.0.0.1:11435.

The fix on the conflicting-process side is to identify the process holding the port and stop it. On macOS and Linux:

lsof -i :11434

That returns the PID and process name. Kill it with kill <PID> and start a fresh Ollama. On Windows, PowerShell's Get-NetTCPConnection -LocalPort 11434 returns the owning process ID; the matching Get-Process -Id <PID> reveals the binary.

The error string: Error: context length exceeded, or prompt too long, or the request would exceed the model context window. The cause: the chat history or the input prompt is longer than the model can hold in a single inference pass.

Every local model has a fixed context window. The window is the total number of tokens — input plus output — that the model can process in one call. The defaults vary: gemma3:4b ships with 8 192 tokens, llama3:8b ships with 8 192, qwen2.5:7b ships with 32 768. The window can be raised at load time (up to the model training-time maximum) but the RAM cost grows with the window size.

The most common trigger is a long-running chat session where the history accumulates. After 20 to 40 exchanges, the running token count crosses the window and the next prompt fails.

The fix has three flavors, in order of preference:

1. Start a new chat. The history is the largest contributor; a clean session brings the token count back near zero. Most apps expose this as a New chat button in the side panel.
2. Configure a context limit in the app. Apps that integrate with Ollama often expose a context length or memory limit setting; lowering it forces the app to truncate the oldest messages before the API call. The setting is per-app, not a global Ollama flag.
3. Set the context length at the Ollama layer. The OLLAMA_CONTEXT_LENGTH environment variable, or the num_ctx parameter in a Modelfile, sets the model window at load time. A larger value gives more memory but more RAM use:

OLLAMA_CONTEXT_LENGTH=16384 ollama serve

That quadruples the default gemma3:4b window at the cost of about 2 GB of additional RAM during inference.

For an error that does not match one of the five above, the next three places catch the remaining 5%:

• Ollama GitHub issues — search before opening; the same error is almost always reported.
• r/LocalLLaMA — fast community answers, especially for hardware-specific questions.
• GitHub Discussions — anonymous, no signup needed for reading, and the topic is explicitly local-AI setup. Search first; open a thread if nothing matches.

For environment-level problems (driver, kernel, macOS Gatekeeper), the OS-specific Ollama docs cover the install and the common post-install gotchas.