Skip to content
Agentdex

Blog · · Agentdex Editorial

OpenCode Guide (2026): The Open-Source AI Coding Agent, Plans, Pricing and Setup

OpenCode is an open-source AI coding agent that runs in your terminal, as a desktop app, or inside your IDE, and works with almost any model provider. You keep control of your code, your model choice and your costs. This guide covers what OpenCode does, how it works, what it costs as of October 2026, and where it fits next to Claude Code (Agentdex profile), Cursor (Agentdex profile) and other AI coding agents.

Key Takeaways

OpenCode is an MIT-licensed, model-agnostic AI coding agent. It connects to 75+ LLM providers through Models.dev, including local models, and wraps them in a tool layer that reads and writes code, runs shell commands, and lets you undo and redo changes.

  • OpenCode separates the agent from the model, so you can switch between Claude, GPT, Gemini, open-weight and local models in the same project without changing tools.

  • Project context is central. Running /init creates or improves an AGENTS.md file for project instructions, and /undo and /redo let you roll back the agent's changes.

  • The client is free. Model usage still costs money unless you stick to OpenCode's free models or run local models: you pay your provider, use OpenCode Zen (pay-as-you-go), or subscribe to OpenCode Go ($10/month) or Go Plus ($40/month).

  • The MIT license lets you use, modify and redistribute OpenCode, including commercially.

  • OpenCode is not a turnkey product. Expect more setup than Claude Code or Cursor in exchange for flexibility and portability.

What is OpenCode?

OpenCode is an open-source AI coding agent that wraps modern AI models with tools for files, shell access and project context. It is not just a chatbot: it works directly in your repository, makes real file changes, runs real commands, and keeps a history you can review and reverse.

  • What it is: An agent layer around generative AI models. It can read and write files, search your repository, run shell commands, keep session history and show diffs before you commit.

  • License: MIT. Free for commercial use, modification and distribution. The OpenCode site reports more than 220,000 GitHub stars and around 950 contributors as of October 2026.

  • Model access: Model-agnostic by design. You can plug in Anthropic, OpenAI, Google, xAI and many other providers, plus local models through tools like Ollama or LM Studio. OpenCode lists 75+ LLM providers. You can also log in with a GitHub Copilot (Agentdex profile) or ChatGPT Plus/Pro account to use those subscriptions.

  • Form factors: A terminal UI (the original interface), a desktop app for macOS, Windows and Linux, IDE extensions, and a web interface. They all talk to the same local server.

  • How it differs from a chatbot: It has direct access to your file system, can run shell commands, enforces permission rules, stores session history locally, and gives you undo and redo for every change. It's a full coding agent, not a suggestion box.

Why OpenCode exists in the first place

Several concrete developer pain points led to OpenCode's creation. This isn't a generic "we wanted AI to be better" story. It's a direct response to real problems.

  • Vendor lock-in: Many coding agent tools tie you to one model provider. If that provider changes pricing, API rules, or access methods, your workflow breaks. Using open code can help avoid vendor lock-in, granting users more control over their software. OpenCode treats the coding agent as separate from any specific AI provider.

  • Access rules shift: Anthropic's terms say consumer Claude Free, Pro and Max sign-ins are only for Claude Code and Claude's own apps. Anthropic now enforces this against third-party tools, and OpenCode's sign-in options cover ChatGPT Plus/Pro and GitHub Copilot accounts, not Claude subscriptions. You can still use Claude models in OpenCode with an Anthropic API key, billed per token.

  • Cost instability: Model pricing and plan limits change often. A model-agnostic agent lets you switch providers without rebuilding your workflow.

  • Limited control: Closed agents give you little visibility into how they assemble context or enforce rules. OpenCode's code, config format and server API are all public.

  • Philosophy: Terminal-first, open protocol, local control. The idea is that models and providers will change; a tool that tightly couples tooling and model will suffer when providers shift. OpenCode isolates that risk.

The goal is a workflow that survives model and pricing changes, so you can adopt new models without rebuilding your setup.

How OpenCode works (high-level workflow)

