opencode

Pricing

Open source

Platforms

Terminal, IDE, Desktop, macOS, Linux, Windows

Website

https://opencode.ai

Verdict for 2026

opencode is no longer just “an open-source terminal agent.” The official positioning now spans terminal, IDE, desktop, parallel sessions, shareable links, GitHub Copilot login, ChatGPT Plus/Pro login, local models, and more than 75 model providers.

My take: opencode is most interesting when you want ownership of the agent loop. Cursor and Windsurf optimize for a polished editor surface. Claude Code and Codex optimize for managed agent workflows. opencode is the more inspectable route: you choose providers, tune agents, keep command execution visible, and decide how much of the workflow should stay local.

What It Actually Is

opencode is an open-source AI coding agent built around a terminal-first workflow, but its surface is broader than the terminal. The official site highlights a terminal UI, editor integration, desktop app, multiple parallel sessions, share links, provider flexibility, and support for local models.

The important part is not the UI list. The important part is that opencode treats the coding agent as a configurable system. You can choose model providers, define agents and subagents, route work through different models, and keep the command loop close to your repository.

Best For

• Developers who want terminal-native control without giving up IDE or desktop options.
• Teams that want model flexibility across Claude, GPT, Gemini, local models, and other providers.
• Engineers who care about reviewing commands, diffs, prompts, and configuration.
• Repositories where test commands and rollback paths are explicit.
• Teams comparing open-source agent loops with Claude Code, Codex, Cursor, and Cline.

Not Best For

• Users who want the smoothest editor-first onboarding.
• Teams that do not want to own provider, model, and permission policy.
• Sensitive repositories without clear command boundaries and secret handling.
• Product work where acceptance criteria are vague and the agent is expected to infer everything.

Model and Agent Configuration

The opencode docs emphasize provider and model configuration. That is a real advantage, but it also creates operational responsibility. The question is not just “which model is best?” It is “which task deserves which model, which provider, and which cost profile?”

My practical split:

• Use stronger frontier models for unclear bug fixes, architecture tracing, and multi-file refactors.
• Use cheaper or local models for mechanical edits, documentation drafts, test scaffolding, and search-heavy tasks.
• Define separate agents or subagents for review, implementation, documentation, and debugging instead of letting one generic agent do everything.
• Record the model, prompt, settings, and verification command for repeatability.

Recent Features Worth Tracking

opencode’s recent direction is less about becoming a prettier terminal and more about becoming a configurable open agent runtime. The official docs now make several pieces explicit: primary agents, subagents, specialized built-in agents, permission keys, MCP servers, LSP, custom tools, Agent Skills, server mode, SDK usage, plugins, and Agent Client Protocol support.

The biggest practical changes to watch:

• Primary agents and modes: opencode ships Build and Plan as primary agents. That matters because planning and implementation should not be the same operating mode.
• Specialized agents: built-in agents such as Explore, Scout, General, Reviewer, Summarizer, Title, and Code Indexer make opencode feel closer to an agent team than one generic assistant. My read: this is the same architectural pressure visible in Claude Code and Codex, but with more local control.
• Permission keys: agent configuration can express which tools are allowed, asked, or denied. This is the difference between “the agent can run commands” and “the team has a reviewable execution policy.”
• MCP, LSP, and custom tools: MCP extends opencode outward to external systems, LSP improves code intelligence, and custom tools let teams expose their own scripts or internal workflows.
• Agent Skills: skills give opencode a way to package reusable instructions and workflow behavior rather than relying on long prompts in every session.
• ACP, server, SDK, and plugins: Agent Client Protocol support, server mode, SDK usage, and plugins make opencode easier to embed into editors, automation, and team-specific surfaces.

Recent release notes outside the core docs also show the product moving quickly around editor support, session path handling, Copilot model sync, model updates, and instruction precedence. I would treat those as signs of velocity, but still evaluate opencode through the stable architecture: provider choice, agent configuration, permissions, reproducibility, and command visibility.

Where It Beats Cursor

opencode is stronger when the team wants a transparent agent loop rather than a polished editor experience. If you care about provider choice, terminal logs, command boundaries, repeatable prompts, and local or self-controlled workflows, opencode deserves serious testing.

It also fits teams that do not want their AI coding strategy tied to one editor vendor. You can still use an editor, but the agent workflow is not owned by the editor.

Where Cursor Still Wins

Cursor remains easier for interactive code reading, inline editing, and onboarding non-terminal-heavy developers. If the daily job is “select code, ask, edit, continue,” Cursor will usually feel faster.

opencode asks more from the operator. That is a feature for disciplined teams and a cost for casual users.

Adoption Checklist

• Start with one real maintenance issue that touches multiple files but has clear tests.
• Write down allowed commands, blocked files, secret rules, and rollback expectations.
• Decide which providers and models are allowed for which task classes.
• Test one local-model route and one frontier-model route before committing to a cost model.
• Compare output against Claude Code, Codex, Cursor, and Cline on the same issue.
• Measure review time, not only completion time.

Quality Signal

The strongest opencode signal is a small, explainable diff with a visible command log and repeatable settings. The weakest signal is an impressive demo that no teammate can reproduce.

Related Tools

• Claude Code if you want a managed terminal agent with Opus, subagents, hooks, and Dynamic Workflows.
• OpenAI Codex if you want ChatGPT-native cloud/local delegation, mobile steering, Automations, and GitHub review.
• Gemini CLI if you want a Google-native terminal agent with generous free access and MCP support.
• Aider if you prefer a Git-centered terminal workflow with explicit diffs and model choice.
• Qwen Code if you want another terminal agent path around Qwen models.
• Cursor, Windsurf, Cline, and Roo Code if you want editor-first alternatives.
• 9Router and OpenRouter if your main concern is routing, fallback, and model/provider cost control.
• OpenHands and GitHub Copilot if you are comparing broader team automation platforms.

Source Notes

• opencode’s official site describes terminal, IDE, desktop, multi-session, share links, GitHub Copilot login, ChatGPT Plus/Pro login, provider flexibility, and local-model support.
• opencode docs describe provider/model configuration, primary agents, subagents, permission keys, MCP, LSP, custom tools, Agent Skills, ACP, server mode, SDK usage, and plugins.
• Recent opencode release notes and package activity show rapid movement around editor support, model sync, model updates, session handling, and instruction precedence; treat these as velocity signals and verify exact behavior against the current docs before standardizing.
• This page uses private Coding Agent Tools diagrams based on the public product model, not copied official screenshots.