UFO

OpenCode vs Claude Code

Short answer: if you want to own the whole stack and change models whenever you like, OpenCode; if you want the deeper extension machinery and don't mind buying from one vendor, Claude Code. Neither is the better tool. They are built on different bets about who should hold the pieces.

The differentiator most comparisons miss isn't a feature. OpenCode is client/server by construction — the agent runs as an HTTP server and the terminal is only one of the things that can talk to it. Claude Code is a single local process that reaches your other devices through a service Anthropic runs. Almost everything else on this page follows from that.

Written 2026-07-31 · OpenCode v1.18.10, released 2026-07-30 · Claude Code v2.1.220 · Star counts, versions and licences read from GitHub and the npm registry that day, and all three move weekly

On this page

  1. Check which repo you're looking at
  2. Client/server versus one process
  3. Driving it from another device
  4. Who you're buying from
  5. What you can bolt on, and what bites
  6. How to pick

Check which repo you're looking at

OpenCode used to live at sst/opencode. It is now anomalyco/opencode, and the docs footer credits © Anomaly. GitHub still resolves the old path — the API answers 301 Moved Permanently and the web URL lands you on the new org — so the move is easy to miss entirely, which is exactly why a lot of writing about OpenCode still describes it by its old lineage.

Everything downstream has moved with it — the Homebrew tap is anomalyco/tap/opencode, the container image is ghcr.io/anomalyco/opencode — so an sst-flavoured install command that isn't a plain redirect predates the change. As of 2026-07-31 the repo shows 191,303 stars, an MIT licence, 4,815 open issues, and a latest release of v1.18.10 published 2026-07-30. Releases land most days; treat any version number you read, including that one, as a snapshot.

Client/server versus one process

OpenCode's own description of its architecture:

When you run opencode it starts a TUI and a server. Where the TUI is the client that talks to the server. The server exposes an OpenAPI 3.1 spec endpoint.

The consequences arrive without being asked for. opencode serve runs it headless — default hostname 127.0.0.1, default port 4096 — behind a documented HTTP API. opencode web serves a browser interface onto the same server. opencode attach http://localhost:4096 hangs a terminal TUI off a server already running, "sharing the same sessions and state." Interface and execution are separable because they were never joined.

Claude Code is one process. You run claude in a project directory, or drive it from the VS Code extension, and the session lives in that process for as long as it lives. Simpler to reason about, and the reason the remote story looks so different. Neither shape is inherently better: a server you can point clients at is leverage if you intend to build something, and an extra moving part if you don't.

Driving it from another device

This is where the architecture cashes out, and both answers come with a bill attached.

OpenCode hands you the architecture and leaves you the networking. Bind to a real interface — opencode web --hostname 0.0.0.0 — and it prints a local URL and a network URL; add --mdns and it advertises itself on the LAN as opencode.local. From a phone on the same Wi-Fi that is genuinely all of it. What the docs describe is local-network reachability, though, not internet exposure: reaching it from a train is a VPN or tunnel you set up and maintain.

The sharp edge: authentication is opt-in. The docs are blunt about it — "If OPENCODE_SERVER_PASSWORD is not set, the server will be unsecured. This is fine for local use but should be set for network access." An agent with filesystem and shell access, bound to 0.0.0.0 with no password, is reachable by everything else on that network. Set the variable in the same command you change the hostname in, not later.

Claude Code hands you the networking and leaves you the vendor. Remote Control is free with the subscription and does the hard parts: your machine makes outbound HTTPS requests only and never opens an inbound port, traffic routes through the Anthropic API, and you connect from claude.ai/code or the iOS and Android app — including by scanning a QR code the terminal prints. It is documented as a research preview, and is off by default on Team and Enterprise until an Owner enables it. Setup is covered in the Claude Code remote guide.

The stated limits are specific enough to plan around. The local process has to keep running, so on a remote box you want tmux or screen. If your machine is awake but offline for more than roughly ten minutes, the session times out and the process exits. And while a session is connected, the transcript is stored on Anthropic servers to keep devices in sync.

