OpenCode: The Free, Open-Source Alternative to Claude Code That You Actually Control

Claude Code has had a good year. By any honest measure it is the most capable AI coding assistant most developers have used in 2026 — fast, fluent with the modern stack, and good enough at the long tail of "edit this, run that, fix the error" that it has changed the shape of an afternoon for a lot of people I know. It also costs money. The first subscription tier is reasonable; the second is not, and the people who hit the second tier are the same people who would not be able to justify it on a personal budget. That gap — between "this is genuinely useful" and "this is genuinely useful AND I can afford to actually use it" — is where OpenCode lives.

OpenCode is the open-source answer to Claude Code, in roughly the way that VS Code is the open-source answer to Visual Studio. It is not a clone. It is not a thin wrapper around a different paid model. It is a full AI-assisted coding tool — terminal-first, with an optional desktop client — that runs against any LLM you point it at, including the free ones. In the last few weeks I have used it to build a small ASP.NET Core blog from a single sentence prompt, and the thing that surprised me was not the output. It was the bill at the end of the month. There wasn't one.

This post is a hands-on look at OpenCode: what it does, what it does not, how it feels to actually use, and the small set of configuration changes that turn it from "interesting" into "I am cancelling my subscription."

Cover image: OpenCode, the open-source Claude Code — Fig. 01 — A working schematic of OpenCode: terminal-first, model-agnostic, and free if you want it to be.

The Two Modes

OpenCode ships in two flavors and you pick the one that fits how you work. Both are the same product; the difference is the surface.

The CLI mode is the original. You install it, you cd into a project, you type opencode, and you are in an agent loop in your terminal. If you are a Claude Code user, this is the mode that will feel familiar on day one. The keyboard shortcuts are similar, the tool list is similar, the way the agent reasons out loud before it acts is similar. I have spent most of my time in this mode, and so far the experience has been "Claude Code, but in a window I do not have to pay to keep open."

The IDE mode is the same agent, same loop, same model, but inside a desktop window. It feels closer to Cursor than to Claude Code. The right pane is a chat; the left pane is the file tree; the bottom is the terminal output of whatever the agent is doing. It is the mode I would recommend to someone who has never used a terminal agent before, because the affordances are visible and the escape hatches are obvious. The CLI mode is faster once you know the shortcuts. The IDE mode is faster to learn.

OpenCode CLI running inside VS Code — Fig. 02 — The CLI mode inside VS Code. The terminal on the right is OpenCode; the rest of the editor is the project you are working on.

Both modes talk to the same backend. Both modes support the same providers. Both modes can be paused, scoped, and resumed. The choice between them is purely about which surface you would rather look at for an hour.

Vibe Coding an ASP.NET Core Blog

The first thing I wanted to know was whether the loop actually worked. The "vibe coding" pitch — describe the thing you want, watch the model build it, fix the things it gets wrong — is the most contentious claim in the AI-coding discourse right now, and the only way to evaluate it is to do it.

I asked OpenCode, in a single sentence, to build a small blog website with ASP.NET Core. The agent produced a todo list, asked me a clarifying question about authentication, and went to work. The first pass generated the project, the controllers, the views, the database context, and the migrations. It did not, however, run the migrations. When I hit run, the site came up but every request that touched the database threw the canonical beginner error:

SqliteException: SQLite Error 1: 'no such table: Blogs'.

This is, in fairness, the exact error every ASP.NET Core developer gets the first time they forget to run dotnet ef database update. The agent had created the migration files. It had not run them. I told it to fix the error. It ran the migration, restarted the server, and the site worked.

The 'no such table Blogs' error in the terminal after the first vibe-coding pass — Fig. 03 — The first run failed with the standard SQLite error. The fix was a one-line instruction to the agent.

The ASP.NET Core blog site running in a browser, after the migration fix — Fig. 04 — Two prompts later, the blog is live. No code was written by hand.

This is a trivial example, and I am not going to pretend otherwise. A 5-file blog is not a production system. But the shape of the loop — agent proposes, human verifies, agent fixes, human verifies again — is the same loop I would use on a real codebase. And the part that matters is that the agent got the project to a runnable state on its own, recovered from a real error on its own, and did not require me to open a single file in between. The remaining work, the kind of work that takes weeks in a real codebase, is the work of refining the design and the data model. The work of "make it run" is increasingly a solved problem.

The Cost Story

The reason I am writing this post is not the agent loop. The agent loop is good in the same way that Claude Code's agent loop is good — same ideas, similar implementation, comparable quality on comparable models. The reason I am writing this post is the cost.

OpenCode ships with a catalog of free models out of the box. You install the tool, you open a project, you pick a model, and you start coding. There is no subscription tier, no per-seat license, no metered overage that appears on your credit card at the end of the month. The free models are not the frontier models — the free tier of OpenCode is closer in quality to Sonnet 3.5 than to Sonnet 4.5 — but for the bulk of everyday coding work, "Sonnet 3.5 in my terminal, free, forever" is a much better deal than "Sonnet 4.5 in my terminal, $20/month for the first tier and $200/month if I actually use it."

The other thing I did not realize I wanted until I had it is per-session token visibility. OpenCode tells you, on every turn, how many tokens the last call used, how many the session has used in total, and roughly what that is going to cost if you are on a paid provider. The CLI mode shows it inline:

