Why I Use OpenCode as My AI Harness

I keep hearing questions about why we use OpenCode. My reaction is usually not very diplomatic. I am less puzzled by OpenCode than by how casually people install proprietary AI clients and move on.

That feels upside down.

AI already comes with enough risk. I do not see why I should also hand my local context, prompts, agent setup, and working habits to the same vendors that operate the models. If a provider gets my request, that is already the deal. It does not follow that the same provider should own the harness around it.

That distinction matters.

The harness is the part I want to own

Models run somewhere else. I do not control that. They are remote services.

What I can control is the layer that decides what gets sent there, how it gets sent, which permissions exist, which agents are available, and what my workflow looks like. That is the harness.

For me, OpenCode is that harness.

This is where privacy, sovereignty, and provider independence stop being slogans and become engineering decisions.

If I rely on one provider's client, I also rely on that provider's workflow, product decisions, outages, terms, and legal exposure. That is too much coupling for my taste.

I prefer a setup where the external part is reduced to the model call. Everything else should be mine.

Provider dependence is a bad hobby

Providers have outages. They change terms. They change prices. Features disappear. Regions become awkward. Legislation interferes.

That is not exotic risk. That is platform risk.

I do not want my workflow to collapse because one company had a bad day.

So I separate the replaceable part from the durable part.

The replaceable part is the model.

The durable part is my harness, my configuration, my agents, my skills, my permissions, and the context I built over time.

That split is the whole game.

Proprietary workflows are not neutral

This is the part I dislike even more. Proprietary clients do not just give access. They shape behavior.

They decide what matters in the interface. They decide how context works. They decide which settings exist. They decide when your workflow changes because their product team had a new idea.

I am sure this is wonderful for somebody. Usually not for me.

I would rather do the extra setup once and define the harness myself. Then the tool does what I want, not what somebody else wants me to want.

That is more work up front. Fine. I have used computers long enough to know that one careful setup beats endless adaptation later.

Configure once, reuse everywhere

This is where OpenCode stops being just a terminal tool.

With the PAI framework (or PAI for OpenCode), I configure providers, models, agents, permissions, skills, plugins, and the rest once. One setup. One place. One source of truth.

Then I use OpenCode in the terminal and get on with work.

If I want a richer interface, I use CodeNomad. It still uses OpenCode underneath. Different UI. Same context. Same subscriptions. Same preferences. Same configuration.

That is the part I like most. The visible tool can change. The actual setup stays put.

The same setup works in my IDE

Recently I wanted an AI agent inside IntelliJ IDEA. The same applies to PhpStorm.

With ACP, the agentic context protocol, I can point the IDE to my OpenCode installation and reuse what already exists. No second setup. No separate agent zoo. No parallel universe of settings that starts drifting on day two.

That matters because drift is where good intentions go to die.

I can occasionally use AI inside the IDE, and it still behaves like my setup, not like some random assistant behind another button.

And now in Zed too

JetBrains IDEs are good tools. They can also be a bit annoying when I switch projects a lot. So I tried Zed after hearing more and more good things about it.

That turned out to be exciting.

Not as a replacement for JetBrains. I am not starting a religion here. But for many daily tasks, it is a very good fit.

And again, through ACP, Zed reuses the same OpenCode setup. Same harness. Same context. Same agents.

At that point it stops looking like a single application and starts looking like infrastructure.

Buzz is the same story at team scale

My latest example is Buzz.

Think of it as a private, self-hosted chat space where a team can work with agents together. What matters is not the chat UI. What matters is that the agents inside Buzz can use the OpenCode agents that already exist across desktops, laptops, and servers.

Again, proven context. Existing setup. No fresh round of configuration.

One setup, many interfaces

Here is the practical effect:

• OpenCode terminal
• CodeNomad
• IntelliJ IDEA or PhpStorm through ACP
• Zed through ACP
• Buzz

All of them sit on top of the same setup.

The serious work happens once. Tailoring, tweaking, permissions, provider setup, and agent design live in one place. Improvements happen there once as well.

Nothing needs manual syncing because nothing is a copy. Every interface uses the same source.

Models are external commodities

This is the strategic point.

The agents are mine. The harness is mine. The workflow is mine.

The models are external.

Useful, expensive, sometimes impressive, sometimes annoying, and replaceable.

If Anthropic has another outage, I want to switch. If OpenAI fits better for one task, I want to switch. If OpenRouter, Z.ai, or something else is the right choice tomorrow, I want to switch.

Not after a migration project. Immediately.

That only works when the model is treated as a commodity and the harness stays stable.

Open source is what makes this possible

This level of independence only works when the harness itself is open source.

Otherwise I still depend on somebody else's client logic, release cycle, and product boundaries. I might gain one convenience feature and lose control where it counts.

That trade does not interest me.

If there is another tool tomorrow, next week, or next year, I want to connect it to the same harness. Maybe another editor. Maybe another team tool. Maybe Drupal sites that should use the setup I already have.

Why would I rebuild that from scratch each time?

I want the boring part to be stable, local, reusable, and mine. Then I can switch models whenever I like.