One agent runtime with several ways in
OpenCode is a coding agent whose main interface lives in the terminal. It can inspect a repository, edit files, execute shell commands, talk to model providers, and hand work to specialized subagents. A beta desktop application provides another front end, with installers for macOS, Windows, and Linux. The core attraction is choice: users are not tied to one model vendor or one fixed agent prompt.
Two primary agents establish the normal working split. Build is the default and has all tools enabled. Plan is intended for analysis, with file changes and shell commands set to ask. Built-in subagents handle general multistep work, read-only repository exploration, and external dependency research. Users can define more agents in JSON or Markdown, choosing their model, prompt, description, and permissions. That is enough structure to create a code reviewer or a documentation researcher without writing a plugin.
Provider choice is useful, and still needs ownership
The provider guide says OpenCode uses the AI SDK and Models.dev and supports more than 75 providers plus local models. A developer connects an account, selects a model, and can customize provider options such as a base URL. Whitelists and blacklists keep irrelevant or disallowed models out of the picker. OpenCode also sells optional model access through its own services, but those are not required to use the agent.
This flexibility solves procurement and experimentation problems, yet it does not remove them. Hosted providers need API credentials and charge according to their own terms. Local models need a server, hardware, and a compatible endpoint. Credentials added through /connect are stored under OpenCode's local data directory. Teams should decide which providers are approved, where keys may live, and whether project configuration can override organization defaults.
Configuration is layered. Remote organizational settings load first, then user, custom, project, .opencode directories, inline settings, and managed administrator policy. Most layers merge rather than replace one another. That is powerful for shared defaults, but a surprising project file can still change a user's effective configuration unless a managed policy overrides it. The documented JSON schema and explicit precedence list make these interactions inspectable.
What happened when we ran it
We cloned commit 7cde832 into a fresh unprivileged Debian container with three CPUs, 8 GB of memory, Node 22, and no secrets. The checkout contained 6,464 files and about 681,672 lines of source. Bun installation succeeded in 108 seconds. It installed 2,363 packages and consumed 2,474 MB, making source contribution a much larger proposition than installing the packaged command-line application.
There was no build script or target at the repository root, so our build step skipped it. That is a neutral result: the harness found nothing it could honestly call a root build. The repository is a workspace monorepo, and individual applications and packages have their own paths.
The root test command ran for 10 seconds and exited 1. Its entire message was do not run tests from root. This is an intentional guard, not a failed assertion. It also means our run produced no package test count and no evidence that the individual workspace suites pass. A contributor must read the contributing guide, identify the changed package, and run the commands specified for that part of the tree.
Permissions are capable but permissive
OpenCode can allow, ask, or deny actions. Rules can apply to a whole tool or to patterns such as particular shell commands, edit paths, URLs, skill names, and external directories. The last matching rule wins, so an administrator can begin with a catch-all and add narrow exceptions. Agent-level permissions then refine what Build, Plan, or a custom subagent can do.
The default posture favors getting work done. The documentation states that most permissions start as allow. Access outside the working directory and repeated identical tool calls ask, and .env reads are denied by default. Build still has broad file and command power inside the repository. Auto mode approves requests that would otherwise ask, though explicit deny rules remain active. On a personal scratch project that may feel convenient. On production source, teams should define denies for destructive commands, pushes, credentials, and sensitive directories before the first session.
MCP support widens the tool set. OpenCode can connect to local processes or remote servers, allowing a model to reach documentation, issue trackers, databases, and other systems configured by the user. Each connection introduces its own executable, URL, credentials, and tool descriptions. Keep the set small enough to review and disable servers that a project does not need. Provider freedom is useful; tool freedom deserves the same policy attention.
A fast-moving project with a large surface
The README covers packaged installation through a script and several package managers. It also documents the desktop downloads and labels that client beta. The wider documentation is stronger than the README itself, with separate guides for providers, agents, permissions, configuration, MCP, and deployment. New users should read the permission defaults before copying a model key into the application.
The repository was pushed on August 25, 2026. Release v1.18.22 arrived on August 24 with fixes for device login links, OpenAI-compatible provider options, Amazon Bedrock compatibility, and the desktop model picker. GitHub reported 5,359 open issues and pull requests combined. That queue is enormous, but daily code and release activity show a project processing demand rather than sitting idle. Fast releases also make pinning sensible for a team that wants repeatable behavior.
OpenCode fits developers who want to compare models, tune agents, and keep a terminal-centered workflow. Install the release rather than cloning the monorepo unless you plan to contribute. Before pointing Build at valuable code, set an explicit permission policy and confirm which configuration layers can change it. If an IDE-native experience or a narrower Git-oriented loop matters more, Continue or Aider may require fewer decisions.