TL;DR: The model that runs fine in ollama run dies the moment Cline, Continue.dev, or Aider connects to it. That’s not a coincidence — coding tools request far bigger context windows than the CLI, and context is the memory multiplier almost nobody accounts for. Before you buy RAM or shrink your model, check three things: what context your tool is asking for, whether the KV cache is quantized, and what else Ollama is still holding in memory. Two environment variables fix the majority of cases.

What you’ll be able to do after this guide:

• Read the three OOM signatures — requires more system memory, signal: killed, and a bare 500 in your editor — and know which layer failed
• Cut a model’s memory footprint by 50–75% with flash attention and KV cache quantization, without changing models
• Stop Ollama from stacking multiple models and parallel requests into memory you don’t have

Honest take: If ollama ps shows your model at 100% GPU and it still OOMs when your coding agent connects, the model is not the problem — the context request is. Fix the context math first. Downgrading from a 14B to a 7B because of an OOM that was really a 64k-context allocation is the most common way people end up with a dumber local setup than their hardware deserves.

This is the third entry in our Ollama troubleshooting series, after connection errors and the silent context-length trap. Everything below was verified on August 7, 2026 against Ollama v0.32.6 (released August 4, 2026), Cline 4.1.6, Continue.dev, and Aider 0.86.x.

The three error signatures

Ollama fails out of memory in three distinct ways, and the message tells you which layer gave up:

Error you see	Where it appears	What it means	Start with
Error: model requires more system memory (X GiB) than is available (Y GiB)	Terminal or server log	Ollama pre-calculated the load and refused before trying	Fix #1, #2
Error: llama runner process has terminated: signal: killed	Terminal, server log, or your editor	The OS killed the runner mid-load — Linux OOM killer or a container memory cap	Fix #2, #5
500 Internal Server Error / generic API error in Cline, Continue.dev, or Aider	Editor only	The runner crashed serving the request — check the server log for the real error, often CUDA OOM	Fix #2, #3, #4

The first error is the polite one: Ollama estimates the total allocation (weights plus KV cache plus overhead) up front and refuses if it won’t fit. A real example from ollama/ollama#8667: model requires more system memory (446.3 GiB) than is available (37.3 GiB) — a 40GB machine trying to load DeepSeek-R1 671B. When the gap is that large, the model is simply too big. When the gap is small — say 18 GiB required, 15 available — the fixes below usually close it.

