opencode: the open-source coding agent split into client and server

What it is

opencode is an open source AI coding agent. The repository is anomalyco/opencode (formerly sst/opencode; the old path 301s to the new org while the GitHub repository id 975734319 stays the same), with 210,595 stars and 27,875 forks, written in TypeScript under MIT, created 2025-04-30, last push 2026-09-28, homepage opencode.ai. The project describes itself in one line: The open source AI coding agent. It ships three front ends - a terminal TUI, a desktop app, and an IDE extension - but the front ends are not the point. The point is that all three talk to the same HTTP server: when you run opencode it starts a server plus a TUI client, and the TUI is merely the first consumer of that server.

This entry also anchors the open source coding-agent layer on this site. XiaomiMiMo/MiMo-Code, already in the AI Coding ladder, states in its own README that it is a fork of OpenCode: it keeps the multi-provider core, the TUI, LSP, MCP and the plugin system, then adds persistent memory, context management, sub-agent orchestration and self-improvement loops on top. Reading opencode therefore gives you the baseline against which every downstream fork should be judged.

Fact sheet

Field	Value
Repository	anomalyco/opencode (formerly sst/opencode)
Stars / forks	210,595 / 27,875
Language / licence	TypeScript / MIT
Created / last push	2025-04-30 / 2026-09-28
Surfaces	Terminal TUI, desktop app, IDE extension, headless server, GitHub Action, ACP subprocess
Model supply	75+ providers via AI SDK and Models.dev, local models, plus the curated OpenCode Zen gateway
Built-in agents	2 primary (Build, Plan) + 3 subagents (General, Explore, Scout) + 3 hidden system agents (compaction, title, summary)
Built-in LSP	35+ language servers, launched by file extension
Install	curl -fsSL https://opencode.ai/install | bash, npm/bun/pnpm/yarn global opencode-ai, brew install anomalyco/tap/opencode, pacman, choco, scoop, mise

The real bet: client and server separation, not a prettier TUI

