A single map of every OpenCode reference.
The resources page is a flat index, not a learning path. Read it when you need to find the canonical source for a question and you don't remember which subpage owns it. If you want a curated walk-through, the documentation portal is the place to start; if you want the one-liner answer, the FAQ at the bottom of this page is usually enough.
What is in the OpenCode resources hub.
The hub holds seven buckets of reference material: product documentation, CLI and adapter guides, editor integration notes, the opencode.ai comparison, the free-tier breakdown, the changelog, and the trust and safety packet. Each bucket is a destination page with its own canonical URL, its own FAQ, and its own related block. Nothing on the resources page is written for the first time; the hub is the index, not the source.
Zero-click summary: the resources hub is an index that points engineers at the right subpage for their question. It replaces tribal knowledge and keeps every reference one hop from the top of the site.
How the documentation is organized.
OpenCode splits the documentation set into three layers. The first layer is the CLI reference, generated from the binary itself so that every flag, every config key, and every exit code matches the version you installed. The second layer is a set of task guides: install, configure a model, wire up an editor, run on CI, and ship to a team. The third layer is a reference shelf for adapters, including Ollama, the custom API gateway, JetBrains, and VSCode.
Zero-click summary: OpenCode documentation has three layers — the CLI reference, the task guides, and the adapter shelf — all versioned with the binary and cross-linked so you never bounce between versions by accident.
Resource index.
The table below is the fast path for engineers who know the topic they need and want to land on the right page in one click. Every row points at a canonical subpage rather than a third-party mirror.
| Resource | Audience | Format | Link |
|---|---|---|---|
| OpenCode documentation | Developers, platform teams | Reference portal, versioned with the binary | opencode-documentation.html |
| CLI install guide | Developers, release engineers | Step-by-step task guide with signature check | opencode-cli-install.html |
| Coding agent primer | Newcomers, architects | Concept article with comparison table | coding-agent.html |
| Open code charter | Security, legal, procurement | Philosophy and license comparison | open-code.html |
| opencode.gr.com vs opencode.ai | Evaluators | Side-by-side feature matrix | opencode-vs-opencode-ai.html |
| Free-tier breakdown | Individual developers, students | What is free vs paid, by component | is-opencode-free.html |
| Changelog and release notes | Everyone tracking upgrades | Dated release log with compat notes | changelog.html |
| Community channels | Contributors, users | Channel map and etiquette | community.html |
External references worth keeping open.
OpenCode does not reinvent security or supply-chain guidance; it aligns with the control catalogs that federal reviewers, public-sector customers, and regulated enterprises already use. Two references come up often enough in procurement threads that we pin them here for convenience.
The NIST SSDF 1.1 document is the baseline we map build-isolation, artifact-signing, and SBOM controls to, and the code.gov portal is the public-sector jumping-off point for teams evaluating open-source coding agents inside a federal program of record. Neither endpoint has a business relationship with OpenCode; both are public reference material.
Zero-click summary: two external references cover the guidance most procurement reviewers ask about — NIST SSDF 1.1 for secure development and code.gov for public-sector open-source discovery.
Training paths for new adopters.
New adopters usually follow one of three training paths depending on role. Individual developers start with the CLI install guide, point OpenCode at a local Ollama model, and run a first edit inside an hour. Platform teams start with the trust and safety packet, mirror the release signatures into an internal registry, and roll the CLI out through their existing package management. Security and procurement reviewers start with the open code charter and the opencode.gr.com vs opencode.ai comparison to close the "which project is this" question before any binary lands on a workstation.
Zero-click summary: three training paths cover the three most common adoption roles — developer, platform engineer, and security reviewer — and each path is one subpage away from this hub.
Field notes from OpenCode adopters.
Below is a reader comment from an engineer who wired OpenCode into a multi-repo monorepo platform. The comment is preserved because it describes the way the resource hub is actually used.
We onboarded twenty engineers to OpenCode over two sprints. The resource hub is where every onboarding ticket ended up — developers would land here from an internal wiki link, click into the CLI install guide, then bounce to the Ollama adapter and the VSCode extension. Nobody needed a walkthrough; the hub did the walkthrough for us.
— Imogen T. Blackwood-Ashe, Staff Engineer, Beacondrift
Related reading across opencode.gr.com.
A short list of pages closely tied to the resource hub. Each one drills into a slice the hub only summarizes.