Explainer

What is OpenCode?

OpenCode is an open-source, terminal-native AI coding agent: you point it at a repo, describe a task in plain English, and it reads files, runs commands, edits code, and reports back — the same loop as Claude Code or Codex CLI, but built in the open and deliberately model-agnostic. It is MIT-licensed, maintained by Anomaly (the team formerly known as SST), and at the time of writing sits somewhere around 172K-178K GitHub stars, which makes it the most-starred open-source coding agent.

If you already know what a terminal coding agent does, the interesting part of "what is OpenCode" is not the loop — it's the two design choices that set it apart: a client-server architecture, and a provider-agnostic core. The rest of this post walks through both, plus where Grindy, our hosted engine, fits.

What it is

OpenCode runs locally on your machine as a CLI agent built for the terminal. Give it a task and it follows the now-familiar agent loop: gather context, propose a change, run something, check the result. It ships with Language Server Protocol (LSP) integration, so it loads the right language server for your project, and it supports multiple sessions running in parallel on the same repo.

A quick note on naming, because it confuses people. After a 2025 split, the original Go codebase was archived and continues today as a separate project called Crush, while the SST/Anomaly team kept the OpenCode name and rebuilt it in TypeScript. So "OpenCode" today means the Anomaly/TypeScript project at anomalyco/opencode, not the older Go one. If you're weighing it against the incumbent, we cover the head-to-head in OpenCode vs Claude Code, and it lands on most shortlists of Claude Code alternatives.

Client-server

This is the architectural decision that defines OpenCode. Instead of being one monolithic terminal program, OpenCode runs a client-server architecture. A backend server handles model communication, tool execution, and session storage (in a local SQLite database). A separate frontend client is just one way to talk to that server.

The payoff is that the agent is decoupled from the UI you happen to be looking at. The server can keep running while different clients — a terminal TUI, a desktop app, an IDE extension — attach to it. The agent's work isn't hostage to a single window. This is the same principle behind why a serious background workflow keeps the process that runs the agent separate from the process you click on; we get into that split in running an agent in the background.

Providers

The second defining choice: OpenCode is model-agnostic. It connects to 75+ LLM providers — Anthropic, OpenAI, Google, AWS Bedrock, Azure, Groq, OpenRouter, and local models via Ollama, among others. You decide which model processes your code, and you can swap providers between sessions instead of being locked to one vendor.

Authentication runs through OpenCode's own auth / connect flow. For Anthropic, for instance, you select the provider and can either drop in an API key or run an OAuth login. The OAuth path opens your browser, authenticates, and stores tokens locally that auto-refresh — more on the catch with that below. Because the software is MIT-licensed and free, the only thing you pay for is the model: connect a frontier API and you pay per token; connect a local Llama via Ollama and the per-token cost is zero. If you're picking a model to plug in, our best AI coding agent in 2026 rundown compares the options OpenCode can drive.

Surfaces

Because the agent lives in a server, OpenCode exposes several front ends:

• TUI — the original terminal interface, and still the primary one.
• Desktop app — a beta desktop client for macOS, Windows, and Linux.
• IDE extension — so the same agent and sessions live next to your editor.

All three are clients of the same backend, which means a session you start in one surface is the same session the server holds — not a fresh, isolated chat. That continuity is the practical upside of the client-server split, and it is what makes parallel sessions and share links work cleanly. If you like the idea of a non-terminal surface for your agent in general, that instinct is the same one behind a GUI for Claude Code.

The OAuth block

One honest caveat worth flagging, because it trips people up. You can authenticate OpenCode's Anthropic provider with an OAuth login tied to a Claude Pro or Max subscription, and community plugins exist to bridge those credentials. But Anthropic's terms state that Claude Pro/Max subscription tokens are meant for official Anthropic clients — so using a subscription login to power a third-party agent like OpenCode is a gray area that can stop working if Anthropic changes its OAuth infrastructure. The clean, unambiguous path is a provider API key (pay-per-token) or a local model. If you want subscription-grade Claude access without the gray area, that's part of why a hosted engine like Grindy exists.

OpenCode and Grindy

Here's where we're direct about our own stake. Grindy — Backgrind's managed, zero-setup engine — is built on OpenCode. We didn't reinvent the agent loop; we run the open-source one and wire it to our own proxy. The user picks the grindy model, and behind the scenes the engine reaches Claude via OpenRouter (one OpenAI-compatible endpoint): grindy-1 maps to Claude Haiku 4.5, and grindy-1-pro maps to Claude Sonnet 4.6. You get a real Claude engine with nothing to install and no provider key to manage — the OAuth gray area above simply doesn't apply, because you're not bringing your own subscription.

Two things are deliberately not hidden and worth stating plainly. First, Grindy is a rebranded fork: the wordmark, CLI banner, and strings all say "Grindy," and a brand firewall on our proxy strips upstream-identifying metadata — model ids, fingerprints, service-tier fields — so Claude, Anthropic, and OpenRouter fingerprints can't leak through. That's a product decision, not a secret we're keeping from you here. Second, Grindy is the managed option, not the only option: if you'd rather run OpenCode yourself with your own keys, nothing about Backgrind stops you. Grindy just removes the setup for people who don't want to deal with providers at all.

Run in an overlay

OpenCode's client-server design is a natural fit for an overlay. Because the agent runs in a server that any client can attach to, you can put a thin, always-on-top window in front of it and keep the heavy process running underneath. That's exactly the shape Backgrind is built around: an AI coding agent overlay that floats over whatever you're doing and pings you only when the agent needs a decision or finishes — so "run an agent in the background" stops meaning "run it blind." Whether you drive OpenCode, Claude Code, Codex, or Grindy, the overlay treats it the same: a real CLI underneath, a calm surface on top.

Frequently asked questions

Where Backgrind fits

Backgrind is not an agent or a model — it's the overlay and notification layer that sits in front of the agent you already run. With OpenCode specifically, the client-server design makes that easy: the agent lives in a server, and Backgrind is just another calm, always-on-top client over your real CLI, pinging you on the events that matter and fading out otherwise. If you'd rather skip the provider setup entirely, Grindy gives you a hosted OpenCode plus a Claude engine with nothing to configure. Either way, you keep your own login and history, and you can feel the notification loop in the live demo.