"OpenCode" gets searched by two different kinds of people who end up at the same GitHub repository. Some are looking for an agent that isn't tied to a single model vendor, that they can point at Anthropic, OpenAI, Gemini, a local model, or whatever their client's procurement policy allows that week. Others are looking for an agent that never has to send code outside infrastructure they control. OpenCode answers both, and the SERP for the term is dominated by the project's own site, its GitHub repository, and tutorial coverage of how to install and configure it. Almost none of it asks what a team gives up, in terms of a record it can show someone else, by choosing the option nobody operates on your behalf.
What OpenCode is, and why teams choose it over a closed agent
OpenCode is an open source coding agent built for the terminal, with a desktop app for macOS, Windows, and Linux, and IDE integrations on top. It's MIT licensed, maintained by Anomaly on github.com/sst/opencode, and has crossed 200,000 GitHub stars, which puts it ahead of most closed competitors on raw adoption. It connects to more than 75 model providers through Models.dev in a single config file, so a team isn't locked into one vendor's model the way they are with Claude Code or Cursor's own defaults. By design, it doesn't store your code or context data itself: a real reason for a team that can't let source leave its own environment to pick it over a hosted product.
That combination, model-agnostic, MIT licensed, nothing stored by the tool itself, is exactly why OpenCode shows up in procurement conversations at software houses working under strict client contracts. It isn't a smaller or cheaper version of a closed agent. It's a different deal: you get the code and the freedom to run it anywhere, and you get everything that comes with owning the thing you run.
Open source changes who owns the infrastructure, not just the license
MIT licensing means the code is inspectable and modifiable, which is real and valuable on its own. It's a separate question from who runs the thing day to day. A closed coding agent ships as a hosted product: the vendor operates the backend, stores session data in its own format, and answers for uptime, retention, and (to whatever degree its terms allow) what happens to that data. Self-hosting OpenCode means the team runs that layer itself, on its own infrastructure, with its own choices about what gets kept and for how long.
That's not a downside of open source. It's the trade a team is explicitly making, and it's worth naming precisely because most of the coverage treats "open source" and "no vendor lock-in" as an unqualified win without following through on what "no vendor" also removes.
What a closed coding agent gives you by default
A hosted agent, Claude Code, Cursor, Copilot, gives an organization a few things without anyone on the team building them: a persistent backend that logs sessions somewhere the vendor controls, an admin console that shows usage across seats, a support line to call when something breaks, and a single company that's accountable if the product misbehaves. None of that is proof of delivery on its own, and the same gap exists inside those tools too: a vendor's own session log is still just a log in a format only that vendor's product can read, not a signed record a client can independently verify. But it is a default, persistent, someone-else's-problem layer that exists the day a team turns the product on.
What OpenCode leaves for the team to build
Take that default away and nothing appears in its place automatically. Because OpenCode doesn't store code or context data and runs wherever the team installs it, a session on one developer's laptop and a session in CI on a build agent don't get correlated anywhere unless the team wires that correlation itself. There's no admin console showing, across a whole engineering org, which repository a given session touched, who ran it, or under what instructions. There's no vendor support line to call when a client asks for proof six months after delivery. There's no built-in retention policy, access control on the logs the team does produce, or tamper protection, because there's no default logging layer to apply any of that to in the first place.
This is the same instruction-versus-record gap already true of hooks inside Claude Code, doubled. A hook log in a closed product is at least a starting point sitting on infrastructure someone is already operating. With a self-hosted, nothing-stored-by-default agent, a team doesn't inherit an incomplete log to strengthen. It inherits nothing, and has to build the whole evidence layer, from the model call to the signed release, from scratch, on top of a tool that was explicitly designed not to keep that data for them.
A checklist before running OpenCode on client work
- Where do sessions actually run. Laptops, a shared server, ephemeral CI runners, some mix. Each of those needs its own plan for capturing what happened, because OpenCode won't do it centrally for you.
- Who owns the log, once one exists. If the team builds session logging on top of OpenCode, someone has to own its retention, its access control, and its integrity, the same responsibilities a vendor would otherwise carry.
- Which provider is authorized for which client. Model-agnostic is a feature until a client's contract restricts which model can touch their code; that has to be enforced by the team's own configuration, not assumed from OpenCode's defaults.
- What happens when a client asks for proof. Not "what did the agent do" in general, but a specific, verifiable answer for a specific change, tied to who authorized it and who reviewed it, six months after the session closed.
- Who signs off before something ships. The layer that turns a record into proof sits above the agent, open source or closed: a person has to sign, and that step doesn't come installed with any coding agent, OpenCode included.
None of this is a reason to avoid OpenCode. It's a reason to be honest about what "open source" buys a team and what it doesn't. The license removes a dependency on one vendor's model and one vendor's infrastructure. It doesn't remove the question of what a software house can show a client when the session is long over, and for a tool that stores nothing by default, that question has no default answer either.