Here's the basic loop of working with OpenCode. This section stays conceptual; architecture details come later.

  1. Install and initialize: Install OpenCode (install script, npm, Homebrew, Scoop, Chocolatey or the desktop app). Open a project and run /init, which scans key files and creates or improves an AGENTS.md file with build and test commands, structure notes and conventions.

  2. Connect a model: Run /connect to add a provider: OpenCode Zen, an API key from Anthropic, OpenAI or Google, a Copilot or ChatGPT login, or a local model.

  3. Choose an agent: Press Tab to switch between Plan (suggests how it will make changes without making them) and Build (allowed to edit files and run commands).

  4. Describe a task: In Plan, OpenCode proposes an approach. Give feedback, then switch to Build to implement it.

  5. Review and iterate: The agent edits files and runs commands. Review the diff. If it's wrong, run /undo and refine your prompt; if it's right, commit.

A developer at a desk with a terminal open on a laptop, the kind of setup where a terminal-based AI coding agent like OpenCode runs.

When you run OpenCode, it starts a local server and a client. The server manages sessions, tools and repository context; the terminal UI, desktop app and IDE extensions are front ends talking to that same engine.

Core architecture: local server, clients, and tools

OpenCode separates a stateful server process from lightweight clients. Here's how the pieces fit together.

  • Local server: Handles sessions, tool execution, model routing and permissions. Run opencode serve to start it headless; by default it listens on 127.0.0.1.

  • Clients: The terminal UI, desktop app and IDE extensions all communicate with the server. You can also script it through the SDK or the HTTP API.

  • API: The server publishes an OpenAPI 3.1 spec covering sessions, messages, files, providers, agents and config.

  • Tools: File read, edit and write, shell commands, glob and grep search, LSP queries, web fetch and subagent tasks. Permission rules decide whether each call runs, asks first, or is blocked.

  • Configuration: opencode.json (or opencode.jsonc) holds providers, agents, permission rules and model preferences, at global and project level.

The practical upshot: you can move between terminal, desktop and IDE without reconfiguring anything.

Supported AI models and providers

OpenCode is built to be model-agnostic. You're not locked to a single provider or model family.

  • Provider registry: OpenCode uses Models.dev for its provider list: cloud providers such as Anthropic, OpenAI, Google, xAI and DeepSeek, plus local options like Ollama and LM Studio.

  • Subscription logins: You can log in with GitHub Copilot or a ChatGPT Plus/Pro account instead of juggling per-provider API keys. Claude Pro/Max logins are not supported (see above).

  • Per-agent models: Each agent or subagent can use its own model, for example a cheap model for broad scans and a stronger one for refactors.

  • OpenCode's own options: A set of free models (availability changes), Zen (a pay-as-you-go gateway to models OpenCode has tested for coding agents) and Go (a low-cost subscription to a curated model lineup). All optional; you can always bring your own key.

  • The benefit: You can compare models on the same repository and instructions without switching tools: run the same task on two models and compare diffs, speed and cost.

Project context and repository context

Project context and repository context are what separate a coding agent from a generic chatbot. In OpenCode, this means the combination of AGENTS.md instructions, directory layout, and selected files that the coding agent can see and reason about.

  • AGENTS.md: The main repository-level instruction file. /init creates it (or improves an existing one) with build, lint and test commands, structure notes and conventions. It lives in the project root and should be committed to Git.

  • The /init command: Scans important files, may ask a couple of targeted questions, and writes concise project guidance. You can edit or extend the result.

  • File references: Typing @ fuzzy-searches files so you can pull a specific file into your prompt. Useful for targeted edits, but too many references waste context.

  • The trade-off: Richly detailed AGENTS.md and file references improve output. The coding agent respects existing patterns, avoids reinventing your project's structure, and makes better decisions. But overly long, unfocused instructions can dilute model attention and waste context space. Keep them sharp.

Good project context makes or breaks results. A sharp AGENTS.md is one of the most useful files in a repo you work on with AI.

An organized desk with labeled folders and a notebook, a visual metaphor for clear project instructions in an AGENTS.md file.

Working with AGENTS.md and instructions

