Opsphere
← All articles

OpenCode AI: What It Is, How to Set It Up, and How to Use It Safely

OpenCode AI: What It Is, How to Set It Up, and How to Use It Safely

Abstract coding and operations platform illustration

OpenCode is an open-source AI coding agent that runs in your terminal, a desktop app or an IDE extension, and works with the model provider you choose. This guide covers what it does, how to install it, what it can cost, which safeguards to configure, and how to give it live production context for debugging and incident analysis.

Opsphere
Give OpenCode Production Context
Opsphere connects AI agents to operational context across cloud and engineering tools through MCP, with more than 300 read-only tools.

TL;DR

  • The problem: an AI coding agent sees your repository, but not what production is doing. Debugging a live failure then means switching between the agent, dashboards, cloud consoles and deploy history.
  • The takeaway: OpenCode is model-agnostic and supports MCP, so it can reach external tools. Its permission system lets you gate every tool it calls.
  • The safe pattern: use OpenCode for code and reasoning, and add Opsphere as a read-only operational layer over MCP. The agent gets production evidence and cannot change infrastructure.
  • The next step: install OpenCode, set permissions first, then follow the OpenCode MCP integration to connect live context.

Table of Contents

What OpenCode AI is

OpenCode is an agent that helps you write and run code with any AI model, in a terminal, a desktop app or an IDE extension, according to the project’s own site. It is released under the MIT License. The site lists more than 220,000 GitHub stars and about 950 contributors.

Three properties explain most of its appeal:

  • Terminal-native. You run opencode inside a project directory and work in a text interface, next to your shell, git and the rest of your toolchain.
  • Model-agnostic. It is not tied to one vendor. You bring a provider and a key, or a local model.
  • Extensible. It can load external tools through the Model Context Protocol (MCP), so the agent can call systems outside your repository.

The search term “opencode-ai” is also the name of an npm package and appears alongside the opencode.ai domain. If you are comparing sources, check that you are reading the current project at opencode.ai and not an older, unrelated project that happens to share the name.

How to install OpenCode and run a first task

The official documentation lists three install paths: the install script, npm, or Homebrew. You can also download binaries from the project’s Releases page. Pick the one that fits how your team manages developer tooling.

A first session looks like this:

  1. Install OpenCode with your preferred method.
  2. Open a terminal in your project directory and run opencode.
  3. Connect a model provider with /connect and paste its API key.
  4. Run /init. OpenCode analyzes the project and creates an AGENTS.md file.
  5. Ask for a small, reviewable task first, such as explaining a module or writing a unit test.

The AGENTS.md file matters more than it looks. It is where you record build commands, conventions and architecture notes so the agent stops rediscovering them each session. Commit it, and treat changes to it like any other review item.

A note on install hygiene

If you install through a script in CI or on shared machines, read it first and pin versions. A GitHub issue on the project describes how tar extraction in the install script can preserve the build user’s UID and GID, which could create a privilege-escalation vector, and it suggests adding --no-same-owner. Whether that is fixed by the time you read this, it is a good reminder to treat agent installers like any other software you run with elevated rights.

Which models and providers OpenCode can use

According to the providers documentation, OpenCode supports more than 75 LLM providers, including Anthropic, Google and OpenAI, and locally hosted models through tools such as Ollama or LM Studio. It also offers two optional paid services, OpenCode Zen and Go, which you can skip entirely if you use your own keys.

What this means for cost:

  • Bring your own key. You pay your provider for tokens. OpenCode itself is free software.
  • Local models. You pay in hardware and accept the quality tradeoffs of smaller models. Useful for sensitive code.
  • Enterprise. OpenCode Enterprise uses per-seat pricing, with no additional token costs from the platform if your organization routes through its own LLM gateway.

Model choice also affects what you can safely do in production work. A larger model reasons better across a long chain of evidence. A local model keeps data inside your network. Many teams use both, with a stronger hosted model for incident analysis and a local one for routine edits. If you want the same flexibility on the operational side, Opsphere supports bringing your own LLM.

Is OpenCode safe to use?

The honest answer depends on three separate questions: where your data goes, what the agent is allowed to do, and what you connect to it.

Three dimensions to assess AI agent safety

Where your data goes

