What the OpenCode project is, in one paragraph.
OpenCode is a permissively licensed command-line coding agent with optional editor surfaces. The project is run by an independent maintainer council, releases on a published four-week cadence, funds itself through transparent sponsorship and a paid team add-on, and refuses to privilege any single model vendor. The CLI is the product; everything else is a thin client.
Project charter and data table.
The charter below is the short form of the governance document kept at the repository root. It is intentionally terse so it can be re-read in under a minute before a release.
| Item | Current value | Review cadence |
|---|---|---|
| License | Permissive open source, single LICENSE file at repo root | Annual outside-counsel review |
| Governance | Maintainer council with rotating chair; decisions by rough consensus | Quarterly council refresh |
| Release cadence | Minor every four weeks; LTS twice yearly; security patches out-of-band | Per release cycle |
| Security reporting | Coordinated disclosure via dedicated channel on the trust and safety page | Reviewed after every report |
| SBOM | CycloneDX 1.5 and SPDX 2.3 attached to every tag | Every release |
| Sponsorship | Accepted under one-page agreement, no roadmap preference | Public ledger, updated monthly |
Where OpenCode came from.
A succinct origin: OpenCode began as a weekend experiment among a handful of platform engineers who were tired of closed coding agents that shipped one editor plugin, locked you to one model, and uploaded your repository to a vendor cloud on every prompt.
The early commits landed in late 2024 as a throw-away shell script that wrapped a small tool schema around an OpenAI-compatible endpoint. Within three months the script had grown into a single-binary CLI that could read a repository, edit files, run tests, and loop until green. The authors open-sourced it under a permissive license and invited the first round of external contributors.
By mid-2025 OpenCode had a VSCode extension, a Windows build, an Ollama integration, and a desktop app wrapping the same CLI. The project formalized its governance in late 2025 with a maintainer council, a contributor license agreement reviewed by outside counsel, and a published release cadence. The goal from day one has been the same: an agent that disappears into the shell a developer already uses.
Maintainer philosophy.
The maintainers hold a short list of opinions that they enforce in review. They are boring on purpose.
First, the CLI is the source of truth. Every editor extension, the desktop app, and the web console talk to the same wire protocol. No feature lands in a GUI before it lands in the CLI, and any feature that only makes sense in a GUI is probably in the wrong project.
Second, the agent must be inspectable. Every prompt, every tool call, and every model decision lands in a plain-text log the developer can grep. When the agent gets it wrong, which it will, recovery is to read the log, adjust the config, and re-run. OpenCode does not hide the seams.
Third, the model is the user's choice. OpenCode speaks OpenAI-compatible JSON and a small tool schema. Any model that exposes that surface slots in through a YAML config block. The maintainers ship a reference config pointing at a popular hosted provider, but the project refuses to privilege any single vendor.
Governance model.
OpenCode is governed by a maintainer council of five to seven people who review architectural RFCs, accept or decline contributor promotions, and sign off on each release tag. The chair rotates quarterly, and any council member can call a vote on any open question with a forty-eight-hour comment window.
Day-to-day commits are reviewed by a rotating maintainer-of-the-week whose only job is to triage new issues, review pull requests, and merge anything that meets the contribution checklist. The maintainer-of-the-week role is open to any contributor who has landed three non-trivial PRs in the last quarter, and the schedule is published on the project calendar.
Architectural changes that touch the wire protocol, the CLI surface, or the security model go through a documented RFC process. Anyone can open an RFC; the council has to respond within fourteen days. Accepted RFCs land in the repo under docs/rfc/ with a permanent number so future changes can reference them directly.
Release cadence in practice.
A predictable cadence makes upgrade planning boring in a good way.
OpenCode cuts a minor release on the first Wednesday of every fourth week. The release notes are drafted by the chair, reviewed by the council, and published alongside signed binaries and SBOMs. An LTS release cuts every two quarters and is supported with security backports for a year.
Security patches ship out-of-band within seventy-two hours of a confirmed report. They are tagged as patch releases on the current minor and on the current LTS, with a public advisory linking the commit, the test that now guards the regression, and the suggested upgrade path.
Funding posture and upstream model relationships.
OpenCode accepts sponsorship from vendors, foundations, and enterprise users under a one-page agreement that prohibits preferential roadmap access, prohibits private forks of security fixes, and requires any sponsored maintainer to disclose affiliation in commit trailers. The sponsorship ledger is public and updated monthly on the funding page.
A paid managed team add-on covers hosted audit logs, SSO, and central policy for teams that want a supported rollout. The core CLI, the VSCode extension, the desktop app, and the web console are free forever under the project license, and no team feature will ever require upstream code to become closed-source.
The project keeps a deliberate distance from upstream LLM providers. OpenCode ships a reference config pointing at a popular hosted provider because users expect a zero-step getting-started, but the maintainer council reviews any change that would privilege one provider in routing defaults. Maintainers on the payroll of a specific LLM vendor recuse from votes that touch that vendor's adapter. Security-sensitive cryptographic modules are reviewed by external cryptographers sourced via MIT CSAIL referrals when the project can arrange it.
Supply-chain posture.
A coding agent that edits source has to be treated like a supply-chain element itself.
OpenCode follows the NIST supply-chain risk management guidance for build isolation, artifact signing, and dependency review. Every binary is reproducible from a public build recipe, every release tag carries an SBOM in CycloneDX and SPDX, and patch signatures are recorded in a transparency log so downstream distributors can detect drift before it reaches a developer workstation.
How to contribute.
The project is eager for contributors. The contribution guide lives at the repository root and is kept to a single screen. New contributors are asked to land a first PR with a test, a second PR that touches the CLI surface, and a third PR that touches the wire protocol or an adapter. After that, a contributor can nominate themselves — or be nominated — for maintainer status. The council reviews nominations quarterly.
A short code of conduct sits alongside the contribution guide. It is enforced by a rotating conduct committee whose members are published on the OpenCode team page. Reports go to the conduct alias listed there, and the committee commits to respond within one business week.
We audited OpenCode before adopting it for a 600-engineer org. The charter, the SBOM pipeline, and the fact that the CLI is the source of truth were the three checkboxes that made procurement painless. The agent is boring and inspectable, which is exactly what a security review wants.
— Rosalind B. Kenefick, Principal Engineer, Nubula Cloud
Related reading across opencode.gr.com.
Short links into the pages that expand on specific sections of this page.