A developer on a flight to Tokyo opened a terminal, typed a feature request in plain English, and watched an AI agent write the code. There was no internet connection. The agent was OpenCode, the model was running on a laptop through Ollama, and the entire interaction happened without a single byte reaching the cloud. For a team paying for cloud coding seats, the same setup is also a way to cut that bill, and this guide sets out what it saves and what it costs in waiting time.
What is OpenCode and how does it work?
OpenCode is an open-source AI coding agent that runs in the terminal. It is written in Go and provides a text-based interface for interacting with codebases through natural language. Unlike autocomplete tools, OpenCode is an agent: it reads files, runs shell commands, searches code, and applies edits autonomously.
OpenCode is released under the MIT license, according to its GitHub repository. It supports over 75 AI providers through a unified configuration system. That makes it provider-agnostic by design. The same configuration that points at Anthropic or OpenAI in the cloud can point at a local model running on your machine.
OpenCode installs on macOS, Linux, and Windows. The recommended method on macOS is Homebrew with brew install opencode, or the universal install script at curl -fsSL https://opencode.ai/install | bash. The binary is about 157 MB with its dependencies.
Why run a coding agent offline?
The obvious reason is privacy. Every line of code you send to a cloud provider leaves your machine. For proprietary software, regulated industries, or air-gapped environments, that is a non-starter. A local model means your code never reaches a third-party server.
The second reason is cost. Cloud AI providers charge per token. A heavy coding session with frequent file reads and large context windows can cost several dollars per hour. Local models run on hardware you already own. There is no per-token charge, no rate limit, and no monthly subscription beyond the electricity bill.
The third reason is latency. A local model responds as fast as your GPU can generate tokens. There is no network round-trip, no queue, and no API throttling. On Apple Silicon with a model that fits in memory, responses start in milliseconds rather than the seconds-long wait for a cloud endpoint under load.
What do you need before you start?
A local coding agent requires four components: a model runtime, a model file, the agent itself, and compatible hardware.
The runtime is the software that loads the model into memory and exposes it over an API. Ollama is the most popular choice. It runs as a background service on macOS, Linux, and Windows, and provides an OpenAI-compatible endpoint at http://localhost:11434/v1. Install it with brew install ollama on macOS or the installer from ollama.com.
The model is the actual neural network that processes your requests. Open-weight coding models come in many sizes. The right size depends on your hardware budget and your tolerance for latency.
The agent is OpenCode itself. Once installed and configured, it routes all prompts through the local endpoint rather than a cloud API. No code leaves the machine.
For hardware, the minimum viable setup is a machine with at least 16 GB of unified memory or VRAM. Apple Silicon Macs with 32 GB or more are the comfortable choice, and Apple Silicon is noticeably faster than Intel for this. NVIDIA GPUs with 12 GB or more VRAM also work, and the selection of CUDA-optimized models is larger.
How do you connect OpenCode to a local model?
The setup process takes about 15 minutes from a clean machine.
This is the terminal route, with a Modelfile and a config file. A no-terminal route through the desktop app follows below.
Step one: install Ollama and start the service. On Linux, curl -fsSL https://ollama.com/install.sh | sh installs it and sets up the service.
brew install ollama
brew services start ollama
Step two: pull a coding model. The most reliable option as of mid-2026 is Qwen 2.5 Coder 14B. It is dense, not a mixture of experts, which means it responds faster and avoids the latency spikes that MoE models introduce with their gating layers.
ollama pull qwen2.5-coder:14b
Step three: increase the context length. Ollama defaults to 4,096 tokens of context, which is far too small for OpenCode. The system prompt and tool definitions alone consume most of that window. There is almost no room left for actual code. Create a Modelfile to override the parameter:
FROM qwen2.5-coder:14b
PARAMETER num_ctx 32768
PARAMETER temperature 0.2
Then build and register the custom model:
ollama create qwen2.5-coder:14b-opencode -f Modelfile
Step four: install OpenCode.
brew install opencode
Step five: configure OpenCode to use the local Ollama endpoint. Edit ~/.config/opencode/opencode.json to add the Ollama provider:
{
"model": "ollama/qwen2.5-coder:14b-opencode",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen2.5-coder:14b-opencode": {
"name": "Qwen 2.5 Coder (local)"
}
}
}
}
}
Restart OpenCode, run the /model command, and select the local model. Every prompt from that point runs entirely on your machine.
One common mistake: setting a different model for the small_model field. OpenCode uses a secondary model for compaction and title generation. If that model loads separately, Ollama keeps both in GPU memory. That causes contention and can trigger sporadic 500 errors from Ollama’s server. The fix is to set small_model to the same value as model.
Another mistake: leaving CLAUDE.md files in your project directory. If you also use Claude Code, its instructions file tricks local models into calling skills and using response formats they do not support. Set the environment variable OPENCODE_DISABLE_CLAUDE_CODE=1 to prevent that.
Can you set it up without the terminal?
Yes. OpenCode also ships as a normal desktop app, which is the version to hand to staff who never open a shell. Most other open-source coding agents do not: Aider and Pi live in a terminal, Cline lives inside VS Code and OpenHands wants Docker (we line them up in this comparison of local coding agents). The desktop route needs one command at most, to pull a model.
Install Ollama from the app installer at https://ollama.com/download (the full Ollama install is here); it then runs in the background as a service. Pull a model once with ollama pull qwen2.5-coder:7b, which runs comfortably on 16 GB, and confirm it landed with ollama list. As a rough guide, a 7B model is fine on 16 GB and a larger model wants 32 GB or more; the exact tags are at https://ollama.com/library.
Download the OpenCode desktop app from https://opencode.ai/download. On Apple Silicon, take the arm64 build, not x64. If macOS Gatekeeper flags an unidentified developer at first launch, right-click the app and choose Open, once. Skip the CLI and IDE modes OpenCode suggests during onboarding. Then open the model-provider settings, choose Ollama, confirm the address is http://localhost:11434, which is where Ollama listens by default, and select the model you pulled. No API key, no config file, no account. On a machine where both pieces were already installed, our wiring took ten minutes.
The default context length still applies on this route. If long sessions fail, the Modelfile change above is the fix.
What if the model does not appear in OpenCode?
Ollama is not running, or the provider address is wrong. When we wired it up, the model was missing from the dropdown because the Ollama service had not come back after a restart. One ollama serve later it appeared. Check ollama list, then check http://localhost:11434, or set Ollama to start at login. Memory is also sticky: once a model loads it stays in RAM. Run ollama ps to see what is loaded, and pick a smaller model if the machine feels tight.
How do you prove it runs offline?
Open a folder you do not mind the agent touching and ask it to read before it writes:
Open this folder, summarize what is in it, and suggest three things you could help me with.
OpenCode asks permission before it reads files or runs anything. In our run it summarised the project accurately, which showed it was reading the files through the local model. Then test that it can write:
Add a function to utils.py that takes a list and returns the sum, and add a test for it.
It proposed the edit, asked to apply it, and the function and its test were in the file. We then turned off Wi-Fi and ran another small change, and it worked the same. During an online run the network indicator stayed at zero. We also asked it to rename a function used across several files. Reading the code through the language server, OpenCode changed the right references and left unrelated uses of the same name alone, where a find-and-replace would have broken them.
Which models work best for local coding?
Not every model is good at tool calling. A coding agent needs to understand function signatures, produce valid syntax, and follow structured output formats. Many open-weight models fail at one or more of these.
The Qwen 2.5 Coder family is the most reliable local option as of June 2026. The 14B variant gives the best balance of speed and accuracy on consumer hardware. The 32B variant requires 24 GB or more of memory.
For a ranked view, see our local coding models ranked by Mac memory tier, which sets Alibaba’s reported 77.2% SWE-bench Verified for Qwen 3.6-27B against what fits at each memory tier from 8 GB up.
DeepSeek Coder V3 is a strong alternative at 236B parameters using a mixture-of-experts architecture. It scores competitively on coding benchmarks but requires at least 48 GB of memory. That puts it out of reach for most laptops.
Llama 4 Scout is another MoE model at 109B parameters. It scores about 65% on SWE-bench and needs 32 GB of memory. It is usable for code generation but feels slower than the dense Qwen variants in interactive sessions.
Gemma 4 31B runs at about 19 GB in its Q4 quantized form and scores competitively on coding benchmarks. It is available through Ollama and benefits from Apple Silicon’s unified memory architecture. The trade-off is resource intensity: at 31B parameters, it leaves roughly 30 GB of free memory on a 48 GB machine, which is enough for development but leaves less headroom for running large IDEs or containers alongside.
The most important distinction is between dense models and MoE models. Dense models like Qwen 2.5 Coder use all their parameters for every token. MoE models like DeepSeek Coder and Llama 4 activate only a subset of parameters per token, which saves memory but introduces latency from the routing mechanism. For interactive coding, dense models feel faster even when their total parameter count matches an MoE equivalent.
How much does OpenCode with a local model save against a cloud agent seat?
The seat side is published. Cloud coding assistants cost about $19 to $30 or more per developer a month on business plans, from the vendors’ published prices on 17 October 2026. For one developer that is about $228 to $360 or more a year (each monthly price times 12). OpenCode itself is MIT-licensed and charges nothing, and Ollama carries no licence fee either. For a 10-person team the seats come to about $190 to $300 or more a month, or $2,280 to $3,600 or more a year (10 seats at $19 to $30, times 12). The local cost is the hardware each person already has, at least 16 GB of RAM per machine for a 7B model, plus the time it takes to set up.
The cost a team pays instead is time. OpenCode’s system prompt runs to about 51,700 tokens, measured in our OpenCode telemetry investigation, and on our test machine Gemma 4 31B processes a cold prompt at about 65 tokens a second, as recorded in our M4 Pro benchmarks. That works out to about 795 seconds, just over 13 minutes, before the first answer after the model loads (51,700 divided by 65). Later requests can reuse the cached prompt, as our prompt cache benchmark shows, so the wait is paid once per load rather than once per question. We have not measured the first-answer time of Qwen 2.5 Coder 14B with OpenCode’s prompt on this machine.
We have not run OpenCode with a local model on a set of real repository tasks, so we give no completion rate and no saving. What would settle it is ten closed issues from a repository given to the local setup and to a cloud seat, with completions and time per task recorded, and it is on our list.
Set-up time is also unmeasured for the people the desktop route is meant for. We have not timed a non-technical member of staff through the steps on a fresh 16 GB laptop with the network off, and we have not repeated our walkthrough on a clean second machine with install and wiring timed separately, so we give no fresh-laptop time. Both are on our list. OpenCode lets anyone change provider in its settings, so any rule about which repositories may go to a cloud provider has to live in your policy, not in the app.
What trade-offs should you know about?
Local coding agents are not a drop-in replacement for cloud models in every scenario. The trade-offs are real.
Speed is the main limitation. A cloud model like GPT-5 or Claude Opus runs on data-center hardware built for speed. On StrideNote’s M4 Pro, local models generate between 9.6 and 32.3 tokens a second, depending on size. For small edits, the difference is barely noticeable. For large refactors that generate hundreds of lines, the wait becomes significant.
Model quality is another gap. The best open-weight models are roughly six to twelve months behind the frontier. The Qwen 2.5 Coder family is excellent for boilerplate, test generation, and straightforward refactors. For novel architecture decisions or deep debugging, a cloud model still wins. OpenCode makes that easy to handle: switch the provider to a cloud model for that one task, then switch back. The default stays local.
Memory is a hard constraint. Running a 31B model leaves about 30 GB of free memory on a 48 GB machine. Running multiple models simultaneously or keeping a large IDE open alongside the model can push the system into swap, which kills performance to single-digit tokens per second.
Then there is the question of which tasks to delegate. Local models handle code generation, test writing, file refactoring, and documentation well. They struggle with long-context reasoning, multi-file architectural changes, and nuanced debugging. Knowing which task to assign to the local agent versus doing it yourself is a skill that develops with practice.
What should a pilot prove before a team adopts it?
Repeat the walkthrough on one staff machine and treat each step as a pass or a fail. The offline edit comes first, because it is the claim the setup rests on: Wi-Fi off, ask for a change, check the file. Second, watch the network indicator during an online run and confirm it stays at zero. Third, the rename across several files, which shows whether the agent reads code through the language server or edits text blindly. Fourth, restart the machine and check the model is still visible in OpenCode; ours was not until ollama serve brought the engine back, so put the two-line check in your internal notes before rollout.
The air-gapped use case is where local agents justify themselves regardless of these trade-offs. A developer who works on classified systems, proprietary trading algorithms, or unreleased products does not have the option to send code to a cloud API. For that developer, a local model running at those speeds is not a compromise. It is the only option.
The number of developers in that position is growing. With open-weight models improving every quarter, the local coding agent is becoming a standard tool in the engineering workflow. Setting one up is the starting point. Picking which model to load is the next decision. The same Ollama model can also drive autocomplete in your editor and a documents tool to ask questions of your own files, and we spent a week coding with a local AI agent and nothing else.
