OpenCode with Ollama not working: how to fix it on Windows

How to fix it on Windows, step by step

Ollama only reads the OLLAMA_CONTEXT_LENGTH variable when it starts, so first close it completely, including the icon in the system tray. Then choose whether you want the change for this session only or permanently.

How to check that it works now

Don’t assume it’s fixed because it seems to work now. Run these checks with the model loaded, while OpenCode is working or right after.

• Run ollama ps: the CONTEXT column must show 32768 (or the value you set), and PROCESSOR should say “100% GPU”. If it still shows 4096, Ollama didn’t read the variable: you didn’t fully close it, or you set it in another window.
• Check the log: searching for “truncating input prompt” (the command is below) should show no new lines since you started Ollama.
• Watch what it does: the agent uses its tools (glob, read, write) and the file you asked for shows up in the folder. With 32,768, gemma4:12b created it in 27 seconds.
• Watch the memory: with 32,768 of context and gemma4:12b, the graphics card’s used memory hovered around 8.4 GB. If you’re close to your card’s limit, read Ollama not using the GPU on Windows.

How to confirm it’s this: what the agent does and what the log says

The screen shows no error. You see an agent acting as if it never read your message, because it didn’t. In our tests, gemma4:12b started planning a “Remember Me” feature for a sign-in form that didn’t exist and called its task list 65 times until the 400-second time limit ran out. qwen3.5:9b, given the same request, replied that it had no access to files.

The definitive proof is in Ollama’s log. If you use the app, it’s at %LOCALAPPDATA%\Ollama\server.log; if you run ollama serve by hand, it prints in that same window. Look for the warning “truncating input prompt”, which means Ollama cut down what it received. In our tests it appeared 66 times: OpenCode sent between 22,159 and 23,004 tokens and Ollama kept about 2,050.

Why it happens: 4,096 tokens of context against about 23,000 of instructions

Ollama sets the default context from the memory of your graphics card: 4k tokens below 24 GiB, 32k between 24 and 48 GiB, and 256k from 48 GiB up (context length in the Ollama documentation). With 16 GB, which is typical for a home PC with a good graphics card, you stay at 4,096.

Before your message, OpenCode sends its internal instructions, the description of each tool (read, search, write, run…) and everything it finds in your configuration: AGENTS.md, skills and MCP servers (connectors to other programs). In our tests that added up to 22,919 tokens. With an empty global configuration it dropped to 7,440, measured with another local server and the same OpenCode. Even the clean version doesn’t fit in 4,096: the problem is not your configuration, it’s the default.

That’s why OpenCode’s documentation recommends raising num_ctx to 16k–32k if tools don’t work (OpenCode providers), and Ollama’s own OpenCode integration asks for 64k or more (Ollama + OpenCode). With 32,768 it worked; 64k takes up more graphics card memory.

The other leak: small_model and your global configuration

OpenCode uses a second model, small_model, for light tasks such as titling a session. According to its documentation, if you don’t set it, it looks for a cheaper one from the same provider and, if there isn’t one, uses the main model (OpenCode configuration). The problem comes if you already have one defined in the global configuration (~/.config/opencode/opencode.json): the files are merged, and that global small_model stays active in a project you thought was local.

With a global configuration loaded (AGENTS.md, skills, a browser MCP server and a small_model from a cloud provider), the prompt grew to 23,569 tokens. The agent got stuck in a loop, reading, thinking and summarizing the conversation four times in 11 minutes without writing anything, and opencode.exe opened an HTTPS connection to that provider. With the global configuration empty and model and small_model pointing to the local server, the prompt dropped to 7,440 tokens and the table came out right in 2 min 50 s. That test used another local server and a larger model, not Ollama, but the leak is in OpenCode, not in the server.

What to expect from a local model with OpenCode

Fixing the context makes OpenCode work; it doesn’t make a 9–12B model work well. With 32,768 tokens, gemma4:12b used the tools, but it put the turn number in the date column and assigned responsibility to whoever spoke in each turn, including a “Send to client → Marta” item that the minutes left without an owner. qwen3.5:9b read the file and did nothing else (17 s). A local model with an agent is good for small tasks you can check, not for handing over work. All the data and the log are in our OpenCode test with a local Ollama model.

Rare cases

• “does not support tools”: this is a different problem. Ollama rejects the tools if the model doesn’t declare them. Check with ollama show <model> whether tools appears among its capabilities, or use another model; raising the context won’t fix it.
• Empty reply after a minute: models that reason can use up the context while they think. qwen3.5:9b used 3,661 of 4,096 tokens reasoning and returned empty text through the /v1 API; with reasoning_effort: "none" it answered in 3.6 s. We explain it in Ollama returns an empty response.
• More context isn’t free: it takes up graphics card memory. If the model no longer fits, Ollama splits it with your system RAM and the speed drops sharply.
• OpenCode doesn’t load your skills: they go in the .opencode/skills folder and need the YAML header at the top.