Cloud-based AI coding assistants have one consistent property: your code leaves your machine. The prompt you send — which might contain proprietary algorithms, internal API structures, business logic — travels to a third-party server, gets processed, and comes back as a suggestion. Most teams accept this implicitly. Some can't, either for compliance reasons or because the code genuinely shouldn't leave the building.
Running a coding assistant locally changes that equation entirely. The model lives on your hardware. The prompts never leave. The network connection is optional.
Qwen 2.5 Coder via Ollama is the most practical path to this right now. OpenCode is the terminal interface that makes it actually usable.
Why Qwen 2.5 Coder
Qwen 2.5 Coder is Alibaba's code-specialized model family, and it performs substantially better on coding tasks than general-purpose models at the same parameter count. The key benchmark that matters for a coding assistant isn't MMLU — it's HumanEval (Python function completion), MultiPL-E (cross-language), and real-world agentic coding tasks.
The practical sizes: 7B fits comfortably on 8GB of RAM and runs at usable speed on a modern laptop. 14B needs 12-16GB and is noticeably better at multi-file reasoning. 32B needs a Mac Studio or similar — but at 32B it's competitive with much larger cloud models on focused coding tasks.
OpenCode
OpenCode is a terminal-native AI coding assistant built by SST (the same team behind the SST framework). It's designed to work with any OpenAI-compatible endpoint, which means it connects to Ollama out of the box. The interface is a TUI running in your terminal — you navigate files, ask questions about code, make edits, and run commands through a single session without leaving the terminal.
Setup
Install Ollama first. On macOS, the Homebrew path is simplest:
brew install ollama
On Linux, curl the install script:
curl -fsSL https://ollama.com/install.sh | sh
Verify it installed and pull the model:
ollama --version
ollama pull qwen2.5-coder
ollama list # confirm it's there
Install OpenCode:
# Homebrew (macOS)
brew install sst/tap/opencode
# Or via npm
npm install -g opencode-ai
Verify:
opencode --version
The Critical Configuration: num_ctx
OpenCode's default context window configuration is too small for serious coding use. Tool calls — file reads, code searches, edit operations — fail silently when the context fills up. The fix is setting num_ctx explicitly in the OpenCode configuration:
{
"model": "ollama/qwen2.5-coder",
"ollama": {
"num_ctx": 32768
}
}
Edit ~/.config/opencode/opencode.json to add this. 32,768 tokens gives you enough room to have multiple files in context simultaneously, which is the normal working mode for any non-trivial coding task.
Without this change, you'll see OpenCode appear to work fine on small tasks and then start producing odd behavior — missing context, repeated tool failures — when tasks get larger. It's not the model or the tool. It's the context window silently truncating.
Running It
Start Ollama if it's not already running:
ollama serve
Navigate to your project and launch OpenCode:
cd ~/projects/my-project
opencode
The TUI opens with your project context loaded. From there you can ask questions about the codebase, request edits, or have it work through multi-step tasks.
What Works Well, What Doesn't
Qwen 2.5 Coder at 14B+ is genuinely good at focused, well-scoped tasks: explain this function, refactor this module, write a test for this class, fix this bug. It understands project structure well when files are in context and produces syntactically correct code in Python, TypeScript, Go, and Rust reliably.
It struggles with ambiguous, open-ended tasks that require strong world knowledge beyond the codebase: "build me a trading dashboard" starting from scratch will produce something workable but generic. It also has less knowledge of very recent library APIs than cloud models that are updated continuously. When you're working with something released in the last 6 months, expect to paste documentation into context.
For a privacy-sensitive environment or air-gapped development context, those tradeoffs are usually worth it. For greenfield projects where you want maximum capability and don't have data sovereignty constraints, a cloud model still wins.