OpenCode CLI in Practice: Workflows, Automation, and Pitfalls

OpenCode's command-line interface is built for scripting, CI pipelines, and unattended agent runs. This article is a practical guide to using it in daily work.

Behind the CLI sits a system of models, tools, permissions, agents, skills, commands, sessions, MCP servers, and a client/server architecture. The agent can read and edit project files, search repositories, execute shell commands, call external tools, and delegate work to subagents. The same environment runs interactively in the TUI or non-interactively from scripts.

For small tasks, you can install it, connect a model, and start asking questions within minutes. For serious work, the quality of the experience depends heavily on model selection, repository instructions, permission boundaries, context management, and how aggressively you allow the agent to operate. This article focuses on that second stage, from the command line: which use cases pay off, which automation workflows hold up in daily use, and which problems appear after the novelty of an AI-powered terminal wears off. It is part of the AI Developer Tools section of this site.

The observations here were checked against OpenCode 1.18.9 and the current documentation in August 2026. OpenCode changes rapidly, so configuration examples deserve a quick documentation check before being copied into a long-lived team setup. If you have not installed OpenCode yet, the OpenCode quickstart covers installation, verification, and provider connection.

What OpenCode Actually Is: An Agent Environment, Not a Chat Box

OpenCode is an open-source AI coding agent designed around the terminal. A simplified view of what it wires together looks like this:

flowchart TD
    U[Developer] --> T[OpenCode CLI or TUI]

    T --> A[Primary Agent]
    A --> M[Selected LLM]
    A --> F[File Tools]
    A --> S[Shell]
    A --> W[Web Tools]
    A --> L[LSP and Code Intelligence]
    A --> X[MCP Tools]
    A --> C[Skills and Commands]
    A --> G[Subagents]

    F --> R[Repository]
    S --> R
    L --> R
    G --> M

    P[Permission Rules] --> A
    I[AGENTS.md] --> A

The important part is the permission layer between a model's intent and the actions OpenCode can perform. An excellent model with bad permissions can be dangerous. A weak model with perfect permissions is merely slow and annoying. Productive OpenCode use requires getting both sides reasonably right.

The same environment serves both surfaces: the interactive TUI and the non-interactive command line. That is what makes OpenCode scriptable in a way a pure chat interface is not. If you want a deliberately minimal take on the same terminal-agent idea — four default tools, no built-in sandbox, everything else via extensions — the Pi Coding Agent review is a useful contrast.

Setup: Install, Connect, and Why Provider Independence Matters

OpenCode installs in one line — official install script, npm, or Homebrew — and starts with opencode from a repository directory. The OpenCode quickstart covers the full install matrix (Arch, Windows, Docker), verification, and provider connection (/connect and /models), so this article does not repeat it.

You can use OpenCode's own model services or connect supported external providers. OpenCode currently builds much of its provider catalog using Models.dev and supports a wide range of commercial and local model configurations.

Provider independence is one of OpenCode's most useful architectural decisions. Your coding workflow does not need to be permanently coupled to one model vendor: you can use one model for difficult architecture work, another for cheap implementation tasks, and a local model for code that should not leave your environment.

That flexibility is real, but it creates another variable to manage. When OpenCode performs badly, the problem may be the harness, the prompt, the available context, the selected model, or the interaction between all four.

Initialize the Repository with AGENTS.md Before Asking for Code

One of the first commands worth running in a new repository is:

/init

OpenCode analyzes the project and creates an AGENTS.md file. Commit that file.

AGENTS.md is where repository-specific constraints can become durable context for every conversation — interactive or scripted — instead of being repeated by hand. A useful file is short enough to remain relevant but concrete enough to prevent predictable mistakes. For example:

# Repository Instructions

## Architecture

- API handlers live under src/api.
- Business logic belongs under src/services.
- Database access belongs under src/repositories.
- Do not call database clients directly from HTTP handlers.

## Validation

After TypeScript changes run:

