OpenCode: the coding agent that runs at home

The video is in Italian; this page is the written version in English.

People put panels on the roof for two reasons, and neither of them is the technology: at the end of the month the bill stops coming, and what they consume does not pass through someone else’s meter. The price is honest: what you can switch on depends on how big the system is.

OpenCode is that, applied to coding agents. The brain is a model running on your own machine: no subscription, no data leaving, and it works unplugged from the network. The limit is the roof.

Not a chat: an agent

The difference from a chat window where you paste code is substantial. OpenCode lives in the terminal and has its hands on the system: it reads and writes files, runs bash or PowerShell commands, navigates the project’s patterns. That is level 3-4 autonomy on the agent scale, driven by a local LLM acting as the decision-making brain.

Chat                                  Terminal agent
you copy the code, it suggests        it opens the files, edits them,
you paste the answer back             runs the commands and reports back

It supports more than seventy-five providers and the MCP protocol: on the integration side it is a platform, not a single tool.

OpenCode versus Claude Code: two philosophies

	OpenCode	Claude Code
Cost	Free	Subscription, about €18/month
Network	Works offline (with Ollama)	Connection required
Data	Stays on the machine	Travels through the cloud
Reasoning quality	That of the local model you pick	Excellent
Control	Total	Delegated to the provider

There is no winner: there are two different trade-offs. On one side better reasoning paid for with a fee, a connection and your data; on the other, full control paid for with hardware.

Where it pays off, and where you need something else

OpenCode is a surgical tool: it is at its best working deeply on the files of a project you have locally — writing code, debugging, editing scripts.

If instead you need to search across information — fifty PDFs to query — or a comfortable interface to converse in, the right road is a different one: an Open WebUI on top of a RAG does that job far better. Different tools for different jobs.

Three families of use cases

Studying. From the terminal, over a folder of notes: have it read a chapter and generate ten questions to check your understanding, compare two sets of notes to find the shared themes, produce a structured summary out of dozens of Markdown files.

Coding. Sweep an entire project looking for silent bugs before they reach production, write the unit tests nobody ever writes, refactor old functions into more modern paradigms.

Automating. Bulk-rename the extensions of hundreds of files, generate an index mapping code files and their internal functions, run through thousands of log lines and sort the errors into a tidy report.

And it is not limited to what sits on your disk: through MCP you connect external tools — the browser, GitHub repositories — and the reach widens.

The two lines everybody forgets

The prerequisites are Node.js and Ollama already running; you install the package with npm and write an opencode.json declaring Ollama as the provider. So far, routine. Then come two details that separate a setup that works from a frustrating one.

{
  "provider": "ollama",
  "tools": true        // without this line the agent looks but cannot touch
}

tools: true. Without explicitly enabling tools the agent is effectively paralysed: it reasons, but it cannot execute anything on the system.

A context window of at least 64,000 tokens, set by hand in a model file. That is its short-term memory: below that threshold, halfway through a multi-step operation the agent has already forgotten the initial instructions. The reason sits in the context window.

Hardware: the three kilowatts on the roof

Machine	Model within reach	Experience
Mac M3, 16 GB	8 billion parameters	Basic: 1-2 step tasks
Mac M4 Pro, PC with an RTX 5070	14 billion	Covers most operations
High-end PC, 64 GB	32 billion	Excellent results

The minimum recommendation for a smooth experience is 14 billion parameters, for instance Qwen3 14B. Below that, with 8B models, the degradation is not gradual: the agent loses its way in long tasks and — the most telling symptom — gets the syntax for calling its own tools wrong, so it fails without even trying. That is not a software defect: it is a system too small for the appliance. To size it there is the lesson on hardware for LLMs, and quantisation moves the threshold up a notch.

The workflow, in five steps

1. terminal in the project folder
2. launch the agent
3. the request, in plain language
4. the agent analyses, reads the files and proposes the changes
5. human review: approve or correct   ← the loop closes here

Step five is not a formality. The agent has permission to write and to execute: final control stays with human intelligence, and it has to be exercised every time.

Is the cloud becoming obsolete?

The question comes naturally when you watch how fast local models are becoming powerful and compact on everyday hardware. There is no answer, but there is a direction: the more decent the system on the roof, the weaker the case for the monthly fee. The full picture of the trade-off is in cloud versus local.

In short

Concept	In one line
What it is	A terminal agent that reads, writes and executes, with a local model
Why pick it	Free, offline, data that never leaves the machine
When you need something else	Querying many documents, or wanting a comfortable interface
The critical config	tools: true and a context of ≥ 64k tokens
The hardware threshold	14B minimum for a smooth experience; below it, the agent calls its tools wrong
The step you never skip	Human review of the proposed changes