To use OpenCode with local models, you run a local inference server that exposes an OpenAI-compatible API endpoint, then point OpenCode at that endpoint via a provider configuration and select the model in the UI. The key idea is that OpenCode doesn’t need the model to be “built in”; it needs a provider entry with a baseURL and a model name mapping so it can send chat/tool requests to the right place. OpenCode’s provider docs include explicit local examples (for example, Ollama, LM Studio, and llama.cpp via a local server) that all follow the same shape: define a provider using an OpenAI-compatible SDK adapter and set options.baseURL to a localhost URL ending in /v1.
A practical workflow is: start your local model server first, confirm it’s listening, then configure OpenCode. For instance, with a local provider you’ll define something like provider.ollama (or provider.lmstudio) in your OpenCode config, set npm to an OpenAI-compatible adapter, set options.baseURL to the local endpoint (examples in the docs include http://localhost:11434/v1 and http://127.0.0.1:1234/v1), and list one or more models under models so they appear in OpenCode’s model picker. Then run opencode, use /models to pick your local model, and start working. If you want to keep things safe while you test, review your tool permissions: OpenCode tools can read/write files and run shell commands, and permissions control whether actions run automatically, are blocked, or require explicit approval. That matters more with local models because you might iterate quickly and forget you allowed a high-impact tool like shell execution.
Once local models are wired up, the “gotchas” are mostly operational: latency and capability depend on the model and your hardware, and you need your local endpoint to stay stable (port, hostname, firewall rules). If your model server runs on another machine (a home GPU box, for example), treat it like any internal service: use an SSH tunnel or a private network, and set baseURL to something reachable from your dev laptop without exposing it publicly. From a build-system perspective, local models pair nicely with local-first stacks: if you’re prototyping semantic search or long-term “project memory,” you can store embeddings in a local Milvus instance during development and have OpenCode help you generate the ingestion/query code, then later switch to Zilliz Cloud when you want managed hosting. The important part is not to confuse “OpenCode runs locally” with “everything runs locally by default”: you choose the boundary by choosing your model endpoint and your permissions, and OpenCode will follow that boundary.