```bash
npm run typecheck
npm test
```

After frontend changes also run:

```bash
npm run lint
```

## Constraints

- Do not modify generated files.
- Do not change public API contracts without asking first.
- Do not create database migrations unless explicitly requested.
- Never run deployment commands.

This is less exciting than installing another MCP server, but it usually provides more value. Coding agents fail surprisingly often because they do not know which constraints are important. A short repository contract removes some of that ambiguity before the first tool call.

Work from the Command Line with opencode run

The interactive interface receives most of the attention, but OpenCode's non-interactive mode changes the range of useful workflows considerably:

opencode run "Explain the error handling strategy in this package"

You can use OpenCode from shell scripts, CI jobs, Makefiles, task runners, or local automation without manually entering the TUI every time. For example, a diff review as a one-shot command:

opencode run \
  "Review the current git diff for correctness and missing tests. Do not edit files."

Or pipe context straight into a run:

git diff --name-only HEAD~1 |
  opencode run "Inspect the changed files and identify risky behavior changes."

In a Makefile, the same call becomes a target:

.PHONY: review
review:
    opencode run "Review the current git diff for correctness and missing tests. Do not edit files."

Because a scripted run has no human at the prompt, the permission policy you configure is the only guardrail standing between the model and your environment. That is why the permissions section below matters more for automation than for interactive use.

The interesting direction here is not replacing deterministic scripts with an LLM. It is inserting model reasoning into places where traditional shell logic becomes awkward, while keeping deterministic validation around it.

The Best OpenCode CLI Use Cases

OpenCode can attempt almost any programming task, but that does not mean every task should be delegated in the same way. The highest-value workflows tend to have three properties: the desired result is testable, the relevant repository context can be discovered, and incorrect changes are cheap to inspect or revert. Each prompt below works in the TUI or as an argument to opencode run.

1. Repository exploration

OpenCode is excellent at answering questions that would otherwise require a sequence of grep, editor searches, file jumps, and git log commands. For example:

Explain how authentication works in this repository.

Trace a request from the HTTP middleware through token validation,
user loading, authorization, and the final handler.

Do not modify anything.

A good agent will search for entry points, follow references, inspect tests, and return something closer to an architecture walkthrough than a plain text search. This is one of the safest ways to introduce OpenCode into an existing codebase because the agent can provide value without writing code.

2. Small, well-bounded fixes

A narrowly scoped bug is close to the ideal coding-agent task. For example:

The CLI exits with status 0 when config validation fails.

Find the code path responsible, add a regression test, implement
the smallest fix, and run the relevant tests.

Do not refactor unrelated code.

The key phrase is not "fix the bug." It is the constraints surrounding the task. OpenCode works better when success can be demonstrated with a test, a compiler, or an observable command. Vague requirements give the model room to create plausible code rather than demonstrably correct code.

3. Test generation after implementation

Tests are useful agent work because the existing implementation gives OpenCode something concrete to reason about. A productive prompt might be:

Review src/parser.ts and its existing tests.

Identify important edge cases that are currently uncovered.
Add tests only. Do not modify the implementation.

Run the parser test suite when finished.

Separating test generation from implementation is important. If the same agent writes both the feature and the tests in one unconstrained pass, it can accidentally create tests that validate its own interpretation rather than the intended behavior.

4. Mechanical refactoring

OpenCode is very good at repetitive transformations where the desired end state is clear. Examples include:

• replacing a deprecated API across a repository;
• converting repeated code to a shared helper;
• renaming a configuration field;
• migrating tests from one assertion pattern to another;
• updating imports after moving a package;
• replacing an obsolete logging abstraction.

The repository's compiler and tests become the agent's feedback loop. A useful pattern is:

Replace uses of LegacyResult<T> with Result<T, AppError> in
packages/api only.

Preserve runtime behavior.

Work in small batches. After each batch run the package typecheck.
At the end run the package test suite and show me the final git diff
summary.

