OpenCode Local Models with Ollama

OpenCode can send its model requests to Ollama on your own computer. That gives the terminal agent a local inference path while OpenCode still handles files, commands, permissions, and the session. Adding the provider takes minutes. Model choice and context size decide whether it can use tools on your code.

Connect Ollama, test it on a repository, and verify the wider network path before calling the workflow offline. Kimi K3 and GLM-5.2 belong in the datacenter hardware class rather than a laptop download list. Model and provider facts were checked on July 28, 2026; the model sizes, tags, and hardware notes in the table below were verified against Ollama's library on August 10, 2026.

What Local Inference Changes

With a hosted provider, OpenCode sends the prompt and selected code context to that provider for inference. With Ollama, OpenCode calls an API on localhost, and the model runs on the machine serving that API. Ollama documents the local endpoint as unauthenticated because it is local to the host.

The model may still need gigabytes of memory and enough context for the prompt, files, tool definitions, and tool results. A small model that answers coding questions can fail as an agent because it emits the wrong tool call, forgets an instruction, or runs out of context during a multi-file task.

Cost moves from a per-token invoice to hardware, power, memory, and time. The OpenCode application remains free to install, while the machine doing inference becomes part of the bill. Compare total task time and operating cost alongside the missing API charge.

Install Ollama and Pull a Model

Install Ollama from its official documentation. Use the installer for your operating system rather than copying an old package command. After the app or service starts, pull a model from the Ollama library:

ollama pull devstral:24b

That is a real tag on the Ollama model library, and the same command works with any other exact ID shown on a model page. Run it once in Ollama before involving OpenCode. Ask a short coding question, then use ollama ps to see the loaded model, processor split, and allocated context.

Prefer a model whose Ollama page or maker documents tool use. Agent work needs reliable function calls as well as text generation. Start smaller than the largest model that can fit, because a response that takes several minutes makes every plan, search, edit, and retry expensive in wall-clock time.

Open Models That Run Well Locally

The model is rarely the weak link now. Several open coding models are built for the work a local agent actually does, and they matter more than the headline flagship names because they fit on hardware you already have.

Model	Built For	Size (4-Bit)
Devstral 24B	Agentic coding tasks	14 GB
Qwen3-Coder 30B	General coding work	19 GB
Qwen2.5-Coder 32B	General coding, smaller footprint	20 GB
Codestral 22B	Fill-in-the-middle autocomplete	13 GB

Those sizes are the download, not the whole requirement. Ollama's Devstral page calls the 24B model light enough for a single RTX 4090 or a Mac with 32 GB of RAM, comfortably above its 14 GB file.

Parameter count alone does not tell you what fits. A 4-bit 24B model can run on some 24 GB GPUs at a moderate context, while the same model at 8-bit roughly doubles that footprint.

Quantization, context length, runtime overhead, and whether the memory is dedicated GPU or unified system memory all decide whether it runs comfortably. Judge by your repository test, not by the parameter count.

So the real limit is the agent layer around the model, not the weights. A model that reads files, calls tools, and recovers from its own errors inside a harness built for local endpoints will beat a stronger model reached through a path that was not.

Connect OpenCode to Ollama

OpenCode's provider guide includes an Ollama path and a manual OpenAI-compatible configuration. The local service listens at http://localhost:11434, while the compatibility endpoint adds /v1. Use the exact model ID you pulled so it appears in OpenCode's model picker.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "devstral:24b": {
          "name": "Local coding model"
        }
      }
    }
  }
}

The npm field names the provider adapter used by OpenCode. You do not run a package-manager command for this step. Save it as opencode.json in the project root, which OpenCode documents as safe to commit and gives highest standard precedence. Then open OpenCode in the repository, run /models, and choose the local model.

Test the path with a read-only prompt: "Name the primary language, find the test directory, and cite the files you read. Do not edit or run commands." If the answer names the wrong code, fix the model or context setup before granting edit access.

Set Enough Context for Agent Work

Context length is the number of tokens the model can keep in one request. Ollama's current defaults vary with graphics memory: 4K below 24 GiB, 32K from 24 to 48 GiB, and 256K at 48 GiB or more. Those defaults were checked on July 28, 2026.

OpenCode's provider page says to raise num_ctx when tool calls fail, starting around 16K to 32K. Ollama's context guide says coding tools and agents should use at least 64K. The second figure is a workload recommendation, and available memory still decides whether the computer can hold it.

On a system with enough memory, you can start the Ollama service with a larger context:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

A larger window uses more memory. Run ollama ps and check the allocated context and processor split. If much of the model moves to the CPU, a smaller model or context may finish the full task sooner.

Failure	Likely Cause	Next Check
Tool call rejected	Model or context	Raise context
Very slow turn	CPU offload	ollama ps
Forgets files	Window too small	Narrow task
Wrong tool syntax	Model mismatch	Try another model

Choose a Model with a Repository Test

Do not pick from a general benchmark alone. Use one small task from the repository with an objective end: explain a failing unit test, propose the smallest fix, edit one implementation file, and run the focused test. Keep the prompt, permissions, and context the same for every model.

• Record time to the first useful plan.
• Count incorrect file reads and failed tool calls.
• Inspect the diff rather than grading its explanation.
• Run the test yourself after the model stops.
• Note peak memory and whether Ollama offloaded work to the CPU.

Then try a second task that needs repository context, such as changing an API field and its tests. A model that passes the first isolated fix may lose track of a change across several files. Stop when retries exceed the time saved by local inference.

Use permissions during the test. Begin with reads allowed and edits or shell commands set to ask. Local weights leave OpenCode's file and command authority unchanged, so review the model's commands with the same care as a hosted model's.

