OpenCode

OpenCode is a standalone agentic coding harness — a terminal-and-IDE agent that uses tool calls to read, edit, and run code against a project. It positions itself as a more configurable alternative to vendor-locked tools (Claude Code, Codex) and ships first-class support for pointing at any OpenAI-compatible endpoint, including locally-served models via llama.cpp.

What it does

A long-lived agent loop with a stable tool surface (file read/write, shell, search, edit), driven by an LLM accessed through a configurable provider. The differentiating choices are:

• Provider-agnostic. Configured via a JSON file with provider URL, model name, and per-provider tweaks. Local llama.cpp servers, OpenAI, Anthropic, Groq, and the bundled ZEN model set are all first-class.
• AGENTS.md as the project contract. OpenCode reads a project-level AGENTS.md (analogous to Cursor Rules or CLAUDE.md) for context, conventions, and rules. This is the file that holds nonstandard filename-prefix requirements, typing constraints, comment styles, etc.
• Bundled ZEN model set. Vetted hosted models on a hosted subscription, including free tiers. Useful for users who want OpenCode-the-harness without separately picking a model and provider.

For Vyacheslav's coding-agent tests on local 16 GB models, OpenCode + llama.cpp was the rig. He picked it over Cline, Kilo Kode, Roo Code, and Zed for "stability and simplicity of setup."

How it pairs with local models

The pairing requires three things on the llama.cpp side and one on the OpenCode side:

• --jinja flag on llama-server — required for the chat template to render tool calls in the format OpenCode expects. Without it, the model never sees the tool list.
• A quantization that the specific model architecture survives — see llm-quantization.
• Enough VRAM headroom for both model and KV cache — see kv-cache-sizing and moe-cpu-offload.

On the OpenCode side, provider config points at http://localhost:8080/v1 (or wherever llama.cpp is bound) and sets the model name. For Qwen 3-family models, the OpenCode config also needs extra_body.chat_template_kwargs.enable_thinking: false to actually disable thinking mode — the --reasoning off flag at the server level is not enough (see thinking-mode-rule-erosion).

Caveats from real use

• The "Thinking…" status indicator in OpenCode's UI is a generic in-flight indicator, not evidence the model is generating thinking tokens. Don't take it as confirmation that reasoning mode is on.
• Skills designed for large hosted models (Context 7, Superpowers, anything that injects a lot of system prompt) overwhelm small local models' context. Vyacheslav recommends "caveman" or no skills for local-model setups.
• The system prompt + skills + MCP context all consume context window before the user's first message. This compounds with small models' already-tight context budgets.

Why it shows up in the wiki

OpenCode is the harness against which several findings get measured: thinking-mode-rule-erosion was discovered by running through OpenCode with AGENTS.md rules; the MoE offload numbers in moe-cpu-offload are with OpenCode driving the inference. It's also one of the harnesses in cli-anything's cross-harness skill distribution.

Related

• llama.cpp — the inference engine OpenCode points at for local models
• lucumr-local-models — Ronacher's critique of local-LLM UX gaps; OpenCode is a candidate to fill some of them
• cli-anything — cross-harness skill packaging that includes OpenCode
• peon-ping — has hooks for OpenCode among other harnesses

Repo: https://github.com/sst/opencode · TypeScript · MIT