This is often more reliable than asking for the entire migration in one enormous step.

5. Code review

OpenCode becomes much more useful when review is treated as a separate agent role rather than another prompt sent to the same editing context. You can create a review-oriented agent that cannot edit files. Then give it instructions such as:

Review the current git diff.

Focus on:
- correctness;
- security;
- concurrency;
- missing tests;
- error handling;
- accidental API changes.

Do not summarize files that are unchanged.
Rank findings by severity.

A read-only reviewer is useful even if another coding agent produced the changes. The separation is valuable because implementation and criticism are different tasks: an agent that has just spent several thousand tokens defending one approach is often less skeptical of that approach than a fresh reviewer.

Use Plan and Build Modes as Different Mental Modes

OpenCode provides primary agents and subagents, with built-in workflows including planning and implementation-oriented behavior. Even when the exact agent configuration changes over time, the conceptual separation remains useful.

Planning should answer questions such as:

• Which files matter?
• What existing patterns should be followed?
• What could break?
• How will we verify the change?
• Is the requested change actually local?

Implementation should happen only after those questions have reasonable answers. For substantial tasks, I prefer a prompt sequence like this:

First investigate the request.

Do not edit files yet.

Return:
1. the relevant files;
2. the current behavior;
3. the proposed change;
4. risks;
5. the exact verification commands.

The same sequence works as a one-shot command:

opencode run "First investigate the request. Do not edit files yet. Return: the relevant files; the current behavior; the proposed change; risks; the exact verification commands."

Then inspect the plan before allowing edits. This feels slower than immediately telling an agent to "implement it," but the expensive failures in agentic coding usually come from incorrect assumptions made before the first edit.

This is a lightweight, per-task version of the same instinct behind spec-driven development: agree on the plan before the agent starts editing. For work that spans multiple files, sessions, or contributors, a written spec earns its overhead in a way a single investigate-first prompt cannot; the GitHub Spec Kit vs Kiro vs Claude Code comparison covers structured SDD workflows that go further than a single prompt.

Subagents Are Useful, but Delegation Is Not Free

OpenCode can invoke specialized subagents automatically or through explicit mentions. For example:

@general find where retry behavior is implemented

You can also define dedicated subagents for jobs such as security review, dependency analysis, frontend testing, or documentation. The same pattern works in other harnesses; the Claude Code subagents guide covers the analogous design on the Anthropic side.

This is powerful because subagent work can remain outside the primary conversation's immediate reasoning path. A primary agent can delegate repository exploration and consume the result instead of filling its own context with every intermediate search. But subagents create three less obvious costs:

1. They consume tokens. A tree of agents that each re-read the repository can become surprisingly expensive — my Oh My Opencode experience report documents what happens when that overhead is taken to the extreme.
2. They create policy complexity. Permissions must be considered for the delegated agent, not only for the parent.
3. Delegation can hide reasoning. When the primary agent says "the subagent found X," you may need to inspect the child session to understand how reliable that conclusion actually is.

For most coding tasks, two or three purposeful agents are more useful than an elaborate fictional software company living inside your terminal.

If the task genuinely needs a full orchestrator delegating to a fixed roster of specialists — parallel background execution, planning and research phases, model routing per role — that is a different product built on top of these primitives, not a bigger prompt. The Oh My Opencode quickstart covers that harness.

Use Custom Agents as Permission Boundaries

OpenCode agents can have separate prompts, models, and permissions. That makes agents useful as security and workflow boundaries, not merely different personalities. For example, a project-local review agent can be defined as a Markdown file:

---
description: "Reviews code without modifying the repository"
mode: subagent
permission:
  edit: deny
  bash:
    "*": ask
    "git diff *": allow
    "git status *": allow
    "git log *": allow
  webfetch: deny
---

Review code for correctness, security, maintainability,
unexpected behavior changes, and missing tests.

Do not modify files.