OpenCode states that it does not store your code or context data and that it is built for privacy-sensitive environments. Its FAQ adds an important exception: data is stored when you use its free models. If you work with proprietary code, use your own provider under your own agreement, or a local model.

The optional /share feature sends conversation data to OpenCode’s hosting service when enabled. Per the enterprise documentation, it can be explicitly disabled in configuration. For a team, disable it centrally. Enterprise also provides centralized configuration, SSO and internal AI gateway support, intended to keep data within your organization’s infrastructure.

What the agent is allowed to do

OpenCode has two main built-in agents. Per the agents documentation, the Plan agent denies file edits, writes and patches by default, while the Build agent has all tools enabled. For unfamiliar code or an active investigation, start in Plan.

Beyond that, the tools documentation explains that you set each tool to allow, deny or ask in your configuration files. That covers actions like file editing and shell commands, and you can use wildcards to gate every tool from an MCP server at once.

What you connect to it

This is where most real risk sits. An agent with a shell and a cloud CLI logged in as an administrator can do whatever that administrator can do. The fix is not to avoid connecting production context. It is to connect it through an interface that is read-only by design.

How OpenCode uses MCP

MCP is an open protocol that lets an AI client call tools exposed by a server. OpenCode supports both local and remote MCP servers defined in its config, and their tools become automatically available to the model, per the MCP servers documentation.

In practice, that means you can add a server for your issue tracker, your docs or your infrastructure, and the agent can query it in the same conversation where it edits code. A minimal remote entry looks like this. The URL and name are placeholders, so take real values from the integration page:

{
  "mcp": {
    "opsphere": {
      "type": "remote",
      "url": "https://<your-opsphere-endpoint>",
      "enabled": true
    }
  }
}

Two cautions apply to any MCP server, not only this one. Every tool you add increases the context the model must reason over, and every tool is a capability you must decide to trust. Add servers deliberately, and gate them with permissions.

How OpenCode uses MCP — overview diagram

Why coding agents need production context

An agent that only sees code can explain a stack trace. It cannot tell you whether the error started right after a deploy, whether a node is under memory pressure, or whether a downstream dependency is failing. The developer fills that gap manually: open the observability tool, find the time window, check the deploy history, look at the cluster, then paste fragments back into the chat.

That manual loop has three costs:

  • Time. Each context switch slows the investigation.
  • Lossy evidence. Pasted screenshots and log snippets drop timestamps, labels and relationships.
  • Anchoring. The agent reasons from whatever you chose to paste, so your first guess shapes its answer.

Giving the agent direct, structured access to operational data removes the paste step and lets it test several explanations against the same evidence.

Adding Opsphere to OpenCode as a read-only operational layer

Opsphere does not replace OpenCode. OpenCode stays your coding agent. Opsphere is the operational intelligence layer that brings live production context into it through MCP, connecting cloud infrastructure, Kubernetes, observability, deployments and engineering systems. It works with the tools you already run and does not require replacing them.

The security model is the point. Opsphere is read-only by default and gives controlled access to production context. It does not allow direct infrastructure changes. Its platform exposes more than 300 read-only operational tools, so the agent can look, correlate and report, but it cannot restart a pod, edit a security group or roll back a release. Details are on the security page, and the MCP operational gateway page explains how access is mediated.

This pairs naturally with OpenCode’s own permissions. A sensible setup has two layers:

  1. At the source: the operational data is exposed read-only, so a bad instruction cannot become a write.
  2. At the client: OpenCode’s permission rules decide which tools run automatically and which ask first.

For example, a wildcard rule in your OpenCode config can require approval for all tools from the Opsphere server while you build trust, then relax to allow for the read-only investigation tools you use constantly. Check the tools documentation for the exact permission syntax in your version.

Practical workflows from the coding environment

The following workflows describe what the setup is for. They are illustrative scenarios, not customer stories or measured results.

1. Investigate a production error without leaving the terminal

You get a report that checkout requests are failing. Instead of opening four tabs, you ask OpenCode to pull the failing service’s recent errors, the pods behind it and their state, and the related alerts. The agent returns a timeline in one place, and you can ask it to open the code path that matches the error.

What to ask for: the time the errors began, which services share the same symptom, and which resources changed around then.

2. Check recent changes before touching code

