OpenCode Local LLM Setup: Ollama, LM Studio and llama.cpp Configs (2026)

An OpenCode local LLM setup has two parts: a server on your machine that speaks the OpenAI-compatible API, and a provider block in opencode.json that points at it, such as Ollama's /v1 endpoint on port 11434, LM Studio's on port 1234 or llama.cpp's llama-server. Choose a model trained for tool calling, give it at least 64K tokens of context and make it the default.

OpenCode is the MIT-licensed terminal coding agent maintained in the anomalyco/opencode repository. It reaches models through the AI SDK and the Models.dev catalogue, and it treats any OpenAI-compatible server as an ordinary provider, so running it on a local model is a matter of configuration rather than workarounds.

The config blocks, defaults and environment variables below come from OpenCode’s documentation and Ollama’s integration page, read on 14 October 2026 against OpenCode 1.19.0, released on 11 October. Model choice is out of scope here: our open-weight coding model guide compares the candidates, and our agent comparison sets OpenCode against Claude Code and Hermes Agent. If you would rather keep Claude Code’s interface, the Claude Code local setup guide covers its Anthropic-format route; the Pi coding agent guide covers a smaller agent that skips approval prompts.

How OpenCode connects to a local model

Every local server below is added as a custom provider in OpenCode’s config. The pieces are the same each time:

• npm names the AI SDK package. Use @ai-sdk/openai-compatible for servers with a /v1/chat/completions route, or @ai-sdk/openai if the model is served through /v1/responses.
• options.baseURL is the server’s address, including /v1.
• models maps each model ID the server knows to a display name and, optionally, a limit object with context and output token counts. Hosted providers get those limits from Models.dev; for a local server, set them yourself so OpenCode knows how much room is left.
• model sets the default as provider_id/model_id; /models switches inside a session.
• options.apiKey and options.headers are optional. They matter for an authenticated server elsewhere on your network, and the key accepts {env:VAR} substitution so it stays out of the file. Running /connect and choosing Other stores a key in ~/.local/share/opencode/auth.json instead.

OpenCode reads JSON or JSONC from ~/.config/opencode/opencode.json for user-wide settings and from opencode.json at the project root, which takes precedence. Files are merged rather than replaced, and OPENCODE_CONFIG points at a custom file.

OpenCode 2 uses a different shape

OpenCode 2 installs from a separate script, https://opencode.ai/v2/install, which fetches beta builds, and it cannot share the opencode command with OpenCode 1. Its config uses a providers key with a package field and settings.baseURL. It also discovers Ollama on 127.0.0.1:11434 and LM Studio on 127.0.0.1:1234 by itself, while discovered vLLM models start with tools disabled. The steps below are for OpenCode 1, the current npm release.

OpenCode with Ollama

1. Pull a model that supports tools:

   ollama pull qwen3-coder:30b

2. Set the context on the server. Ollama’s OpenCode page says OpenCode needs 64K tokens or more, while OpenCode’s provider docs suggest starting around 16K to 32K if tool calls fail; aim for Ollama’s figure. Ollama’s OpenAI-compatible API has no way to pass a context size, so either start the server with one:

   OLLAMA_CONTEXT_LENGTH=65536 ollama serve

   or bake it into a model variant with a Modelfile, run ollama create qwen3-coder-64k, and use that name in the config:

   FROM qwen3-coder:30b
   PARAMETER num_ctx 65536

3. Let Ollama do the wiring with ollama launch opencode, or ollama launch opencode --config to configure without starting a session. Ollama says the launcher does not overwrite ~/.config/opencode/opencode.json, and models defined only in that file do not appear in its picker.

4. Or write the provider yourself. This is the documented Ollama block with a real model and a limit added:

   {
     "$schema": "https://opencode.ai/config.json",
     "provider": {
       "ollama": {
         "npm": "@ai-sdk/openai-compatible",
         "name": "Ollama (local)",
         "options": {
           "baseURL": "http://localhost:11434/v1"
         },
         "models": {
           "qwen3-coder:30b": {
             "name": "Qwen3-Coder 30B (local)",
             "limit": {
               "context": 65536,
               "output": 16384
             }
           }
         }
       }
     },
     "model": "ollama/qwen3-coder:30b"
   }

Run ollama ps while OpenCode works to confirm the context the model was loaded with matches the limit you declared.