This is much better than writing "please do not edit anything" in prose. Instructions influence the model. Permissions constrain the tool. Those are not equivalent controls.

Configure OpenCode Permissions on Day One

One of OpenCode's most important practical characteristics is that its normal defaults are permissive. That is convenient during a demo and not necessarily what I want on a workstation containing SSH keys, production credentials, package publishing tokens, Kubernetes contexts, and access to several cloud accounts. For unattended opencode run jobs, the stakes are higher still: nothing stops a run except the policy you configure.

OpenCode's current permission model supports:

allow
ask
deny

Rules can be applied to file access, edits, shell commands, web operations, subagents, skills, external directories, and other tool categories. A conservative starting point might look like this:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "ask",
    "read": "allow",
    "grep": "allow",
    "glob": "allow",
    "edit": "ask",
    "bash": {
      "*": "ask",
      "git status *": "allow",
      "git diff *": "allow",
      "git log *": "allow",
      "git push *": "deny",
      "rm *": "deny"
    }
  }
}

The exact rules should match your environment. What matters is making the policy intentional rather than discovering the default after the agent has already executed something surprising.

Do not confuse approval prompts with sandboxing

Permission rules are useful, but they are not the same as operating-system isolation. If OpenCode has permission to execute an allowed shell command, that process runs with the access available to your environment. A coding agent can potentially interact with files, network services, environment variables, credentials, sockets, package managers, and other developer tooling.

For sensitive repositories or unattended runs, stronger isolation is worth considering:

flowchart TD
    H[Host Workstation] --> B[Restricted Container or VM]
    B --> O[OpenCode]
    O --> R[Repository Copy]
    O --> T[Build and Test Tools]
    O --> K[Limited Model Credentials]

    P[No Production Credentials] --> B
    N[Restricted Network Access] --> B

Git is rollback. Permissions are policy. A container or VM is isolation. Those are three different layers.

Turn Repetitive Prompts into Custom Commands

If you repeatedly type the same instructions, they should probably stop being chat history and become configuration. OpenCode supports project and global custom slash commands for the interactive interface. For example, create:

.opencode/commands/review.md

with:

---
description: Review the current changes
agent: plan
---

Review the current git diff.

Look for:
- bugs;
- security issues;
- incomplete error handling;
- missing tests;
- accidental API changes.

Do not modify files.

Then use:

/review

This is a small feature with disproportionate value. Reliable coding-agent workflows emerge when good prompts become shared project infrastructure rather than personal clipboard snippets. Other useful project commands might include:

/test-changes
/review
/prepare-pr
/check-migration
/update-docs
/release-check

Use Skills for Reusable Workflows

OpenCode also supports SKILL.md files. Skills are useful when a workflow needs more than a single prompt. A skill can contain detailed operational guidance and supporting files while remaining unloaded until the agent actually needs it. Useful candidates include:

• database migration procedures;
• release workflows;
• incident investigation;
• API compatibility reviews;
• package publishing;
• infrastructure validation;
• internal architecture conventions.

For example:

.opencode/skills/database-migration/SKILL.md

A skill description might tell OpenCode when the procedure applies, while the body explains how to inspect schemas, create migrations, validate rollback behavior, and run integration tests. If you already use the equivalent concept in another harness, the Claude Skills guide for developers maps the same design decisions.

The advantage is context discipline. Dumping every organizational rule into AGENTS.md eventually creates a giant system prompt that is expensive and increasingly easy for the model to ignore. Skills let specialized instructions enter context only when needed.

MCP: Useful Until the Tool Catalog Becomes the Problem

OpenCode supports local and remote MCP servers. That can expose issue trackers, documentation systems, browsers, observability platforms, databases, APIs, and other tools to the coding agent. A typical configuration might provide a documentation server:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

MCP is one of those features that is easy to overuse. Every tool the agent must understand consumes attention and frequently context tokens. A setup with fifteen MCP servers may look powerful in a configuration screenshot while making actual model behavior slower, more expensive, and less predictable.