Worth checking before you plan around it: Remote Control requires a claude.ai login and talking directly to api.anthropic.com. API-key authentication isn't supported, and it is disabled on Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry, or whenever ANTHROPIC_BASE_URL points at a gateway or proxy. Organisations on Zero Data Retention can't enable it at all. That rules out a good share of exactly the enterprise setups most interested in remote access — and it is the case where OpenCode's self-hosted server has no equivalent objection to answer.

Who you're buying from

Facts as of 2026-07-31. This is a table of what each thing is, not a scorecard.

OpenCodeClaude Code
Repoanomalyco/opencodeNot public
LicenceMITProprietary (npm reports "SEE LICENSE IN README.md")
Versionv1.18.10 (2026-07-30)v2.1.220
Models"75+ LLM providers" via the AI SDK and Models.dev, plus local runtimesAnthropic models
How you payYour own provider keysBundled with a Claude plan, or an Anthropic API key
Runs whereYour machine, as a server you can addressYour machine, as a process

Local models are documented rather than tolerated: Ollama, LM Studio and llama.cpp are configured as custom OpenAI-compatible providers pointing at a localhost endpoint. If inference must never leave your building, that is a real answer, and Claude Code doesn't attempt to be one.

But "switch models freely" has a boundary that OpenCode's own documentation states plainly, and it's the one people trip over:

There are plugins that allow you to use your Claude Pro/Max models with OpenCode. Anthropic explicitly prohibits this. Previous versions of OpenCode came bundled with these plugins but that is no longer the case as of 1.3.0

So the subscription you already have does not travel. In OpenCode you pay per token to whoever you point it at — the docs do list ChatGPT Plus, GitHub Copilot and GitLab Duo as subscriptions that work with no setup, so this isn't absolute, but Anthropic's isn't among them. Read the other way round: if you already pay for Claude, Claude Code is not an additional line item, which is the strongest commercial argument on its side.

What you can bolt on, and what bites

Both are extensible and the shapes differ more than the ambitions do. OpenCode loads plugins as JavaScript or TypeScript files from .opencode/plugins/ or as npm packages named in opencode.json, installed with Bun at startup; alongside those it documents agents, skills, commands, permissions, MCP servers and ACP.

Claude Code's surface is more specified. It publishes roughly thirty named hook events — SessionStart, PreToolUse, PermissionRequest, SubagentStop, PreCompact and the rest — and an explicit contract for refusing work: a PreToolUse hook can exit 2, or return JSON with permissionDecision: "deny", and the tool call does not run. That is a policy gate executing outside the model's judgement rather than a prompt asking it to behave, and it has one edge that quietly defeats most first attempts; the subagent system is the other half of that machinery. If you are writing rules that must hold, a published contract and an open-ended event API are not the same purchase.

The concrete limitation on the OpenCode side is language-server feedback, because it is usually assumed to be on. LSP is disabled by default, and when enabled it starts servers on file open rather than running a diagnostics loop after every edit. The docs recommend against it as often as for it:

Language servers can get out of sync, use significant memory, vary by version or project, and slow down agent workflows. In many projects it is better to have the agent run lint, typecheck, or other diagnostic CLI tools directly, so errors are fed back into the agent loop without those tradeoffs.

That is honest advice rather than a defect, but it means "OpenCode has LSP-fed diagnostics" describes something you opt into and tune, not a property of the box. Set "lsp": true, or document your lint and typecheck commands in AGENTS.md and skip it.

How to pick

Short version, by the thing that actually decides it:

Running both is cheap, since they are separate binaries editing the same files through the same filesystem. The reason to actually choose is usually procurement or policy, not capability.

Where we fit, briefly

We build UFO, so weigh this accordingly — and the answer to this page's question is not us. If you want a coding agent in a terminal, both options above are good ones and you should pick between them on the grounds listed here.

UFO is the layer after: a team chat where AI agents are members of channels alongside people, each running on a machine you've paired, with task cards for work that outlives a session. OpenCode and Claude Code are both things you can run inside that.

It starts mattering when there are several agents, on several models, and other people need to see what they did.

Sources

Versions, star counts, licences and quoted documentation read on 2026-07-31. Quotations are verbatim from the pages linked below. Both projects ship frequently; verify anything you plan to depend on.

Not affiliated with Anomaly or Anthropic. If something here is wrong or has gone stale, tell us and we'll fix it.