signal: killed is the impolite one. Ollama’s estimate said it would fit, the allocation started, and the operating system disagreed and killed the process. This is the classic failure on Macs loading models near the RAM ceiling (#8571, #8464) and on Docker containers with a memory limit.

The third signature is the one that wastes evenings: your editor shows a useless 500 and everything looks fine on the Ollama side — because ollama run works. The crash only happens under the request your coding tool sends. To see the real error, read the server log:

# macOS
$ cat ~/.ollama/logs/server.log

# Linux (systemd)
$ journalctl -u ollama --no-pager --follow

# Windows: explorer %LOCALAPPDATA%\Ollama  →  server.log
# Docker
$ docker logs <container-name>

Fix #1: check what’s actually loaded before anything else

One command answers most OOM mysteries:

$ ollama ps
NAME                 ID            SIZE     PROCESSOR    CONTEXT    UNTIL
qwen3-coder:30b      abc123def     21 GB    100% GPU     32768      4 minutes from now
llama3.2:3b          456ghi789     3.4 GB   100% GPU     4096       2 minutes from now

Three things to read off this output:

1. How many models are resident. Ollama keeps every model in memory for 5 minutes after its last request by default, and OLLAMA_MAX_LOADED_MODELS defaults to 3 per GPU. If you chatted with one model in Continue.dev and then pointed Cline at a different one, both are sitting in memory. The second load OOMs even though either model alone fits.
2. The PROCESSOR split. 100% GPU means fully in VRAM. 100% CPU means fully in system RAM. A mixed split like 43%/57% CPU/GPU means the model didn’t fit in VRAM and spilled into RAM — not an error, but the usual prelude to one, and a performance cliff.
3. The CONTEXT column. This is the number that explains why your coding tool kills a setup that ollama run handles fine.

Evict what you don’t need instead of restarting the server:

$ ollama stop llama3.2:3b

Or make unloading automatic: OLLAMA_KEEP_ALIVE=0 unloads models immediately after each response (the API equivalent is "keep_alive": 0 per request). If you run one coding session at a time on tight VRAM, our sister site’s model reloading guide covers the tradeoff — aggressive unloading trades OOM crashes for cold-start latency on every request.

Fix #2: the context window is the memory multiplier

Here’s the mechanic that breaks coding tools specifically. Model weights are a fixed cost — a Q4 quantized 14B is roughly the same size whether you give it 4k or 64k of context. The KV cache is not: it grows with the context window, and at large contexts it can rival or exceed the weights themselves.

As of v0.32.x, Ollama picks a default context length based on available VRAM: 4k under 24 GiB, 32k between 24 and 48 GiB, 256k above 48 GiB. But clients can request their own — and coding agents do. Ollama’s own documentation says agent and coding workloads “should be set to at least 64000 tokens.” Cline ships repository context, file trees, and tool definitions in every request; Continue.dev and Aider both let you set num_ctx per model. Your CLI test ran at 4k. Your agent connected and asked for a context sixteen times larger, and the KV cache allocation for it is what blew past your VRAM.

So the fix is a deliberate choice, not a magic value: pick the largest context that fits, then cap it in both places — server and client. Server side:

$ OLLAMA_CONTEXT_LENGTH=32000 ollama serve

Or bake it into a model variant with a Modelfile (the num_ctx parameter defaults to 2048):

FROM qwen3-coder:30b
PARAMETER num_ctx 32768

$ ollama create qwen3-coder-32k -f ./Modelfile

Then point Cline or Continue.dev at qwen3-coder-32k and set the same number in the client config so the tool doesn’t request more than the server allocated. If your agent genuinely needs 64k+ and your card can’t hold it, that’s a hardware conversation — runaihome’s CUDA OOM guide covers the GPU side, and their VRAM-to-model table tells you what your card can realistically hold.

Fix #3: flash attention and KV cache quantization — the free 50–75%

Two environment variables shrink the context memory cost without touching your model or your context size. Per Ollama’s FAQ, flash attention “can significantly reduce memory usage as the context size grows,” and the KV cache itself can be quantized independently of the model weights:

OLLAMA_KV_CACHE_TYPE	KV cache memory	Tradeoff
f16 (default)	baseline	full precision
q8_0	~50% of f16	negligible quality loss for most uses
q4_0	~25% of f16	noticeable loss at long context — exactly where coding agents live

$ OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

(For a systemd install, add both as Environment="..." lines under [Service] via systemctl edit ollama.service, then systemctl daemon-reload && systemctl restart ollama; on macOS set them with launchctl setenv and restart the app.)

Start with q8_0. It’s the difference between a 64k-context coding session fitting on a 16GB card or not, and in day-to-day agent use the quality difference against f16 is hard to detect. Be more careful with q4_0: a coding agent’s value lives in long-context recall — remembering the function signature it read 40k tokens ago — which is precisely what aggressive KV quantization degrades first.

Fix #4: parallel requests multiply everything

Ollama serves parallel requests by growing the context allocation. From the official FAQ: “a 2K context with 4 parallel requests will result in an 8K context and additional memory allocation.” OLLAMA_NUM_PARALLEL defaults to 1, but if you raised it for throughput — or you run Cline and Continue.dev against the same server, or Cline fires a subtask while the main task streams — the memory math from Fix #2 multiplies again.

The symptom pattern: the first request works, a second concurrent one crashes the runner. If you see OOMs only when two tools are open, set OLLAMA_NUM_PARALLEL=1 explicitly and let the second request queue instead of allocating.

Fix #5: Docker and WSL memory caps

signal: killed inside a container is almost never the model’s fault. A Docker container with a --memory limit (or Docker Desktop’s default VM allocation on Mac/Windows) enforces a ceiling well below the host’s RAM. Ollama’s pre-check reads the host-visible number, starts loading, and the cgroup kills it.

$ docker inspect ollama --format '{{.HostConfig.Memory}}'
8589934592        # 8 GiB cap — a 13 GB model dies here regardless of host RAM
$ docker update --memory 24g --memory-swap 24g ollama

On WSL 2, the same ceiling lives in .wslconfig (memory= under [wsl2]) — WSL 2 defaults to 50% of host RAM or 8GB, whichever is smaller, per Microsoft’s WSL configuration docs. If Ollama runs on the Windows side and your tools in WSL, this doesn’t apply; if Ollama itself runs inside WSL, raise it there and restart with wsl --shutdown.

Fix #6: the model really is too big — downsize deliberately

If ollama ps shows one model, the context is capped at 8–16k, KV cache is at q8_0, and the pre-check still refuses: the weights don’t fit, and no environment variable changes that. Move down the quantization ladder (a Q4_K_M tag instead of Q8_0) before moving down in parameter count — a well-quantized 14B generally holds up better on coding tasks than dropping to a 7B, and runaihome’s VRAM model guide maps which quant fits which card. The wrong move is doing this while an un-diagnosed context request is the real culprit, which is why this fix is last, not first.

How each tool surfaces the crash

• Cline shows an API error banner and offers to retry. Retrying re-sends the same oversized request; it will fail identically until you change the context math. Cline’s long system prompt and tool schemas also mean it hits context limits before leaner clients do — related: the tool-use loop bug.
• Continue.dev fails the chat request with a generic provider error; autocomplete may keep working since FIM requests are far smaller. If chat dies while autocomplete lives, that asymmetry itself points at context-size OOM.
• Aider surfaces the 500 through litellm with the raw body attached, which at least includes Ollama’s actual message. Our Aider + Ollama setup guide covers setting num_ctx in .aider.model.settings.yml so Aider and the server agree.

The same debugging order applies to LM Studio backends — see the LM Studio error guide for that server’s equivalents.

FAQ

Why does ollama run work when Cline crashes the same model? Different requests. ollama run starts a bare chat at the server’s default context. Cline requests a large context window and fills it with your repository. The KV cache for that request is the allocation that fails. Compare the CONTEXT column in ollama ps during each session and the difference is usually stark.

Does adding swap fix signal: killed? It can stop the Linux OOM killer from firing, but token generation from swapped memory is unusably slow for interactive coding. Treat swap as a way to survive the occasional spike, not as capacity.

Is restarting Ollama a real fix? It’s a reset, not a fix. A restart evicts every loaded model, which is why things work again — briefly. ollama stop <model> does the same thing surgically, and OLLAMA_KEEP_ALIVE or OLLAMA_MAX_LOADED_MODELS=1 makes it permanent policy.

Should I use q4_0 KV cache to save the most memory? Only if q8_0 still doesn’t fit and you can’t reduce context. Long-context recall degrades first under KV quantization, and coding agents depend on it more than chat does.

How much memory does a model actually need? Weights (roughly the download size for GGUF quants) plus KV cache (scales with context length and parallel requests) plus overhead. There’s no single number per model — a 9GB model can need 12 GB at 8k context or 20+ GB at 64k with an f16 cache. That’s why every fix above is really about the second term.

Sources

• Ollama troubleshooting — official docs
• Ollama context length — official docs
• Ollama FAQ (memory, keep_alive, parallelism, KV cache) — official docs
• Ollama Modelfile reference (num_ctx) — official docs
• Ollama v0.32.6 release — GitHub
• ollama/ollama#8667 — “model requires more system memory (446.3 GiB) than is available”
• ollama/ollama#8571 — “llama runner process has terminated: signal: killed” on 64/128GB Macs
• ollama/ollama#8464 — DeepSeek-V3 “signal: killed” on M4 Max 128GB
• CUDA Out of Memory on Local AI — runaihome.com
• Best local AI models by VRAM — runaihome.com
• WSL configuration settings — Microsoft Learn

Last updated August 7, 2026. Verified against Ollama v0.32.6. Ollama’s memory behavior changes between releases; check the official docs for the current state.