AGENTS.md is OpenCode's central instruction file, similar in purpose to CLAUDE.md in Claude Code or rules in Cursor. Here's how to use it well.

  • Scope: Put personal rules in ~/.config/opencode/AGENTS.md and project rules in the repo's AGENTS.md. For Claude Code users, OpenCode falls back to CLAUDE.md if no AGENTS.md exists (and ~/.claude/CLAUDE.md globally). You can also list extra instruction files, such as CONTRIBUTING.md, in opencode.json.

  • What belongs in AGENTS.md: Test commands (npm test, pytest, make check), language/framework versions, code style conventions, naming rules (e.g., "Use kebab-case for CLI commands"), domain-specific constraints ("Don't modify generated files in /src/gen/"), and security-sensitive directories.

  • What doesn't belong: Vague platitudes like "follow company style guide" without specifics. Overly broad project notes that include incidental files. Outdated build commands. Messy, conflicting nested AGENTS.md files in subdirectories.

  • Commit it: Committing AGENTS.md means teammates and every agent session share the same expectations.

A good AGENTS.md entry: "Run 'npm run lint' before committing. Use TypeScript strict mode. Tests live in __tests__/ directories adjacent to source files."

A bad AGENTS.md entry: "Keep code clean and follow best practices." That tells the coding agent nothing actionable.

Keep instructions specific and current. Vague or outdated rules waste context and can steer the agent wrong.

OpenCode modes, permissions, and safety limits

OpenCode combines built-in agents with a permission system to balance speed and safety.

Agents:

  • Plan is the cautious agent. It disables the ability to make changes and instead suggests how it will implement a task. Use it for analysis and design.

  • Build is the default working agent. It can edit files, run tests and execute shell commands, subject to your permission rules. Switch between the two with Tab at any point.

Permission rules:

Permissions are set in opencode.json, globally or per agent. Each rule targets a tool (such as read, edit, bash or webfetch), optionally with a pattern, and resolves to allow, ask or deny. When several patterns match, the last matching rule wins, so put the catch-all first. Out of the box most permissions are allow; reading .env files and touching paths outside the project ask first.

Permission

Example resource

Effect

bash

npm *

allow

bash

rm *

deny

edit