Most incidents follow a change. Ask the agent to list recent deployments and configuration changes for the affected service and compare them with the start of the symptom. If the timing lines up with a release, you can read that diff with OpenCode right away. If it does not, you have just ruled out the most common cause and saved a speculative fix.

3. Correlate application failures with infrastructure signals

A timeout in application logs may come from a saturated database, a throttled node, a failing dependency or a network policy. Ask the agent to compare the failing code path with infrastructure metrics and Kubernetes events for the same window, and to state which signals support each explanation and which contradict it. Asking for the evidence behind each hypothesis keeps the agent honest and makes the result easy to review.

4. Debug with real configuration, not assumptions

When code behaves differently in production than locally, the difference is often environment: a resource limit, a missing variable, a different dependency version. With read-only access to the running state, the agent can compare what the code expects against what is actually deployed, then propose a fix in your repository for you to review.

5. Write up the incident while context is fresh

After resolution, ask OpenCode to summarize the timeline, the evidence checked, the cause and the code change, drawing on the same operational queries. You edit and approve it. The agent supplies a structured first draft grounded in what it actually retrieved.

Setup checklist for teams

Use this order. It keeps risk low while you learn how the agent behaves.

Step Action Why it matters
1 Install OpenCode and run /init Creates AGENTS.md so conventions persist
2 Connect a provider you have a data agreement with Avoids free-model data storage for proprietary code
3 Disable /share in team config Stops conversation data going to a hosting service
4 Default to Plan for investigation File edits are denied by default in that agent
5 Set permissions to ask for MCP tools You review each new tool call at first
6 Add Opsphere as a remote MCP server Brings read-only production context into the session
7 Relax approvals for proven read-only queries Cuts friction once behavior is predictable
8 Review AGENTS.md and config changes in pull requests Keeps agent behavior auditable

Also decide up front who can add MCP servers. A shared configuration file in the repository, reviewed like code, is easier to govern than each developer adding their own.

What to measure

Do not judge the setup by how impressive a demo looks. Track a few operational numbers before and after you adopt it:

  • Time to first useful hypothesis during incidents.
  • Number of tools opened per investigation, as a rough proxy for context switching.
  • Rework rate: how often an agent-proposed fix is rejected in review because it missed a production fact.
  • Approval prompts per session, to decide which permissions to relax.

Compare like with like, such as similar severity and similar services, and keep the sample honest. A small team can reasonably review a month of incidents by hand.

Opsphere plans for teams adding production context

Opsphere is published with a free Community plan at €0 per month, a Developer plan at €19 per month and a Team plan at €500 per month. Enterprise and Custom Solutions are also available, and the pricing page has the current details. If you are an individual developer who wants to try live context inside OpenCode, start with the entry tiers. If a platform or SRE team wants shared access, review the Team plan and the platform overview.

When you are ready, follow the OpenCode MCP integration guide to connect Opsphere, then start with one real, low-severity incident and compare it with how you would have investigated it before. You can also book a 20-minute demo if you want to see it against your own stack.

FAQ

Is OpenCode AI free?

The software is free and open source under the MIT License. You still pay for the model you use, either through your own provider key or through an optional OpenCode service, unless you run a local model. Enterprise is priced per seat.

Is OpenCode AI safe for proprietary code?

OpenCode says it does not store code or context data, but its FAQ says data is stored when you use its free models. For proprietary code, use your own provider under your own agreement or a local model, and disable /share. Enterprise adds SSO, centralized configuration and internal gateway support.

Can OpenCode change my infrastructure?

Only if you give it a way to. With shell access and cloud credentials, an agent can run whatever those credentials permit, so gate those tools with permissions. Opsphere is read-only by default and does not allow direct infrastructure changes, so connecting it adds visibility without adding write access.

Does Opsphere replace OpenCode?

No. OpenCode remains your coding agent. Opsphere adds live operational context, covering cloud infrastructure, Kubernetes, observability and deployments, to it through MCP, so the agent can investigate with evidence while you stay in the coding environment.

Sources

Opsphere
Discuss OpenCode and MCP
Reach out to discuss how Opsphere's read-only operational tools can connect AI agents with cloud, observability, and engineering context.

This article is provided for general informational purposes only and does not constitute professional, legal, security, or compliance advice. Please evaluate recommendations against your organization’s specific environment and requirements.