My rule is simple: if a tool is not useful in a normal week of work, it probably should not be enabled globally. Load tools because a workflow requires them, not because the integration exists.

Local Models in OpenCode: A Real Option, Not a Magic Fix

One of OpenCode's strongest use cases is its ability to work with local or self-hosted OpenAI-compatible model endpoints. This is attractive when:

• source code must remain local;
• API costs are significant;
• you already operate GPU infrastructure;
• you want to experiment with open models;
• internet connectivity is unreliable;
• model routing is part of your platform.

A custom provider can point OpenCode to a local endpoint such as LM Studio, llama.cpp via llama-server, vLLM, Ollama-compatible infrastructure, or another OpenAI-compatible server.

This is where expectations matter. A good coding harness cannot compensate completely for a model that is weak at tool use, long-horizon planning, code reasoning, or instruction retention. Community discussions around local OpenCode setups repeatedly converge on the same observation: local models can be excellent for bounded tasks, but the smaller ones often need more supervision. For measured numbers on how specific models actually behave inside OpenCode, see my hands-on LLM comparison for OpenCode.

The practical solution is model routing by task complexity. Use a cheaper or local model for:

• repository search;
• documentation;
• simple tests;
• repetitive edits;
• formatting changes;
• straightforward bug fixes.

Use a stronger model for:

• architectural changes;
• ambiguous bugs;
• cross-package refactors;
• concurrency;
• security-sensitive code;
• difficult migrations.

Provider independence makes this strategy possible. It does not make model quality irrelevant.

A Practical Daily Workflow with OpenCode

My preferred workflow is deliberately conservative. It works the same in the TUI or via opencode run; where a step is a prompt, the command-line variant is shown alongside.

Step 1: Start from a clean Git state

git status

Either commit existing changes or deliberately record what is already modified. An AI coding agent operating inside a dirty working tree makes review much harder because human changes and agent changes become mixed together.

Step 2: Ask for investigation first

Investigate issue #482.

Do not modify files.

Explain:
- the current behavior;
- likely root cause;
- relevant files;
- existing tests;
- proposed fix;
- verification commands.

The same prompt as a one-shot command:

opencode run "Investigate issue #482. Do not modify files. Explain the current behavior, likely root cause, relevant files, existing tests, proposed fix, and verification commands."

If the investigation is wrong, correcting it is cheap.

Step 3: Narrow the implementation

Implement the proposed fix only.

Do not refactor unrelated code.
Add the regression test first.
Run the smallest relevant test suite after the change.

Or non-interactively:

opencode run "Implement the proposed fix only. Do not refactor unrelated code. Add the regression test first. Run the smallest relevant test suite after the change."

The agent now has a smaller decision space.

Step 4: Inspect the diff yourself

git diff --stat
git diff

Do not outsource this step to another model entirely. You are checking not only whether the code looks plausible, but whether the agent changed files it did not need to touch.

Step 5: Run deterministic verification

npm run typecheck
npm test
npm run lint

Use the actual project commands. "OpenCode says the tests pass" is not stronger evidence than your terminal displaying a successful test process.

Step 6: Run an independent review

Ask a read-only agent:

Review the uncommitted diff as if it were a pull request written
by another engineer.

Try to find reasons this implementation is wrong.

Do not edit files.

The command-line variant:

opencode run "Review the uncommitted diff as if it were a pull request written by another engineer. Try to find reasons this implementation is wrong. Do not edit files."

The phrase "try to find reasons this is wrong" is intentional. Models are very good at politely confirming plausible work. Review prompts should encourage falsification rather than applause.

Step 7: Commit only after the diff makes sense

git add -p
git commit

I still prefer interactive staging after agent-generated changes. It forces one final human pass across every hunk that becomes part of the repository history.

Where OpenCode Becomes Frustrating: Common Pitfalls