Token usage displayed at the bottom of each turn in CLI mode — Fig. 05 — Token usage after each turn in the CLI. The number is honest. The number is local.

The IDE mode shows the same number in a sidebar. Both modes are honest about the cost of what you are doing, which is the kind of feature you do not appreciate until you have hit a surprise bill from a tool that was not.

Token usage shown in the IDE sidebar after a turn — Fig. 06 — The same number, in the IDE sidebar.

The number is the answer to the question I now ask first whenever I open a new tool: "what does it cost to use this honestly for an hour?" The answer for OpenCode, with a free model, is zero. The answer for OpenCode with a paid model is whatever the model costs, with no markup, with no per-seat license, with no subscription gate. The answer for Claude Code is "the subscription, or the metered overage, or both."

Custom Providers: The Killer Feature

The free models are the reason you install OpenCode. The custom-provider support is the reason you keep it.

OpenCode supports a long list of AI providers out of the box — the usual frontier labs, the usual aggregators, the usual self-hostable endpoints. If the provider you want is on the list, you add an API key, you pick a model, you are done. If the provider you want is not on the list — and if you are in 2026, the provider you want is almost certainly not on the list, because the list of "providers I want to try" is growing faster than any client can keep up with — you add it yourself.

The configuration lives in opencode.json, which is loaded in a defined order:

Remote config (from .well-known/opencode) — organizational defaults
Global config (~/.config/opencode/opencode.json) — user preferences
Custom config (OPENCODE_CONFIG env var) — custom overrides
Project config (opencode.json in project) — project-specific settings
.opencode directories — agents, commands, plugins
Inline config (OPENCODE_CONFIG_CONTENT env var) — runtime overrides

The order is what makes this useful. The project config can override the user config, which can override the organizational default. A team can ship a base configuration that locks down providers and models, and a developer can layer their own preferences on top without touching the file the team committed.

To add a new provider, you drop a small JSON block into your opencode.json. For example, to wire up the ChatFire API as a custom provider:

{
    "$schema": "https://opencode.ai/config.json",
    "provider": {
        "chatfire": {
            "npm": "@ai-sdk/openai-compatible",
            "name": "ChatFire API",
            "options": {
                "baseURL": "https://api.chatfire.cn/v1"
            },
            "models": {
                "gemini-3-flash-preview-thinking": {
                    "name": "gemini-3-flash-preview-thinking"
                },
                "gpt-4o-mini": {
                    "name": "gpt-4o-mini"
                }
            }
        }
    }
}

Then you add the API key to ~/.local/share/opencode/auth.json:

{
  "chatfire": {
    "type": "api",
    "key": "your api key"
  }
}

That is the entire setup. No SDK to install. No plugin to download. No provider approval queue to wait in. The next time you open OpenCode, the new provider is in the model picker:

The new chatfire provider appears in the IDE model picker — Fig. 07 — The custom provider, in the IDE model picker, right next to the built-in ones.

The CLI mode picks it up the same way:

The new chatfire provider appears in the CLI model picker — Fig. 08 — Same provider, CLI mode. No extra setup.

And the new models are immediately usable in both modes:

Using a custom model in the IDE — Fig. 09 — A custom model being used in the IDE. The "model" line at the bottom shows it is the new one.

Using a custom model in the CLI — Fig. 10 — Same model, CLI mode.

This is the part I want to underline. Claude Code supports a fixed set of providers. You pay for the providers you want to use, on the plan that lets you use them. If a new provider ships tomorrow, you wait until the client is updated, and you use it through whatever pricing structure the client decides to apply. OpenCode's answer is: the config file is the contract. The provider list is whatever you put in the config file. If a new provider ships tomorrow, you add four lines of JSON and you are using it. The economics of "trying a new model" go from "subscribe to a new service, see if it is good, cancel if it is not" to "edit a JSON file, see if it is good, delete the JSON file if it is not."

The Shape of What Comes Next

The interesting thing about OpenCode is not that it exists. Open-source AI coding tools have existed for as long as the closed ones. The interesting thing is the position. OpenCode sits at the intersection of three trends that are all accelerating in 2026: open-source models getting good enough for everyday work, the protocol layer (MCP, function-calling) stabilizing around a few standards, and the price of inference falling faster than the price of subscriptions is rising. Each of these trends, on its own, is a tailwind for an open-source coding tool. Together, they are something close to a structural shift.

The closed tools are not going to disappear. Claude Code, Cursor, Copilot, the rest — they are going to keep shipping features, they are going to keep setting the ceiling on what the loop can do, and they are going to be the right answer for a lot of teams. But the floor — "what is the cheapest, most flexible, most under-your-control way to do AI-assisted coding today" — has moved, and OpenCode is on the floor. For solo developers, for small teams, for the long tail of "I would use this more if it were cheaper," that is the right place to be.

A small toolkit to get started, if you have not already:

Install OpenCode from the official site for your platform.
Open a project. Pick a free model from the picker. Run a one-line task — "add a /healthz endpoint" is a good first one — and watch the loop.
Wire up the provider you actually use. If it is on the list, add the API key. If it is not, add four lines of JSON.
Decide for yourself whether the closed tools are still worth the subscription. For me, the answer has been "no, not for the everyday work."

OpenCode is open source, it works with the models you want, it does not require a subscription, and it runs in the same editor you are already using. If Claude Code is starting to feel expensive, or if you just want to see what an open-source agent loop looks like in 2026, this is the one to try.