opencode serve runs a headless HTTP server exposing an OpenAPI 3.1 spec (default http://127.0.0.1:4096/doc). The types in the JS/TS SDK @opencode-ai/sdk are generated from that spec rather than hand-written. The consequences are larger than they look:

• One agent core, five kinds of client: terminal, desktop, IDE, CI scripts and SDK integrations all hit the same endpoints. Nobody re-implements the agent loop per host.
• The /tui endpoint drives the TUI remotely: you can prefill or run a prompt over HTTP. That is exactly how the official IDE plugins work - the IDE is not another agent, it is a remote control for the same server.
• The server is discoverable, protectable and cross-origin aware: --mdns enables mDNS discovery (default domain opencode.local), OPENCODE_SERVER_PASSWORD turns on HTTP basic auth (username defaults to opencode, override with OPENCODE_SERVER_USERNAME), and --cors can be passed repeatedly.
• Events arrive as an SSE stream: /global/event for global events, /global/health for health and version. Dashboards and multi-agent orchestrators never need to scrape terminal output.
• The endpoint surface covers project (list projects, current project), path and vcs (current path, version control info), instance, session, messages and tool calls - a real contract you can open in a Swagger explorer.

Our reading: this is the line between opencode and yet another terminal chat client. Because the agent is a service with an OpenAPI contract, downstream ecosystems (forks such as MiMo-Code, IDE plugins, CI integrations) inherit an interface rather than a codebase. A large share of those 210k stars is attributable to that single decision.

Agent orchestration: primary agents split by authority, subagents split by job

opencode separates agents into two classes and, crucially, distinguishes them with a permission system rather than with prompts:

Agent	Type	Tool access	Purpose
Build	primary (default)	All tools enabled	Real development work: read and write files, run commands, change the repository
Plan	primary	file edits and bash default to ask	Analysis and proposals with no writes. Use it when you want the model to read code, suggest changes and produce a plan without touching the codebase
General	subagent	Full tools except todo	Researching complex questions and executing multi-step tasks; the docs explicitly suggest using it to run multiple units of work in parallel
Explore	subagent	Read-only, cannot modify files	Fast codebase exploration: find files by pattern, search code for keywords, answer questions about the repository
Scout	subagent	Read-only	External docs and dependency research: clone a dependency repository into a managed cache, inspect library source, cross-reference local code against upstream implementations without touching the workspace
compaction / title / summary	primary (hidden)	Internal	Compact long context into a smaller summary, generate short session titles, create session summaries. They run automatically and are not selectable in the UI

The Tab key (or your configured switch_agent keybind) cycles primary agents; @ mentions invoke subagents. Scout deserves its own note: reading upstream implementation source is a constant need in real coding work, and it pollutes the workspace if you do it naively. opencode turns it into a read-only subagent plus a managed cache instead of letting the primary agent run git clone inside your project.

Model supply: 75+ providers plus a gateway that treats serving quality as the product

opencode uses the AI SDK and Models.dev to support 75+ LLM providers, and it runs local models too. Credentials added through /connect are stored in ~/.local/share/opencode/auth.json; provider.options.baseURL rewrites the endpoint for any provider, which is how proxies and internal gateways are handled. /models picks the model.

OpenCode Zen is the team own AI gateway and it is entirely optional - opencode works without it. The argument behind it is blunt: there are many models, but only a few work well as coding agents, and providers are configured very differently, so the same model served by different providers gives very different performance and quality. Route a model through a reseller and you can never be sure you are getting the best version of it. Their process has three steps: test a select group of models and talk to those teams about how to run them best, work with a few providers so those models are served correctly, then benchmark the model-plus-provider combination and publish a list they are willing to recommend.

Our reading: the value here is not the gateway, it is the admission that coding agent performance is the product of model and serving configuration. Reporting a model name alone is not enough. That matches the three rulers this site uses for the LLM domain: intelligence, capacity, supply. The models the docs recommend (explicitly non-exhaustive and possibly stale) are GPT 5.2, GPT 5.1 Codex, Claude Opus 4.5, Claude Sonnet 4.5, Minimax M2.1 and Gemini 3 Pro.

The engineering feedback loop: LSP, AGENTS.md, skills, custom tools, MCP, plugins

This is the thickest layer in opencode and the main reason it gets forked. Item by item, with the criteria that matter:

• LSP (35+ built in): typescript, pyright, gopls, rust-analyzer, clangd, jdtls, sourcekit-lsp, ruby-lsp, hls, julials, elixir-ls, ocaml-lsp, nixd, zls, gleam, dart, deno, csharp, fsharp, razor, kotlin-ls, lua-ls, php intelephense, clojure-lsp, bash, eslint, oxlint, prisma, terraform, tinymist, yaml-ls, astro, svelte and vue. Servers are detected by extension, auto-installed where dependencies are missing, and their diagnostics are fed back to the agent as signal. LSP is disabled by default; OPENCODE_DISABLE_LSP_DOWNLOAD=true blocks automatic downloads.
• The counter-recommendation on LSP (rare, and worth copying): the docs state plainly that LSP is not always a net positive. Language servers drift out of sync, consume significant memory, vary by version and project, and slow the agent loop down. In many projects it is better to let the agent run lint, typecheck or other diagnostic CLIs directly and document those commands in AGENTS.md or in skills. Documentation written to sell a feature does not include that paragraph.
• Rules: AGENTS.md carries project-specific instructions (comparable to Cursor rules). /init scans the important files in the repo, may ask a couple of targeted questions when the codebase cannot answer them, then creates or improves in place an existing AGENTS.md instead of blindly replacing it. It focuses on what future sessions actually need: build, lint and test commands, command order and focused verification steps, architecture and repo structure that filenames do not reveal, project conventions and operational gotchas, and references to existing Cursor or Copilot rules.
• Skills: .opencode/skills/<name>/SKILL.md, and it also reads .claude/skills/ and .agents/skills/ at both project and global level (~/.config/opencode, ~/.claude, ~/.agents). Project-local discovery walks up from the current working directory until it reaches the git worktree. Loading is progressive disclosure: the tool description lists only name and description (YAML frontmatter recognises name, description, license, compatibility, metadata; unknown fields are ignored), and the agent calls skill({ name }) to pull the full body. name must be 1-64 characters, lowercase alphanumeric with single hyphens, no leading or trailing hyphen, no double hyphen, and it must match the directory name.
• Custom tools: TypeScript or JavaScript files in .opencode/tools/ (or the global equivalent), where the filename becomes the tool name. Define them with the tool() helper from @opencode-ai/plugin for type safety and schema validation. The definition must be TS or JS, but the implementation may shell out to scripts in any language.
• MCP: local and remote servers, configured under mcp, each with a unique name and an enabled flag so a server can be turned off without deleting it. Added tools become visible to the model alongside built-ins. The docs warn in the other direction as well: MCP servers consume context, tool counts add up fast, and servers such as the GitHub one can easily exceed the context limit. Choose deliberately.
• Plugins: JS or TS files in .opencode/plugins/ (project) or ~/.config/opencode/plugins/ (global), loaded automatically at startup, or npm packages listed under "plugin": [...] in the config (scoped packages supported). Plugins hook events, change default behaviour and integrate external services.

Permissions and autonomy: three states plus one deliberate escape hatch

The permission config decides whether an action runs automatically, prompts you, or is blocked: allow, ask, deny. A global rule (*) can be overridden per tool. Since v1.1.1 the legacy boolean tools config is deprecated and merged into permission, still supported for backwards compatibility.

--auto automatically approves requests that are not explicitly denied - note the exact semantics: it only changes the requests that would otherwise ask, explicit deny rules still hold. opencode run --auto "Refactor this module" is the scripted form; in the TUI the command palette toggles auto-approve and a muted auto indicator appears next to the current agent. Plan defaulting to ask plus the --auto exception rule gives a graded autonomy dial rather than a single yolo switch.

Collaboration and delivery: share, GitHub, ACP, enterprise

• /share: creates a public link opncd.ai/s/<share-id> for a session and syncs conversation history to the project servers. Three modes, manual by default (nothing is shared automatically; /share generates the URL and copies it to the clipboard). Shared conversations are publicly accessible to anyone holding the link.
• GitHub: mention /opencode or /oc in an issue or pull request comment and the task executes inside your own GitHub Actions runner. Three jobs: triage an issue and explain it, fix an issue or implement a feature (it works in a new branch and submits a PR with all changes), and stay secure because execution happens in your runners. opencode github install walks through installing the GitHub app, creating the workflow and setting up secrets; manual setup means installing github.com/apps/opencode-agent and adding .github/workflows/opencode.yml.
• ACP (Agent Client Protocol): opencode acp starts opencode as an ACP-compatible subprocess speaking JSON-RPC over stdio. Zed can install it from the ACP Registry, or you configure command: opencode, args: [acp] under agent_servers in ~/.config/zed/settings.json. The significance is that opencode does not need to ship a plugin for every editor - the protocol is there, so editors can connect.
• Enterprise: aimed at organisations that need code and context data to never leave their infrastructure, using centralised config that integrates with SSO and an internal AI gateway. The project states that opencode does not store your code or context data; all processing happens locally or through direct API calls to your provider. The single caveat is the optional /share feature: enabling it sends the conversation and associated data to the service hosting share pages at opencode.ai, served through a CDN edge network and cached near your users, which is why the guidance is to disable it during an enterprise trial.

Placing it in the map on this site

Dimension	Where opencode sits	Cross-reference
Capability domains	Primary code (AI Coding)	It is a coding agent proper; its server, SDK and plugin surface also make it evidence for harness (Agent Harness)
Role in open source	The reference implementation	MiMo-Code forks it and adds persistent memory, context management, a goal referee model and compose workflows; deepseek-harness takes the opposite route where everything is a plugin
Stance on models	Model neutral	75+ providers, no lock-in; Zen is an optional curated gateway, not a required entry point
Extension surface	Five parallel ones: LSP, skills, custom tools, MCP, plugins	Against closed harnesses such as Claude Code or Codex, all five are open to the user and described by the OpenAPI contract
Autonomy control	Three-state permission plus --auto plus the read-only Plan agent	Graded and revocable, not unconditional auto-approval

One last point that touches how this site itself operates: opencode skill discovery reads .claude/skills/ and .agents/skills/ as well as its own directory, so the same skill folder is consumable by several harnesses. That is the practical argument for treating a skill as a cross-harness asset rather than as private configuration for one product - write it once and it is discoverable from opencode, from Claude-compatible layers and from other agent directory conventions.