Place Kimi K3 and GLM-5.2 Correctly

Kimi K3 and GLM-5.2 belong in the flagship server class; neither is a normal laptop choice. Moonshot's July 16 Kimi K3 page names 2.8 trillion total parameters, 16 active experts out of 896, and a context window of one million tokens. It recommends a supernode with 64 or more accelerators for deployment.

That page said full Kimi K3 weights would be released by July 27. When checked on July 28, the page still used future tense and did not link an official weight repository. Hosted Kimi K3 access exists, but a promise to publish weights should not be reported as a completed Ollama release.

Z.ai's official GLM-5.2 model card is live on Hugging Face with an MIT license. It lists 753 billion parameters and a one-million-token context, plus serving paths for vLLM, SGLang, Docker, and quantized variants. Those options make the model self-hostable infrastructure, while performance on one workstation still needs its own test.

For local OpenCode work, choose a smaller model built for tool use. Use Kimi K3 or GLM-5.2 through a hosted provider unless you operate the accelerator capacity and serving stack their full checkpoints require.

Use Local and Hosted Models Together

OpenCode can keep several providers in one model list. A local model can handle code search, explanation, small tests, and repetitive edits. A hosted model can take the task when it needs a larger context, stronger tool use, or better reasoning across many files.

Keep the acceptance test unchanged when you switch. Otherwise you cannot tell whether the model solved the task or the task became easier. Check the active provider before a long run so private code does not move to a hosted API by accident.

A hybrid setup also gives you a fallback when the local service is slow or a hosted provider is down. It does not require every task to bounce between models. Pick one model for a run, finish or stop the run, then restart with the other model and the same state.

Check the Whole Privacy Boundary

Local Ollama inference keeps that model request on the local endpoint. OpenCode can still fetch a URL, call a remote MCP server, push to Git, install a package, or switch to a hosted provider. Each action has its own destination, credentials, and logs.

For a repository with strict data rules, that makes the boundary a checklist rather than a setting. Work through it before the first run:

• List every enabled provider and tool.
• Deny web access and remote MCP tools the task does not need.
• Use a local Git remote, or no remote at all.
• Check where the package manager fetches from.
• Account for telemetry and operating system traffic.
• Inspect outbound traffic when the requirement calls for proof.

Say "local model inference" when that is all you have verified. "Offline workflow" is a claim about every line above, not about where the weights sit.

How Cursor's Local Path Differs

This is the question readers arrive at from the comparison, and the primary docs answer it more plainly than the marketing does. Cursor can use a local model, and the road is bumpier than pointing OpenCode at Ollama.

You override the OpenAI base URL in settings and point it at Ollama or LM Studio, both of which expose an OpenAI-compatible endpoint. Three catches follow, and all three are real:

1. Cursor's backend runs sandboxed and cannot see localhost, so it needs a public HTTPS tunnel to reach your machine, and the request still travels out through Cursor and back.
2. A custom endpoint can supply standard chat models, while Tab autocomplete still uses Cursor's built-in models.
3. Cursor can send more context than a small Ollama default can hold, so raise the context only as far as your model and hardware allow.

Local models	OpenCode	Cursor
How	Native provider config	Base URL plus a tunnel
Truly offline	Yes	No; routes via its backend
Autocomplete	Your model	Cursor's built-in models
Context default	Your model's full window	Raise it to fit your hardware

One route people try does not carry across. Ollama's own VS Code path runs through GitHub Copilot Chat, which Cursor does not ship because it replaces it with its own AI, so the base-URL override is the method that works.

The wider head-to-head, including pricing, the agent layer, and who each tool suits, is in Cursor vs OpenCode.

FAQ

Does OpenCode work with Ollama?

Yes, by either of two documented paths: the named Ollama provider, or a manual OpenAI-compatible block pointing at http://localhost:11434/v1. Prefer the manual block when you want the model list and its labels committed alongside the repository. Neither path invents a model, so pull it in Ollama first.

Does a local model need an API key?

Not for the local request: Ollama's API at http://localhost:11434 does not require authentication. The question is per destination rather than per tool, so one OpenCode session can still need credentials for Ollama cloud models, remote tools, or Git hosting. Check which provider is active before assuming no key is involved.

Why do OpenCode tool calls fail with Ollama?

Two common causes look identical from outside: the model does not follow tool syntax, or its context is too small. Raise num_ctx first, since OpenCode suggests 16K to 32K and Ollama's coding-agent guidance recommends at least 64K. If the same call still fails at the larger window, the model may be the problem rather than the context window.

Can I run Kimi K3 or GLM-5.2 on a laptop?

No, not in their full flagship form: Moonshot recommends 64 or more accelerators for Kimi K3, and GLM-5.2 carries 753 billion parameters. The test is not whether a quantized file fits on disk, but whether the agent finishes your repository task at an acceptable speed. Use hosted access and keep the local slot for a smaller tool-use model.

Is a local model in Cursor really local?

Only the weights are. Cursor documents that requests still pass through its backend even when you supply your own endpoint, and that backend cannot reach localhost, so the setup needs a public HTTPS tunnel. If your reason for going local is a data rule rather than cost, that request path is the thing to check first.

Start Small and Verify the Whole Path

OpenCode with Ollama is a sound fit for private routine work when a smaller model can follow the tool protocol, hold enough context, and finish your repository test at a useful speed. The setup is easy to connect, but the model and hardware decide whether it works as an agent.

Start with one model, a 64K context only if the machine can hold it, and a narrow task with a known test. Keep a hosted provider for jobs that exceed that setup, and describe privacy in terms of the whole configured workflow rather than the location of one model.