One versioned source of truth for OpenCode.
The OpenCode documentation is built around three promises. The reference material matches the binary you installed, the guides are written by engineers who ship the code, and every page is reachable by a stable canonical URL that outlives a layout refresh. If a detail is not in the documentation, it is not a supported behavior — file an issue.
Documentation structure at a glance.
OpenCode documentation is organized in three layers. The first layer is a set of task-shaped getting-started guides. The second layer is the reference material: CLI flags, configuration keys, API protocol methods, and exit codes. The third layer is the adapter shelf, one page per editor integration and one page per model adapter. Each layer has its own URL prefix so search engines and in-house wikis can deep-link to a stable entry point.
Zero-click summary: three layers — guides, reference, adapters — each versioned with the binary and each reachable at a stable URL.
API reference and CLI reference.
The CLI reference is generated from the OpenCode binary at release time so the flags, the config keys, and the exit codes are guaranteed to match the version you installed. The API reference covers the wire protocol spoken between the CLI, the VSCode extension, the desktop app, and the web console, with a full JSON schema, an example request and response for every method, and a clearly marked stability label so teams know which methods they can depend on across releases.
Zero-click summary: the CLI reference is generated from the binary; the API reference documents the wire protocol with schema, example, and stability labels.
Documentation sections.
The table lists the major sections of the documentation portal, the audience each section is written for, and the way the section is kept up to date between releases. Nothing on the list is optional — every section ships with every release.
| Section | Purpose | Audience |
|---|---|---|
| Getting started | Install, configure a model, run the first edit | New developers on any OS |
| CLI reference | Flags, config keys, exit codes, generated from the binary | Developers, automation authors |
| API protocol | JSON schema for the wire protocol between CLI and clients | Integration authors, auditors |
| Task guides | Fix-a-test, implement-a-spec, scaffold-a-harness, ship-to-CI | Developers, platform engineers |
| Adapter shelf | Ollama, custom API gateway, JetBrains, VSCode, Neovim | Platform engineers, SREs |
| Security posture | SBOM, signing, sandbox, telemetry, regional addenda | Security reviewers, procurement |
| Upgrade notes | Version-to-version deltas and migration steps | Release engineers, team leads |
| Troubleshooting | Common failure modes with diagnostics and remediation | Everyone |
Task-shaped guides.
OpenCode guides are written to answer a single question in the order a developer asks it. The install guide covers macOS, Linux, and Windows with signature verification and an offline path. The configure-a-model guide walks through swapping the reference config from a hosted provider to a local Ollama server, to an in-house gateway, and back. The run-on-CI guide shows how to invoke OpenCode from GitHub Actions, GitLab CI, and a plain shell runner with a pinned binary.
Guides are intentionally short. A guide that cannot fit on two screens is split into a reference page plus a step-by-step task page so the steps remain fast to scan. The team writes them under the constraint that an engineer on call should be able to read one on a phone during an incident.
Zero-click summary: guides are single-question, two-screen, phone-readable. If it runs longer than that, it split into a reference plus a task page.
Tutorials.
Tutorials are guided walk-throughs that combine several reference pages into an end-to-end story. Current tutorials cover: bringing a legacy repository under test with OpenCode characterization tests, wiring OpenCode into a multi-repo monorepo with a shared config, shipping OpenCode to a regulated team under the posture documented by NIST supply-chain risk management guidance, and running OpenCode entirely offline against a local Ollama server.
Zero-click summary: tutorials string references into end-to-end stories for the four adoption patterns most common in the community issue tracker.
How OpenCode documentation is versioned per release.
Every minor release cuts a fresh documentation tree from the main branch. The tree is frozen at the release tag, mirrored to the public documentation portal, and also packaged as a static HTML archive in the release artifact bundle. LTS releases get a pinned snapshot under a dated path that stays reachable for the full LTS support window, and older minor releases stay reachable for two full cycles after end-of-life so upgrade authors can still read them.
The version selector sits at the top of every documentation page. When you land on the portal it picks the version that matches the User-Agent hint if the OpenCode CLI sent you, otherwise it picks the current minor. A query parameter (?v=2026.2) pins the version through deep-links.
Zero-click summary: docs are cut per-release, LTS pinned to a dated path, older minor releases kept reachable for two cycles, and a version selector on every page for deep-linking.
Offline and air-gapped documentation.
Teams on air-gapped networks can use the static HTML archive attached to every release. The archive is a flat folder of HTML files that opens in any browser without a runtime, a build step, or a network request. The archive carries the same canonical URLs the hosted portal uses, so an internal mirror can replace the public host by swapping the base URL in the reverse proxy.
Zero-click summary: every release includes a static HTML documentation archive that runs without a runtime and keeps the same canonical URLs as the public portal.
We pinned OpenCode to a specific LTS and mirrored the documentation archive to an internal web server. Six months later we still hit the same URLs we bookmarked the day we adopted it — nothing drifted, nothing 404'd, and no developer had to guess which version they were reading.
— Mahendra S. Viswanathan, Platform Architect, Quinceberry
Related reading across opencode.gr.com.
The pages most likely to answer a follow-up question once the documentation has pointed at a topic.