We wanted to know what it actually feels like to do real coding work with a fully local agent, not for an afternoon but for a working week. So we set a rule and kept it: OpenCode pointed at a local Ollama model, no cloud agent, no quiet fallback when something got hard. If the local setup could not do it, we would feel that, write it down, and only break the rule on purpose. For a team weighing a local agent against paying for cloud agent seats, the week doubles as a cost test.
This is the diary. It is honest about the good days and the slow one.
How do you run a local coding agent with OpenCode and Ollama?
The whole rig is small. OpenCode is the agent, running as a normal desktop app, the kind you double-click rather than launch from a shell. It is pointed at Ollama on http://localhost:11434, serving our usual coding model. That is it. No API keys, no account, nothing leaving the laptop. The Atlas note describes OpenCode as the one open-source coding agent that ships as a polished standalone application, and that is exactly why we picked it for this: we wanted the agent to disappear into the work, not become the work.
One setting in opencode.json is easy to get wrong: set small_model to the same value as model, or Ollama keeps two models in GPU memory and can return sporadic 500 errors. The fix is in our offline OpenCode setup guide.
The rule, again: local only, all week, no cloud unless we declared it.
What is a week of coding with a local agent like?
Monday: the approval rhythm
The first thing you notice is that OpenCode asks before it acts. It wants to read a file, you approve. It wants to edit, you see the change and approve. It wants to run a command, it asks. On Monday this felt slow, and we caught ourselves wishing it would just go.
By the afternoon we had changed our mind. The per-action approval is the thing that lets you trust an agent on your own machine, because you are never surprised. You watch it reason, you see the edit before it lands, you say yes. It turns the agent from something you launch and hope into something you steer. The pace it sets is deliberate, and deliberate turned out to be the right speed for code we actually have to maintain.
Tuesday: the LSP-aware edits land
Tuesday was a refactor, the kind where a function gets renamed and used in a dozen places. This is where local coding agents usually disappoint, because a weaker setup pattern-matches the name as text and misses the one call site that is spelled slightly differently or shadowed in another scope.
OpenCode did not do that. It reads symbols, definitions, and references through the Language Server Protocol, which means it understands the code as structure rather than as a wall of characters. The rename came out clean. We checked every site by hand anyway, out of habit, and it had them. This was the moment the week tipped from experiment to actually useful: the edits were grounded in what the code is, not in what it looks like.
Wednesday: the model is the ceiling
Wednesday was a reminder of the one rule that governs all of this. The agent is only ever as good as the model behind it. OpenCode can read your files perfectly, ask before every action, and apply edits surgically, and none of that helps if the model underneath does not understand the problem.
On a medium-hard task involving some tangled state, the local model started well and then talked itself into a worse design. The tooling worked perfectly. The reasoning hit its limit. We steered it back with a more specific prompt and it recovered, but the lesson was clear: the agent is the hands, the model is the head, and the head is where the ceiling lives. This is not a flaw in OpenCode. It is the honest physics of local coding, and the Atlas note says it plainly: a weak model in OpenCode is still a weak agent.
Thursday: a quiet, productive grind
Thursday was the day we forgot we were running an experiment. Bug fixes, small features, a bit of test writing. The agent read the relevant files, proposed edits, asked, applied. We approved our way through a normal productive day and nothing went to the cloud, nothing hit a meter, nothing left the room. There is no anecdote here because nothing went wrong, and that absence is the whole point. By Thursday the local agent was just how we coded.
Friday: the one task that broke the rule
Then came the task we had been quietly dreading. It was genuinely hard: a gnarly problem with a lot of moving parts and a design that needed real insight, not just correct mechanics. We gave the local model three honest attempts with good prompts. It got close and could not close.
So we broke the rule, on purpose, exactly the way the tooling invites you to. OpenCode lets you switch the model provider for a single task, so we pointed it at a frontier cloud model, solved that one problem, and switched straight back to local for everything after. This is the honest shape of local-first coding, and it matches what the note on replacing paid tools already told us: on genuinely hard problems a frontier cloud model is still ahead, and the right move is to use it for that single task rather than abandon the local setup for all of them. One task went out. The rest of the week stayed home.
Coding with local AI agent OpenCode vs a cloud agent seat: what did the week cost?
The diary gives a partial count. Over five working days, one task left the machine: the Friday problem, after three local attempts that got close and could not close. One more, on Wednesday, went wrong and recovered after a more specific prompt. Everything else that week was finished locally. We did not log a total number of tasks or the hours each one took, so we cannot put a figure on the time the slow day cost, and we are not going to estimate one.
The cloud side has published prices. 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. Over a year, one developer’s seat comes to about $228 to $360 or more (each monthly price times 12). The local agent has no seat price: OpenCode is MIT-licensed and the model runs on a machine already on the desk.
We did not log every task, the minutes each one took or which ones left the machine, so we cannot cost the week in hours against a cloud seat. That needs a repeat of the local-only week with a task log, and it is on our list.
What did a week of local-only coding teach us?
A few things settled into place by Friday.
The per-action approval is a feature, not a tax. It is slow until you realize the slowness is trust, and then you stop wanting it any faster. The LSP awareness is what separates a real coding agent from a search-and-replace bot, and it is the reason the edits held up. And the model is the ceiling, always, which means the lever that most improves your local coding is not the agent, it is the model you feed it.
Would we code this way every week. For most of the work, yes, easily, and we mostly already do. The privacy story is observable rather than promised, the bill does not grow, and the agent fits into a normal day instead of demanding a new one. We keep the cloud option in our back pocket for the one Friday problem, and we reach for it on purpose, not by reflex.
The privacy argument has a paper trail. Our piece on running AI coding agents entirely offline goes through GitHub’s March 2026 Copilot training policy and the Cloud Security Alliance finding that AI-assisted commits leak secrets at 3.2 percent against a 1.5 percent baseline.
That was the week. One agent, one local model, one deliberate trip to the cloud.