OpenCode with LM Studio

1. Download a model and load it with a 64K window. The optional --identifier flag gives it a shorter API name:

   lms get qwen/qwen3-coder-30b
   lms load qwen/qwen3-coder-30b --context-length 65536

2. Start the local server:

   lms server start --port 1234

3. Add the provider. OpenCode’s documented block uses google/gemma-3n-e4b as its example; swap in the identifier you loaded:

   {
     "$schema": "https://opencode.ai/config.json",
     "provider": {
       "lmstudio": {
         "npm": "@ai-sdk/openai-compatible",
         "name": "LM Studio (local)",
         "options": {
           "baseURL": "http://127.0.0.1:1234/v1"
         },
         "models": {
           "qwen/qwen3-coder-30b": {
             "name": "Qwen3 Coder 30B (local)",
             "limit": {
               "context": 65536,
               "output": 16384
             }
           }
         }
       }
     },
     "model": "lmstudio/qwen/qwen3-coder-30b"
   }

Slashes inside the model ID are fine: OpenCode’s own example default is lmstudio/google/gemma-3n-e4b. LM Studio lists Qwen3 Coder 30B in GGUF and MLX builds, so the same config works on a Mac running the MLX version.

OpenCode with llama.cpp

OpenCode’s llama.cpp example expects llama-server on port 8080. Since build b11521 of 9 October 2026 the server defaults to port 9931, so pass the port explicitly, along with an alias that matches the model key in your config:

llama-server -hf unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:Q4_K_M \
  --alias qwen3-coder:a3b --host 127.0.0.1 --port 8080 -c 65536 --jinja

Then add the provider. This is the block from OpenCode’s docs with the limits lowered to match a 64K server; the documented example declares 128,000 tokens of context and 65,536 of output:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama-server (local)",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "qwen3-coder:a3b": {
          "name": "Qwen3-Coder: a3b-30b (local)",
          "limit": {
            "context": 65536,
            "output": 16384
          }
        }
      }
    }
  },
  "model": "llama.cpp/qwen3-coder:a3b"
}

Keep limit.context at or below the -c value. If the server holds less context than OpenCode thinks it has, the server runs out of room before OpenCode’s automatic compaction steps in. The README ties OpenAI-style tool calling to --jinja, which current builds enable by default; the -hf file is a community quantization, so validate it before wider use. For a GPU server shared by a team, our inference server comparison weighs llama.cpp against vLLM and Ollama.

Picking an OpenCode local model

OpenCode’s model page is blunt about the bar: few models are good at both generating code and calling tools, and the agent depends on the second skill for every file read, edit and shell command. A model that writes good code but formats tool calls badly will stall.

Model selection is covered in depth in our comparison of open-weight coding models, and the VRAM calculator checks whether weights plus your chosen context fit. As reference points, three tool-capable models with Apache 2.0 licences that Ollama packages:

• Qwen3-Coder-30B-A3B-Instruct (qwen3-coder:30b, a 19 GB download): a mixture-of-experts model with 3.3B of its 30.5B parameters active per token, whose card highlights tool calling.
• Devstral Small 2 (devstral-small-2:24b, 15 GB): Mistral’s 24B coding model with a 256K window on its card.
• gpt-oss-20b (gpt-oss:20b, 14 GB): OpenAI’s 21B model with 3.6B active, which OpenAI says fits within 16 GB of memory.

Local MCP servers and permissions

Adding a local MCP server

OpenCode runs MCP servers as child processes when their type is local. The documented example uses the reference test server:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mcp_everything": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

Local entries also accept environment, cwd, enabled and timeout, which defaults to 5,000 ms for fetching the tool list. Remote servers use type: "remote" with a url, optional headers and OAuth. OpenCode’s docs warn that every server adds to the context, and name the GitHub MCP server as one that adds many tokens. On a 64K local window that cost is real, so enable servers per project rather than globally.

Tightening the defaults

OpenCode’s permission defaults are permissive: most actions are allowed, doom_loop and external_directory ask, and reads of .env files are denied. The restricted plan agent asks before edits and shell commands, while the default build agent has every tool enabled. A stricter project setting, using the documented rule syntax:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": {
      "*": "ask",
      "git *": "allow",
      "rm *": "deny"
    }
  }
}

