This is a build log, not a brochure. The goal was specific: get a coding agent running in a normal app window, answered by a model on our own machine, and watch it edit real code with the network off. We did, and it worked. Here is exactly what happened, including the one step that confused us for a minute.
If you want the clean step-by-step, the Playbook covers that. This is the version with the reasoning and the snags left in.
The goal, stated plainly
We did not want an agent in a terminal, and we did not want one that ships our code to a server. We wanted Cursor’s shape, an app you open, with a model we own underneath. OpenCode plus Ollama is that combination, and we had both pieces already from the studio stack. The job was wiring, not installing from scratch.
Starting point
Two things were already running:
- Ollama, serving on
http://localhost:11434, with our coding model pulled. - OpenCode, the desktop app, installed and opening to a clean window.
If you are starting cold, install those first. Confirm Ollama is alive with ollama list before you go further. We learned to always check that first, for a reason that shows up below.
The wiring
In OpenCode, the model lives in provider settings. We chose Ollama as the provider, confirmed the address was http://localhost:11434, and expected our model to appear in the dropdown.
It did not appear. This was the confusing minute.
The fix was dull and worth knowing: Ollama was not actually running in that moment. The background service had not come back up after a restart. One ollama serve later, the model showed up in OpenCode immediately. The lesson we now treat as a rule: if a local tool cannot see your models, the engine is not running or the address is wrong. Check ollama list and check http://localhost:11434. It is almost always one of those two.
With the model selected, the wiring was done. No API key, no config file, no account.
The first real test
We opened a small project folder in OpenCode and typed a prompt that forces the agent to read before it writes:
Open this folder, summarize what is in it, and suggest three things you could help me with.
OpenCode asked permission before reading anything. We approved. It summarized the project accurately, which told us it was genuinely reading files through the local model and not guessing.
Then the test that matters, can it 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 we approved. The function and its test were in the file. Normal app window, real edit, model on our disk.
The part we wanted to see
We turned off Wi-Fi and ran another small change. It worked the same. That was the moment worth filming: an AI coding agent, editing real code, with no connection at all. Nothing was leaving the building because there was no “out” for it to leave by.
We also watched the network indicator during an online run. It stayed at zero. The privacy story is not a claim here, it is observable.
What it is good at, and where it stops
On ordinary work, refactors, small features, bug fixes, test scaffolding, the local setup carried its weight. The LSP-aware reading helped: the agent understood symbols and references rather than pattern-matching, which made its edits more accurate than we expected from a local model.
Where it stops is the model’s ceiling, not the app’s. On a genuinely hard problem, a frontier cloud model is still ahead. OpenCode makes that easy to handle: switch the provider to a cloud model for that one task, then switch back to local. The default stays on our machine; the cloud is the exception we reach for on purpose.
Snags worth flagging
- Models not appearing. The engine is not running, or the provider address is wrong. This was our one real hiccup and it has a two-line fix.
- Architecture on Apple Silicon. Take the arm64 build of OpenCode, not x64.
- First launch on macOS. Gatekeeper may flag an unidentified developer. Right-click, Open, once.
- Onboarding noise. OpenCode offers CLI and IDE modes during setup. We skipped them. The desktop app pointed at Ollama was the whole build.
What this changed for us
It collapsed a category. We expected an AI coding agent to mean a terminal tool or a VS Code extension or a Docker container. Instead it is an app on the Dock, running a model we own, that keeps working when the internet does not. That reframing is the reason this is in production and not in the experiments folder.
We did not tell you it is the best agent on the market. We told you what we built and what we watched it do. You make your own call. Curious about these things. You should be too.
Harness your curiosity.
— Stridenote · № 002