src/*

allow

edit

*.env

ask

bash

git push *

deny

What this is not:

Permissions are a workflow safety net, not a security sandbox. Shell commands run with your user's privileges, and if you approve a dangerous command, it runs. Starting OpenCode with --auto approves anything not explicitly denied, so use it with care. For risky codebases, run OpenCode in a container or a separate machine (OpenCode publishes a Docker image).

Server mode best practices:

  • Keep the server on localhost (the default).

  • Set OPENCODE_SERVER_PASSWORD to require HTTP basic auth.

  • Don't expose the server directly to the public internet.

  • Configure tool permissions to deny destructive commands by default.

Undo, redo, and session history

OpenCode's /undo reverts the agent's changes and shows your original message again so you can rephrase. Run it several times to step back further, and /redo to restore. It's built for the moment a change isn't what you wanted.

  • How it works: Undo works per message: each request and response cycle can be reverted. This pairs well with Plan: explore an approach, build it, and revert if it doesn't hold up.

  • Session history: OpenCode says it does not store your code or context data on its servers; the exception is when you use its free models. Long sessions can be summarized or compacted to save context. Sharing a session creates a link, so don't share sensitive work.

  • Comparison to Claude Code: Claude Code also has checkpoints to rewind changes. The bigger difference is model choice: Claude Code is built around Anthropic's models, while OpenCode lets you pick the provider.

Use undo as a normal part of your workflow, and still review diffs before committing.

Local-first development with OpenCode

"Local-first" means running OpenCode on your machine, keeping project files local, and optionally using local models for inference. It's a spectrum, not a switch.

  • Fully local: With a local model (via Ollama, LM Studio or a self-hosted server), prompts and code don't need to leave your machine.

  • Hybrid: Most people connect at least one cloud provider for quality. Then prompts and code context go to that provider, and its data policies apply.

  • Trade-offs of smaller local models: More invalid tool calls, weaker understanding of large repos, and more manual oversight. Smaller models can misread complex code or lose track of multi-step tasks.

  • Hardware: Larger local models need a lot of RAM or GPU memory. Smaller models run on consumer hardware but with clear limits.

  • Privacy nuance: Even in a local setup, if you use share features or connect cloud providers, data may leave your environment. Configure permissions and sharing deliberately.

Local-first is a good option, but it's not a magic privacy switch. Understand what leaves your machine and what doesn't, then make informed choices about your local setup.

Common OpenCode workflows for real projects

This section bridges architecture and practice. Here's how developers actually use OpenCode week to week.

Typical workflows include building features, refactoring, debugging, writing tests for untested code, and getting oriented in unfamiliar code.

In all of them, OpenCode is an agent, not an autopilot. Human review of diffs, tests and deploys stays essential.

Cross-model testing is useful: run the same workflow on different models to see how they behave on your project.

Building new features with Plan and Build

The Plan and Build loop is OpenCode's core workflow for feature work.

  1. Start in Plan mode. Describe the feature you want. Include acceptance criteria and test commands directly in the request so the coding agent can validate behavior.

  2. Review the plan. The coding agent proposes which files to touch, what patterns to follow, and what trade-offs exist. Edit or reject parts of the plan before proceeding.

  3. Switch to Build. The coding agent implements the feature, creates or modifies files, and runs tests. AGENTS.md and repository context help the model respect existing patterns.

  4. Review diffs. Check what changed. If it's wrong, /undo and refine. If it's right, commit.

Different AI models might propose different designs for the same feature. Capture these differences when comparing providers. One model might favor composition where another reaches for inheritance. Knowing your chosen model's tendencies helps you write better project instructions.

Refactoring and large-scale cleanups

Refactors are where coding agents earn their keep, or cause expensive messes. OpenCode's approach:

  • Start in Plan mode. Map dependencies, call sites, and potential breakpoints before any code is changed. Let the agent trace through the codebase and identify risks.

  • Restrict Build scope. During big refactors, limit Build mode to narrower directory scopes. This keeps diffs reviewable and reduces the blast radius of mistakes.

  • Use /undo checkpoints. After each major step, verify tests pass. If they don't, revert to the earlier snapshot and try a different approach. This is especially important when using newer or less-tested models.

  • Lean on LSP diagnostics. OpenCode can use language servers for diagnostics, giving the agent a tighter loop for catching type errors during refactors.

Debugging and incident response

Debugging with OpenCode follows a structured loop:

  1. Feed context. Paste stack traces, error logs, or reproduction steps. The coding agent traces through relevant files and proposes hypotheses.

  2. Triage with cheaper models. Use a less expensive model for initial exploration. It may not get the fix right, but it can narrow the search space.

  3. Patch with a stronger model. Switch to a higher-quality model for the actual fix. Run tests to verify.

  4. Record what worked. Keep a record of successful debug sessions in AGENTS.md or project docs to help future coding agents handle similar issues faster.

Debugging quality depends heavily on accurate reproduction steps and good logging. Generative AI cannot guess missing runtime state. Feed it real data, and it performs; feed it vague descriptions, and it hallucinates.

The OpenCode desktop app

The OpenCode desktop app is available for macOS (Apple Silicon and Intel), Windows (x64 and ARM64) and Linux (.deb and .rpm). It's a graphical front end to the same OpenCode engine as the terminal UI.

  • Who it's for: People who aren't comfortable in the terminal but want a full coding agent.

  • What you get: Sessions, agent switching, and diff and log views in a regular app window.

  • Under the hood: The desktop app uses the same permission rules, AGENTS.md and config as the terminal interface.

  • Expect change: OpenCode moves fast, and OpenCode 2 is rolling out alongside version 1 (both use the opencode command). Check which version your install method gives you and read the release notes before updating.

A laptop showing an application with several tabs and a code diff view, similar to reviewing an AI agent's changes in a desktop app.

Using OpenCode from your IDE and editor

OpenCode IDE extensions connect your editor to the OpenCode server, bringing the agent into your existing workflow.

  • How it works: The extension drives OpenCode through its server, so you can prompt the agent and review its changes without leaving the editor.

  • Agent vs. completion: Inline completion tools (like Copilot) focus on single-line or single-block suggestions. OpenCode focuses on multi-step changes, plans, and repo-wide context. They complement each other rather than compete.

  • Same project, same rules: The extension uses the same AGENTS.md, config and permissions as the terminal.

  • Typical use cases: Editing files, running tests, inspecting diffs, and reviewing coding agent suggestions inside the editor. For larger refactors, the terminal UI or desktop app may be more practical.

Choose the interface that matches your habits. The underlying agent configuration stays the same regardless of which front end you use.

Subagents, MCP, and automation patterns

OpenCode supports extensibility through subagents and MCP (Model Context Protocol) servers.

  • Subagents: Specialized agents with their own model, prompt and permissions, defined in opencode.json or as Markdown files. Useful for code review, documentation lookup or broad codebase scans. The main agent can hand tasks to them in child sessions.

  • Custom agents: You can create custom agents with restricted tool permissions, different models, and tailored prompts. A documentation agent might only have read access; a test agent might run shell commands but not edit source files.

  • MCP servers: External tools and services the agent can call, configured in opencode.json and governed by the same permission system.

  • Automation: Use opencode run, the SDK or the HTTP API for scripted jobs like code scans or dependency bumps. Set tight permissions and keep a human review step before anything merges.

More automation means more responsibility for guardrails. Subagents and MCP add a lot of reach, but without careful configuration, they can create noise or make unwanted changes.

OpenCode pricing: free client, paid models

OpenCode itself is free, open-source software. You don't pay a license fee to download or run it, and it ships with a set of free models you can try without an account. Costs come from the models you connect.

Here's how costs work as of October 2026, from OpenCode's Go page and site:

Component

Cost

OpenCode client (CLI, desktop, IDE)

Free (MIT license)

Cloud model usage (OpenAI, Anthropic, etc.)

Per-provider token billing

OpenCode Go subscription

$10 per month

OpenCode Go Plus subscription

$40 per month

OpenCode Zen

OpenCode Zen

Pay-as-you-go, price depends on the model

Local models (Ollama, LM Studio)

Free (you pay hardware/electricity)

  • Provider costs: Using your own API keys means paying that provider's standard rates per token. Logging in with a Copilot or ChatGPT plan uses that plan's limits.

  • Go and Go Plus: Subscriptions to a curated lineup of lower-cost coding models with usage limits per 5 hours, per week and per month. You can top up credit and cancel any time, and Go also works with other coding agents.

  • Local models: No API fees, but you pay in hardware, electricity and setup time.

Cost control habits and "free isn't free"

Local models avoid API fees but still cost hardware, electricity and maintenance time. "Free" has a cost.

Cost-saving tactics:

  • Use cheaper models for exploration and planning. Reserve expensive, high-quality models for final code generation and complex reasoning.

  • Keep prompts and context focused. Avoid loading entire monorepos into context. Only reference the files you actually need.

  • Limit context space where possible. Avoid dumping large files or too many file references at once.

  • In permission rules, block or prompt before resource-intensive tools (full test suites, heavy shell commands, wide searches).

  • Set preferred models in opencode.json and give each agent an appropriate model, so expensive models are only used where they earn their keep.

Set rules in AGENTS.md:

Add explicit guidance for when the coding agent may run expensive operations. Example: "Only run full test suite after confirming individual module tests pass." This saves provider tokens and keeps costs predictable.

Periodic review:

Check your usage dashboards regularly. If a provider's limits or prices change, you can switch without rebuilding your workflow, which is the point of model-agnostic tooling.

OpenCode vs. Claude Code and other AI coding agents

Here's how OpenCode compares with Claude Code and editor-first tools. Agentdex is independent and not affiliated with any of these vendors; the aim is to show trade-offs, not crown a winner.

Key differences:

Axis

OpenCode

Claude Code

Editor-first tools

License

MIT (open source)

Proprietary

Varies

Model choice

75+ providers, including local

Anthropic's Claude models (directly or via supported cloud providers)

Varies by tool

Interfaces

Terminal, desktop app, IDE, web

Terminal, IDE extensions, desktop app, web

The editor itself

Repository context

AGENTS.md, full repo

CLAUDE.md, full repo

Indexing, rules files, @-mentions

Billing

Own API keys, Copilot/ChatGPT logins, Zen, Go, or free models

Paid Claude plan or Anthropic API key

Subscription, often with usage-based extras

Permissions

Configurable allow/deny/ask

Built-in permission modes and settings

Varies

OpenCode is a bring-your-own-model tool. Claude Code is built around Anthropic's models and plans. Editor-first tools like Cursor have their own model menus, billing and UI.

OpenCode vs. Claude Code

Claude Code is tightly integrated with Anthropic's models and plans, and it is included in paid Claude plans (Pro is $20/month, or $17/month billed annually). It gives a polished experience if you're committed to Anthropic. OpenCode can switch between Anthropic and many other providers.

Both understand repository context, run shell commands and support MCP servers. They differ in model choice, billing (a Claude plan or API key vs any provider) and openness (proprietary vs MIT-licensed).

Because Claude Pro and Max logins only work in Anthropic's own apps, using Claude in OpenCode means an API key and per-token billing. If you mostly use Claude, weigh Claude Code's convenience and plan pricing against OpenCode's flexibility and extra setup. See our Claude Code pricing guide for current plan details.

OpenCode vs. editor-first tools (Cursor, etc.)

Cursor is an AI-first code editor with inline completions, chat and agents. It's lighter for quick, in-file edits because the AI lives where you type.

OpenCode's terminal-first design focuses on plan-and-build workflows across the repo. It suits structured, repeatable agent work: multi-file refactors, scripted automation and plan-driven feature development.

Mixing is common: an editor tool for small changes and OpenCode for larger refactors or scripted jobs. For a wider comparison, see our guide to the best AI coding assistants.

OpenCode for teams comparing models on the same project

One practical strength of OpenCode is fair model comparison within a single project.

  • Same context, different models: Use the same AGENTS.md, same project instructions, same repository context, but configure different models per agent. Run the same task against each, then compare diffs, run times, and test outcomes.

  • Concrete patterns: Create a Plan agent using a cheaper model and a Build agent using a stronger model. Or create parallel Build agents with different providers. Evaluate which model handles your stack best, where local models break down, and where expensive models aren't worth the premium.

  • Log findings: Feed results back into AGENTS.md. Note which model handles TypeScript refactors well, which one struggles with your test framework, which one produces clean diffs vs. noisy ones.

The best model depends on your codebase, budget and tolerance for oversight, so test on your own work rather than trusting leaderboards alone.

OpenCode for automation builders and scripting

Automation-focused developers can script OpenCode with opencode run, its SDK or the HTTP API.

Example automations:

  • Scheduled code scans that check for TODOs, deprecated API usage, or security vulnerabilities, then open PR-ready patches.

  • Automated PR generation for dependency bumps: let the coding agent update packages, run tests, and generate a diff for review.

  • CI bots that call OpenCode with controlled permissions to lint, format, or refactor code as part of a pipeline.

Guardrails matter:

When using OpenCode in CI/CD pipelines, set tight permission rules. Deny destructive commands. Require human approval for merges. Audit logs for every change. A coding agent running unattended with broad permissions is a recipe for surprises.

Blending with existing stacks:

OpenCode doesn't replace your bash, Python or Node scripts. Use your existing scripts for orchestration and OpenCode for the parts that benefit from AI: understanding code, proposing changes, writing tests.

Getting started with OpenCode in practice

Here's a realistic "day one" flow for getting started.

  1. Install OpenCode. Use the install script (curl -fsSL https://opencode.ai/install | bash), npm, Homebrew, or the desktop app. On Windows, OpenCode recommends WSL; Scoop and Chocolatey also work.

  2. Select a model provider. Run /connect. Try the free models, sign in to Zen, add an API key, log in with Copilot or ChatGPT, or point it at a local model.

  3. Initialize a project. Open a small personal project, run opencode, then /init to generate AGENTS.md.

  4. Run your first task. Start in Plan mode. Ask the coding agent to explain the project's structure or suggest a small improvement. Review the plan. Switch to Build. Review the diff.

  5. Iterate. Try different models. Edit AGENTS.md to improve instructions. Experiment with permissions.

A workstation with a monitor, keyboard and a terminal window open, ready for a first session with a coding agent.

Platform notes:

  • macOS and Linux: the install script or Homebrew.

  • Windows: WSL is recommended for the terminal version; the desktop app runs natively.

  • Paid models aren't included in the install. You choose providers and models separately.

Start small. A side project or personal repo is ideal for learning. Don't point OpenCode at your production monorepo on day one.

Who OpenCode is (and isn't) for

Ideal users:

  • Developers who want control over model choice and don't want to be locked to one provider.

  • Indie hackers who like to self-host and value transparency.

  • Teams hedging against vendor changes, API pricing shifts, or access rules that shift unexpectedly.

  • Tinkerers building coding agent automations, custom agents, and scripted workflows.

Who might prefer alternatives:

  • People who want zero-configuration, opinionated cloud tools. Claude Code or Cursor are faster to start.

  • Developers who don't care about model selection and are happy with a single provider.

  • Teams that need enterprise support contracts and SLAs that open-source projects typically don't provide.

OpenCode needs more setup and configuration than turnkey tools. It pays off in flexibility, portability and cost control. If you want to open a tab and start coding with no setup, it's probably not your first choice.

If you're still weighing options, the Vibe Coder Starter Kit includes starter rules and checklists that work across agents.

The future of OpenCode and ecosystem trends

OpenCode ships frequently, and OpenCode 2 is now rolling out next to version 1. Check the changelog before upgrading a setup you depend on.

  • No guaranteed roadmap. Priorities shift with new models, platform changes and community feedback. Breaking changes are possible.

  • Broader trends: More coding agents, richer repository context, wider adoption of MCP, closer IDE integration, and shared instruction files like AGENTS.md working across tools.

  • Context engineering is maturing. How teams use AGENTS.md and similar instruction files to standardize agent behavior is becoming a discipline of its own, not just a nice-to-have.

  • Community: Being open source means anyone can file issues, submit pull requests and add provider integrations.

Follow OpenCode's GitHub, docs and changelog for current changes, and subscribe to Model Pulse for a daily round-up of tool and model updates.

Model Pulse

Daily AI model drops, tools, and what they mean for AI coders.

FAQ

These FAQs address practical questions not fully covered above, focusing on installation, security, and model choice.

Is OpenCode safe to run on private repositories?

OpenCode says it doesn't store your code or context data, except when you use its free models. Your code still goes to whichever model provider you connect, so that provider's retention policy matters. Configure permissions carefully, especially for shell commands.

Keep the server on localhost, set OPENCODE_SERVER_PASSWORD if you run it as a server, and don't share sessions that contain sensitive code. OpenCode's permissions are a safety net, not a hardened sandbox, so treat it like any tool that can run commands on your machine.

Can I use multiple models in the same OpenCode project?

Yes. You can configure different providers and models per agent or subagent within the same project context. This lets you mix fast, inexpensive models for exploration with stronger, slower models for final code edits or complex reasoning.

Switching models doesn't require reinstalling anything. Change it in opencode.json or the model picker, and note preferred models per task in AGENTS.md so teammates stay consistent. A common pattern: a cheaper model for planning and a stronger model for building.

How does OpenCode compare to using ChatGPT or Claude in the browser?

Browser chat tools are fine for quick questions but can't see your repository, run your tests or undo file changes. OpenCode is an agent with direct access to files and commands, plus persistent project context through AGENTS.md.

You can use the same underlying models, but OpenCode adds tools, automation and local control on top. The trade-off is setup time compared with opening a browser tab.

Do I need to know the terminal to use OpenCode?

It helps but isn't required. The desktop app and IDE extensions cover most common tasks, so beginners can start there and pick up terminal commands over time.

Advanced features like scripting, CI use and custom agents assume some command-line comfort. You don't need to be a shell expert to start.

Is OpenCode free?

Yes, the software is free and MIT-licensed, and it includes some free models. You pay for other models: either your provider's API rates, OpenCode Zen's pay-as-you-go prices, or a Go ($10/month) or Go Plus ($40/month) subscription, as of October 2026.

Written by Agentdex Editorial. Agentdex is an independent directory reviewing AI coding tools; we are not affiliated with the companies mentioned. Prices and features are as of October 23, 2026, from official sources linked above. Always confirm on the vendor's site.