The last matching rule wins, and opencode --auto approves anything not explicitly denied. Permission rules decide what the agent may attempt; they are not isolation. OpenCode has no built-in sandbox, but it publishes a container image (ghcr.io/anomalyco/opencode), and our guide to isolating agents that run code covers containers, gVisor and microVMs.

Keeping code on your machine

A local provider keeps inference local. OpenCode has other features that talk to the network, each with a documented switch:

• Other providers. enabled_providers makes OpenCode ignore every provider not listed, even when API keys sit in your environment or in ~/.local/share/opencode/auth.json.
• The small model. OpenCode uses small_model for chores such as session titles and, when it is unset, tries a cheaper model from your provider before falling back to the main one. Set it explicitly.
• Sharing. /share syncs the conversation to OpenCode’s servers behind a public link. The default is manual; "share": "disabled" turns it off for a project.
• Updates and catalogues. "autoupdate": false, OPENCODE_DISABLE_MODELS_FETCH for the Models.dev refresh and OPENCODE_DISABLE_LSP_DOWNLOAD for language-server downloads.
• Web tools. webfetch retrieves URLs directly, and websearch is available only with OpenCode’s own providers or when OPENCODE_ENABLE_EXA or OPENCODE_ENABLE_PARALLEL is set.

Added next to the provider block from the Ollama section, those settings look like this:

{
  "$schema": "https://opencode.ai/config.json",
  "enabled_providers": ["ollama"],
  "model": "ollama/qwen3-coder:30b",
  "small_model": "ollama/qwen3-coder:30b",
  "share": "disabled",
  "autoupdate": false,
  "permission": {
    "webfetch": "deny",
    "websearch": "deny"
  }
}

Two more points for teams. Running opencode serve starts a server on 127.0.0.1 port 4096; set OPENCODE_SERVER_PASSWORD before binding it to any other address. And OpenCode’s documentation does not describe usage telemetry, so confirm the result with egress monitoring rather than by reading config files.

Testing, troubleshooting and Windows

Testing the setup

1. Ask the server which model IDs it serves. Ollama and llama-server both answer the OpenAI-style models route:

   curl http://localhost:11434/v1/models

2. Check that OpenCode lists the same IDs under your provider:

   opencode models ollama

3. Run a one-shot task without the terminal UI:

   opencode run -m ollama/qwen3-coder:30b "List the top-level folders in this repository"

If a step fails, start OpenCode with --log-level DEBUG and read the newest file in ~/.local/share/opencode/log/, where it keeps its ten most recent logs.

Common errors

• ProviderModelNotFoundError means the model reference is wrong. It must read <providerId>/<modelId>, using the key from your provider block and the exact model key beneath it.
• AI_APICallError can come from a stale provider package. OpenCode installs provider packages on demand and caches them in ~/.cache/opencode; clearing that folder forces a fresh download, so on a machine without internet access, populate the cache before you go offline.
• Tool calls that never happen or repeat usually mean too little context or a model without tool training. Raise the server’s context first; the doom_loop guard asks you after three identical calls in a row.

Windows and WSL

OpenCode recommends running it inside WSL on Windows for better file-system performance and terminal support. Natively, it installs with choco install opencode, scoop install opencode or npm install -g opencode-ai, and OPENCODE_GIT_BASH_PATH tells it where Git Bash lives.

If OpenCode runs in WSL 2 and the model server runs on Windows, the default NAT networking means localhost inside WSL is not the Windows host. Use the host IP that Microsoft’s docs show how to find, with the server listening beyond 127.0.0.1, or switch on mirrored networking on Windows 11 22H2 or later so localhost works in both directions. Behind a corporate proxy, OpenCode’s network page says to set NO_PROXY=localhost,127.0.0.1, because the terminal UI talks to its own local server.

How VDF AI fits

OpenCode with a local model is a sound way for one developer to keep code in-house. Rolling it out to a department raises other questions: whose server hosts the model, who approves models and MCP servers, and where the record of prompts and edits lives. VDF AI does not run, host or integrate with OpenCode.

VDF Code is VDF AI’s governed coding assistant for that stage. Per its product page it deploys on your own Kubernetes, OpenShift or bare-metal estate, air-gapped sites included, with model allow and block lists, tool restrictions per repository and an audit log of prompts, model calls and edits. For model serving, VDF AI Router registers Ollama and other on-premises deployments next to approved cloud models, and its air-gap mode keeps routing on local models only.