I Ran OpenCode Instead of Claude Code for Two Weeks. It Was 78% Slower — and I Kept It Anyway.

A developer replaced Claude Code with open-source coding agent OpenCode for two weeks, finding it 78% slower but keeping it due to its model-agnostic design that unifies local and hosted AI models. The switch eliminated the mental tax of switching between tools, despite the performance trade-off.

Two weeks ago I was paying for a coding agent I had quietly stopped trusting. Not because it got worse. Because I noticed, on a slow Tuesday, that every line of my work was passing through a single company’s servers, on that company’s schedule, at that company’s price, and I had no fallback that didn’t involve a weekend of reconfiguration. I had built my whole day around one vendor’s terminal tool and called it productivity. That realization is not a dramatic story. It was closer to the feeling you get when you check your subscriptions and find three you forgot about. But it was enough to make me try OpenCode for real, instead of starring it on GitHub and moving on like I usually do. I went in expecting to confirm what most of the comparison posts already say: that the open-source agent is rougher, slower, and a downgrade you tolerate to save money. The slower part turned out to be measurably, irritatingly true. The downgrade part did not. After fourteen days I uninstalled nothing, kept OpenCode as my default, and I am still a little surprised about that. OpenCode crossed 160,000 GitHub stars in June and the project’s own marketing claims something like 7.5 million monthly developers. It hit number one on Hacker News on March 20 with over a thousand points, which in that particular crowd is the equivalent of a standing ovation. None of those numbers made me install it. Star counts tell you a tool is fashionable, not that it is useful to you specifically, and I have wasted enough evenings on fashionable tools to know the difference. What made me install it was a much smaller, pettier thing. I run a local model on my laptop every day. A 36GB MacBook Pro, Qwen 3.6 at the 27-billion-parameter size, quantized down to about seventeen gigabytes so it actually fits in unified memory with room left to compile. For most of my real work reading a file, renaming things across a module, writing the obvious test, explaining a function some past version of me wrote at midnight that local model is plenty. It costs me nothing per token and it works on a plane. The problem was that my local model and my paid agent lived in two different worlds. The polished agent assumed I wanted its hosted models. The local model sat in a separate terminal, driven by a thinner tool, with none of the project awareness I had gotten used to. So my day had a seam down the middle of it: cheap-and-local for the boring majority, expensive-and-hosted for the hard minority, and a mental tax every time I crossed from one to the other. OpenCode is model-agnostic by design. It drives, depending on how you count, somewhere north of 75 providers, from Anthropic and OpenAI and Google to anything you are running locally through Ollama, all from a single configuration file. That one sentence is the entire reason I gave it two weeks. Not the stars. The seam. The setup was less ceremonial than I expected and more fiddly than the documentation implies, which is the normal state of open-source software. OpenCode is a real agent harness, not a chat box with a code theme. It ships as a terminal user interface, a desktop application that is still labelled beta on macOS, and an editor extension. It has a tool loop, session management, and a plan-versus-build mode distinction that matters more than it sounds. And it integrates with the Language Server Protocol, the same machinery your editor uses to know that a symbol is undefined or that you just broke a type. That last part is the quiet differentiator. When the model proposes an edit, the language server’s diagnostics get fed back into the loop, so the agent sees the same red squiggles you would, instead of confidently hallucinating a method that does not exist and waiting for you to notice. Wiring it to my local Qwen took one block in a configuration file pointing at the Ollama endpoint and a model name. Wiring it to a frontier API for the hard cases took an environment variable. Within an hour I had a single harness where I could switch the underlying brain with two keystrokes and keep the same project context, the same session, the same plan I had been building. The seam I had been paying a mental tax on for months closed in an afternoon. It did not solve everything, though. The first day was slow and slightly humiliating, in the way that abandoning muscle memory always is. Here is the number nobody who loves OpenCode wants to lead with. On the same underlying model, OpenCode benchmarks around 78% slower than Claude Code. That is not a typo and it is not a worst case. It is roughly what I felt. Anthropic has spent a genuinely large amount of engineering effort on latency: on how fast the agent decides what to do next, how it batches tool calls, how little it makes you wait between the moment you hit enter and the moment something happens on screen. OpenCode’s defaults lean the other way. They favour thoroughness, more reading, more verification, more passes over the code, and you pay for that in seconds. On a tight inner loop, where you are asking for a dozen small changes in a row, those seconds stack into something you notice in your shoulders. For the first three or four days this nearly ended the experiment. I am not a patient person about tooling. When a tool makes me wait, my hand drifts to the other terminal out of habit, and a couple of times I caught myself halfway back to the old agent before I remembered I was supposed to be testing this thing. What changed was not that OpenCode got faster. It is open source; it did not magically optimize itself over a weekend. What changed was that I stopped measuring it against the wrong baseline. The honest comparison is not OpenCode-on-a-frontier-model versus Claude-Code-on-a-frontier-model, where Claude Code wins on speed and it is not close. The honest comparison, for the bulk of my day, is OpenCode-driving-my-free-local-Qwen versus paying per token for a hosted model to do work a 27B model handles fine. Against that baseline, a few extra seconds is a price I will pay every single time, because the alternative is a meter running in the background. Cost is the obvious part, so let me get it out of the way and then talk about the part that surprised me. My API spend was already down by more than half before any of this, because the local model was carrying the steady majority of the load. With OpenCode it dropped further, not to zero I will get to why not but to a number I no longer think about. For a working engineer who codes most days, “I stopped thinking about the meter” is worth more than most feature comparisons admit. The part I did not expect to care about was the absence of lock-in, and how much it changed the way I work rather than just what I pay. When the underlying model is a configuration line instead of the entire foundation of your tool, you experiment differently. A new model dropped mid-experiment, and trying it was a one-line change rather than a migration. I ran the same refactoring task through my local Qwen, then through a hosted model, then through a different hosted model, and compared the diffs side by side in the same session. I have never bothered to do that before because the friction was too high. The model stopped being a destiny I committed to and became a variable I could turn. There is a subtler thing too, harder to put a number on. Because OpenCode is verbose and a little slow, it shows you more of its reasoning before it acts. Claude Code, in optimizing for speed, often just does the thing, and most of the time the thing is right and I am grateful. But OpenCode’s slower, more legible loop meant I caught two bad plans before they touched a file. Once because it was about to edit the wrong module, once because its plan quietly assumed a library version I had upgraded away from. The friction that annoyed me on the inner loop turned into a guardrail on the risky changes. I am not sure that trade is universal. It is real for the way I work. I can point to the moment the experiment stopped being an experiment. It was day nine, an unglamorous maintenance task: migrating a service off a deprecated client library to its replacement, the kind of work that is too mechanical to be interesting and too scattered to be quick. Forty-odd call sites across a dozen files, each with slightly different argument shapes, the sort of change where the danger is not difficulty but volume. Miss one, and it compiles fine and then pages you at the worst possible time three days later. I gave it to OpenCode running my local Qwen, in plan mode first. It read the codebase, found the call sites the language server knew about, and laid out a plan before touching anything. The plan was wrong in one specific way: it had grouped two call sites together that looked identical but were not, because one of them passed a value that the new library handles differently. I caught it in the plan, said no, told it the distinction, and let it proceed. It did the rest in one pass, and the language server diagnostics it folded back in caught two type mismatches it had introduced and corrected them before I ever saw red in my editor. The whole thing took maybe twenty minutes longer than the polished agent would have taken. It also cost me nothing, ran on a model sitting in my own memory, and surfaced a mistake I would have had to find in review anyway. Twenty minutes against a class of bug that eats an afternoon when it escapes is not a trade I have to think about. That was the moment the slowness stopped feeling like a tax and started feeling like the price of seeing the work. The next morning I deleted the alias I had kept pointing at my old setup, the little escape hatch I had left myself in case the whole thing fell apart. That deletion was the real verdict, more honest than anything I could write here. I would not trust this article if it ended there, and you should not either. Claude Code is faster, and on a long agentic task, the kind where you hand it a vague goal and let it churn through twenty steps, the speed compounds into a genuinely better experience. It feels designed. The rough edges have been sanded in a way that only a funded team doing nothing else can manage. When I hit a hard debugging problem, the kind where the bug is three layers down and the fix is non-obvious, I still escalate to a paid frontier model, and I often still reach for the polished agent to drive it, because in those moments I want every second of latency shaved and every bit of reasoning quality I can buy. The local 27B model is good. It is not good enough for the worst hour of my month, and pretending otherwise would be a lie that some reader would discover at exactly the wrong time. OpenCode’s desktop application is beta and feels it. The terminal interface is where the project is strongest and where I live, but if you want a polished graphical experience you will notice the seams. And the broader open-source reality applies: the documentation lags the code, some providers integrate more smoothly than others, and you are occasionally the person filing the bug rather than the person whose bug was fixed three releases ago. None of that is damning. All of it is the texture of running software that a community maintains instead of a vendor sells you. There is also a failure mode I want to name because it bit me. Model-agnostic means model-responsible. When you can point the agent at anything, you can point it at the wrong thing: a local model that is too small for the task, quietly producing plausible nonsense while you assume the harness would have stopped it. The harness does not save you from your own model choice. That judgment is now yours, every time, and on a busy day that is one more decision you have to keep making. The framing of “OpenCode versus Claude Code” is the wrong frame, and I fell for it for the first three days before the experiment taught me otherwise. I did not replace one agent with another. I replaced a rigid arrangement one tool, one vendor, one pricing model, one model quality, take it or leave it with a flexible one. Most of my week now runs through OpenCode driving a free model on my own laptop, slower than I would ideally like, costing nothing, showing me its work. A meaningful minority of my week, the hard and expensive minority, runs through a frontier API, and when latency really matters I am still happy to pay for the polished experience. The thing OpenCode actually gave me was not a better agent. It was the ability to stop choosing once and for all. If you are a hobbyist or you only code occasionally, the honest answer is that the polished paid agent is probably the better default. The speed is real, the experience is smoother, and the cost of a few hours a week is not worth optimizing. The calculus changes when you code most days, when the per-token meter starts to feel like a faucet you forgot to turn off, and when you have hardware sitting idle that could carry the boring majority of your work for free. That is a narrower audience than the star count suggests. It just happens to be the audience I am in. Two weeks later, what stays with me is how quickly the thing I dreaded, the slowness, stopped registering, and how the thing I did not think to want, not being owned by a single tool, became the part I would actually fight to keep. I do not think that is a universal lesson. I think it is what happens when you stop benchmarking a tool against a spec sheet and start benchmarking it against your own week. I Ran OpenCode Instead of Claude Code for Two Weeks. It Was 78% Slower — and I Kept It Anyway. https://pub.towardsai.net/i-ran-opencode-instead-of-claude-code-for-two-weeks-it-was-78-slower-and-i-kept-it-anyway-9a84102cc982 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.