OpenCode was the most-discussed open-source coding agent in our X sample this week, at about 24,900 posts. After the OpenCode Console breach, a fair question is: do I need cloud API keys at all?
For many tasks, no. OpenCode can run against a model on your own machine. Here's how to set it up with the three most common local runtimes.
How it works
OpenCode supports 75+ providers through the AI SDK, and it can also use any OpenAI-compatible server. Ollama, LM Studio and llama.cpp's llama-server all expose one. You add a provider block to opencode.json that says:
npm:@ai-sdk/openai-compatible(the adapter)options.baseURL: where your local server listensmodels: the model IDs to show in the/modelspicker
Put opencode.json in your project root, or in your global OpenCode config.
Option 1: Ollama (easiest)
New to Ollama? Read Ollama for beginners first.
The one-command way. Ollama can configure OpenCode itself:
ollama launch
Pick OpenCode from the list of integrations.
The manual way. Pull a model, then add this to opencode.json:
ollama pull gemma4
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": { "baseURL": "http://localhost:11434/v1" },
"models": {
"gemma4": { "name": "Gemma 4 (local)" }
}
}
}
}
The key under models must match the name ollama list shows. OpenCode's docs use llama2 as the example; swap in whatever you pulled.
Gotcha: if tool calls don't work, OpenCode's docs say to increase num_ctx in Ollama, starting around 16k–32k. Coding agents send long system prompts and tool definitions, and a small default context cuts them off. Our context windows explainer covers why.
Option 2: LM Studio
In LM Studio, load a model and start the local server. Then:
{
"$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": {
"google/gemma-3n-e4b": { "name": "Gemma 3n-e4b (local)" }
}
}
}
}
Replace google/gemma-3n-e4b with the model identifier LM Studio shows for the model you loaded.
Option 3: llama.cpp (llama-server)
llama-server gives you the most control. It serves OpenAI-compatible chat, responses and embeddings endpoints, plus an Anthropic Messages endpoint. Jinja chat templates are on by default. It can download a GGUF straight from Hugging Face with -hf:
llama-server -hf <user>/<model>-GGUF --port 8080 -c 32768
The port gotcha: the current llama-server docs list the default port as 9931, but OpenCode's example config uses 8080. Either pass --port 8080 as above, or change the baseURL.
{
"$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": 128000, "output": 65536 }
}
}
}
}
}
The limit block tells OpenCode how much context the model has, so it can track how much is left. Set context to what you actually started the server with (-c), not the model's theoretical maximum.
Pick the model, then test
Start OpenCode in your project, run /models, and pick your local model. Then give it a small, checkable task, like "add a unit test for X and run it".
Which model? It depends on your hardware:
- Read how much VRAM you need for a local LLM.
- See our comparison of two new open coding models, Flint and Ornith 1.5.
Safety still applies
A local model doesn't make the agent safe by itself. It still runs commands in your terminal. Keep permissions strict and work in a git repo. Our guide to running coding agents safely and the vibe coding security checklist cover the basics.
