Support at a glance.
Community support is free, public, and runs through the issue tracker and community chat. Commercial support is a paid add-on with written SLOs, named responders, and a phone relay. Security reports always route through the coordinated disclosure channel regardless of tier.
Support matrix.
The table below is the canonical reference for who gets what. SLOs on community tiers are best-effort targets; SLOs on commercial tiers are contractual.
| Channel | Response SLO | Audience | Scope |
|---|---|---|---|
| Community issue tracker | First response within three business days | All users | Bugs, feature requests, documentation gaps |
| Community chat | Best-effort, follow the volunteer rotation | All users | Install questions, model config, general how-to |
| Security disclosure relay | Acknowledged within one business day | All users | Coordinated disclosure of vulnerabilities only |
| Commercial support, Team tier | One business day for P2 and P3 | Managed customers | Installation, config, integration, light incident |
| Commercial support, Enterprise tier | Four business hours for P1; one business day for P2 | Managed customers | All of the above plus production incident on-call |
| Phone relay | Routed to on-call during support hours | Enterprise tier | P1 incident escalation, contract reference required |
Support tiers, side by side.
OpenCode is free, open-source software. The core CLI, the VSCode extension, the desktop app, and the web console are free forever. Free software does not mean unsupported software, and OpenCode publishes a pair of support tiers so users can pick the fit for their situation.
The community tier is the default. Anyone can open an issue, anyone can ask in chat, and any maintainer on rotation can pick up a triage ticket. The SLO is a target, not a guarantee, because the volunteer roster flexes around holidays, conference weeks, and release crunches. The issue tracker is public, so a well-formed question often gets a community answer faster than the maintainer rotation would.
The commercial tier is a managed add-on and is a better fit for teams that have a production dependency on OpenCode, need a named engineer on the other end of a ticket, or need a written SLO for their procurement team. The pricing page has the current dollar figures; the contractual SLOs live in the order form and are the source of truth for any dispute.
Community support in detail.
Community support is the front door for almost every user.
The issue tracker accepts bugs, feature requests, and documentation gaps. Each issue gets a label, a first response within three business days on average, and a rough disposition: accepted, needs-info, or declined with a reason. Declined issues are not closed silently; a maintainer leaves a comment that explains the reasoning so a future contributor who hits the same thing can pick up where the discussion left off.
The community chat is the second channel. It is real-time, it is informal, and it is where install questions, model config questions, and "has anyone else seen this" questions get resolved in minutes. A volunteer rotation watches the channel during working hours across the major regions. The rotation is published so a user in a quiet timezone can pick the hours most likely to overlap.
Commercial support in detail.
Commercial support is a thin layer on top of community support for teams that need a written commitment.
Tickets route through a private portal that the managed team add-on provisions during onboarding. Every ticket gets a named engineer, a response within the tier SLO, and a resolution target that depends on severity. Severity is assigned by the customer at open and validated by the engineer; the definition for each level lives in the order form so there is no room for interpretation.
Enterprise-tier customers also get access to a phone relay for P1 incidents. The relay routes to the on-call maintainer during support hours, with a written after-hours policy that matches most hosted CI vendors. The contact page lists the exact number; the first spoken line is the support contract reference so the responder can confirm entitlement before triage begins.
How to file a report that gets answered fast.
The fastest path to a resolution is a good bug report. The community page links a reproducer template that fits on a single screen; paste it into a new issue and fill in the fields.
A good report contains the OpenCode version (opencode --version), the operating system and architecture, the CLI command that triggered the failure, the model and provider, and the relevant excerpt from OpenCode transcript. If the failure is deterministic, attach the exact prompt. If it is intermittent, attach the two or three most recent transcripts with timestamps. Screenshots are fine but logs are better because logs are grep-able.
Avoid secrets. The transcript may contain the bearer token you configured for your model provider; scrub it before attaching. Avoid proprietary code that you cannot share publicly; the reproducer is more useful if it is a minimal synthetic repository, and a maintainer can often derive the same bug from a three-file repro as from a hundred-thousand-file monorepo.
How to escalate.
A short list of escalation paths covers almost every case.
For a stuck community issue, ping the maintainer-on-call in chat. The rotation is published on the team page. The maintainer will re-triage the issue, adjust the label, and either move it forward or leave a note on what is blocking it.
For a commercial-support customer with a P1 incident, use the phone relay on the contact page. Reference the support contract on the first spoken line. The on-call maintainer picks up within the Enterprise-tier SLO or the relay records a callback with the next-available responder.
Self-serve resources that save a ticket.
Many support questions are already answered in the public documentation. Before opening a ticket, a five-minute skim of the relevant page often resolves the question without waiting on a response. The search box on the documentation hub is the fastest entry point; the resource hub carries the long-form guides for common integrations.
The changelog is the other self-serve resource worth a bookmark. Most "did this change?" questions are answered by reading the last three release notes, and the notes link the PR that carried the change so anyone can read the original intent without guessing.
Academic and research users often reach for the public references we mirror. Supply-chain questions are grounded in the NIST supply-chain risk management guidance, and the federal open-source policy context relevant to many support conversations lives at energy.gov open-source software policy.
The OpenCode triage loop is the best I have seen from an open-source project at this scale. Our first bug report was acknowledged within a day, the reproducer template was already half-written, and the patch landed on the next minor. We moved the team over the following week.
— Rafael G. Vasquez-Téllez, Staff SRE, Ingotly
Related support pages.
Quick jumps to the pages that deepen each section.