The interesting limitations are not usually "the AI made a syntax error." Compilers are good at catching those. The difficult problems come from autonomy, context, hidden assumptions, and configuration.

Challenge 1: Model quality dominates the experience

The same OpenCode workflow can feel excellent with one model and almost unusable with another. This makes product reviews difficult because users often attribute model behavior to the agent harness.

If OpenCode repeatedly:

• ignores instructions;
• rewrites too much code;
• calls tools incorrectly;
• loops on the same failed action;
• loses track of constraints;
• invents APIs;

try another model before redesigning the entire OpenCode configuration. The terminal did not suddenly become smarter. The model did.

Challenge 2: Long sessions accumulate bad context

Coding-agent sessions become less trustworthy as incorrect assumptions accumulate. An early mistake such as "this service is stateless" can influence dozens of later decisions even after the relevant files have changed.

OpenCode supports compaction to manage context limits, but compression creates its own tradeoff. A summary necessarily decides which details survive. For major task transitions, starting a fresh session is often cleaner than continuing a heroic 80,000-token conversation. With scripted runs the answer is even simpler: a new opencode run starts with a clean context every time, so long-lived state belongs in files like AGENTS.md, not in a conversation.

Context is not free memory. It is working state, and working state gets stale.

Challenge 3: Permissions can become deceptively complicated

Simple rules are easy:

read -> allow
edit -> ask
git push -> deny

Complex agent hierarchies are harder. Once primary agents can invoke subagents, custom tools, MCP servers, and shell commands, you need to reason about the effective capabilities of the whole workflow rather than one configuration line.

There have also been real community and GitHub discussions about subagent permission behavior and permission inheritance. The lesson is broader than any one bug: test security assumptions with an actual disposable repository — for example, git init /tmp/opencode-perm-test and try to make the agent run a command you denied there. If an action absolutely must not occur, do not rely on prose instructions alone.

Challenge 4: OpenCode changes quickly

OpenCode has shipped at a remarkable pace. That is good for features and less pleasant for documentation longevity. A particularly easy trap in 2026 is finding configuration examples from a different OpenCode generation. Current documentation also contains separate V2 material whose configuration schema differs from the established 1.x syntax. For example, permission concepts may appear under different field names in V2 documentation.

Do not casually combine examples from:

/docs/

and:

/v2/docs/

without checking which runtime you are actually using. When troubleshooting a configuration copied from a blog post, check its publication date before assuming OpenCode is broken.

Challenge 5: The TUI can hide scale

A conversational interface makes a ten-file change feel smaller than a ten-file change. The agent may report:

Implemented the new validation and updated the relevant tests.

That sentence could represent three lines or 600 lines. Keep independent shell tools close:

git status --short
git diff --stat
git diff --name-only
git diff

The coding agent should not be the only interface through which you observe the coding agent.

Challenge 6: MCP can destroy context efficiency

More integrations do not automatically produce a better coding agent. Large MCP servers can expose many tool schemas, each consuming model context and increasing tool-selection complexity. If OpenCode feels oddly indecisive after you installed half the MCP ecosystem, disable most of it and compare. A smaller tool surface often produces better agent behavior.

Challenge 7: Local privacy requires verifying the whole path

Running a local model does not automatically guarantee that every part of a toolchain is local. Community discussions in early 2026 raised privacy questions around OpenCode's auxiliary model behavior and web interface architecture. Some of those claims referred to older versions, some were disputed, and some code paths have since changed.

The durable lesson is not "OpenCode sends everything somewhere." The durable lesson is: if local-only operation is a hard requirement, verify it. Use network inspection, read the current configuration, understand which interface you are using, disable unnecessary remote integrations, and test the exact version you intend to deploy. Security requirements should be validated, not inferred from a product category.

OpenCode vs Claude Code and Codex CLI

OpenCode's strongest differentiator is not necessarily coding quality. The underlying model still contributes heavily to coding quality. Its differentiator is control over the harness.

OpenCode is compelling when you value:

• an open-source implementation;
• provider flexibility;
• terminal-first workflows;
• configurable agents;
• granular permissions;
• local-model support;
• MCP;
• reusable commands and skills;
• client/server architecture.

Claude Code is compelling when you want a tightly integrated Anthropic experience with strong first-party model behavior and increasingly polished built-in agent workflows. Codex CLI is compelling when your preferred models and workflow are already centered on OpenAI's coding stack.

I would not choose among them by counting features. Choose based on which layer you want to own. If you want a vendor to make most workflow decisions, a first-party coding agent can be attractive. If you want the harness to remain replaceable while you experiment with providers and agent configurations, OpenCode makes a stronger argument.

What Reddit and Hacker News Get Right About OpenCode

Community discussions around OpenCode are unusually polarized. Some developers describe it as their favorite coding harness, especially when combined with Codex models, local models, or custom agent setups. Others focus on resource usage, permission behavior, privacy questions, provider authentication changes, or the complexity that appears once a seemingly simple terminal application becomes infrastructure. Both perspectives are reasonable.

OpenCode is not difficult because the command line is difficult. It is difficult because an autonomous coding environment exposes questions developers previously did not need to answer explicitly:

• Which model should make this decision?
• Which files may it read?
• Which commands may it execute?
• Which credentials can the process see?
• Which tasks should become subagents?
• How much context should survive?
• Which tools deserve permanent context?
• Which result must a human verify?

A polished closed product can make many of those decisions for you. OpenCode makes more of them yours. That is precisely why advanced users like it.

A Starting Configuration I Would Recommend

I would resist building an elaborate setup immediately. Start with:

1. one strong default model;
2. one AGENTS.md;
3. conservative shell and edit permissions;
4. a read-only review agent;
5. two or three custom commands;
6. no MCP servers until a real need appears.

A simple environment is easier to debug. Once a workflow becomes repetitive, promote it into a command, skill, or agent. Once a capability becomes risky, restrict it with permissions. Once context becomes bloated, split the workflow instead of merely buying a larger context window. This incremental approach is less impressive in screenshots and considerably more pleasant to maintain.

Who Should Use OpenCode

OpenCode is a particularly good fit for developers who already live in terminals and want their coding agent to behave like another programmable development tool. I would strongly consider it if you:

• work across multiple LLM providers;
• want local-model support;
• dislike being locked to one AI vendor;
• need project-specific agents;
• automate development tasks from shell scripts;
• want to inspect or modify the coding harness;
• already understand Git and normal CLI tooling.

It is less compelling if you primarily want an invisible AI layer inside an IDE. OpenCode also expects more operational judgment than a traditional autocomplete tool. If reviewing diffs, understanding shell commands, and managing Git branches already feel uncomfortable, giving an autonomous process access to those tools will not make the underlying complexity disappear.

Final Verdict

OpenCode is one of the more convincing examples of an AI coding tool becoming developer infrastructure rather than merely a chat interface. Its best features are not flashy. Provider independence, explicit permissions, reusable agents, non-interactive execution, repository instructions, commands, skills, and composable tools make it possible to shape the agent around a real engineering workflow.

The weakness is the mirror image of that strength. OpenCode gives you enough control to create a disciplined coding environment, but it also gives you enough control to create a complicated, expensive, poorly isolated swarm of agents with twenty MCP servers and no clear verification boundary.

I would not optimize OpenCode for maximum autonomy. I would optimize it for short feedback loops. Give it a bounded problem, enough context to understand the problem, permission to perform only the necessary actions, and deterministic commands that can prove whether the result works. That is less magical than asking an agent to build an entire application while you sleep. It is also much closer to how OpenCode becomes genuinely useful.

References

• OpenCode documentation: https://opencode.ai/docs/
• OpenCode changelog: https://opencode.ai/changelog
• OpenCode GitHub repository: https://github.com/anomalyco/opencode
• Models.dev provider catalog: https://models.dev