Complete Guide to OpenCode (2026)

Published Updated

OpenCode sits beside your editor rather than trying to replace it. That makes it a different kind of AI coding tool: one terminal agent can work with VS Code, Neovim, JetBrains, or Emacs, and you can swap model providers without rebuilding your daily setup.

That freedom sounds abstract until a provider shifts a price, access rule, or model list. OpenCode keeps the editor, model, and agent separate, so you can move one part without throwing out the rest of the way you work.

DecisionOpenCode AnswerBest Fit
Working styleTerminal-first agent beside your editorDevelopers who already use CLI tools
CostFree tool; model costs varyPeople willing to choose their own cost route
PrivacyLocal inference through Ollama is availableCode that must stay on controlled hardware
Model choice75+ providers plus local modelsWorkflows that cannot rely on one vendor
Main trade-offMore setup, no inline autocompleteDevelopers who value control over polish

What OpenCode Actually Is

OpenCode's documentation describes an open-source AI coding agent available through a terminal interface, desktop app, and IDE extension. This overview focuses on the terminal workflow because that is where its provider flexibility and remote-work fit are easiest to see.

OpenCode reads project files, proposes edits, runs approved commands, and writes those edits back to the same repository your editor has open. OpenCode leaves inline autocomplete to a separate editor tool. Pair it with Copilot if you want ghost-text suggestions, or use Cursor when the editor and agent should be one product.

That separation is the main reason to choose OpenCode. Your editor can be VS Code, Neovim, JetBrains, or Emacs, while the model behind OpenCode can vary by task. The configuration stays in readable files, and the agent remains usable when a provider alters its price, access rules, or model lineup.

That portability matters most on mixed projects. The same terminal workflow can follow you from a local repository to a remote SSH session, while the editor and model vary around it.

Getting Started

Install OpenCode from its official site, open a project directory, connect an approved provider, and use Plan mode before allowing an edit. Read the proposed file list and command before approval.

The advanced OpenCode guide owns the setup files, provider connection, permissions, and first-task loop. Use a known module or failing test for the initial trial and run the focused check yourself.

Permissions That Match the Task

OpenCode's permission system can allow, ask, or deny individual tool classes. The documented keys cover reading, editing, search, shell commands, subagents, external directories, web access, language-server tools, and skills. A permission can also use file or command patterns, so the boundary can be narrower than "shell on" or "shell off."

Start from the task, then grant only what it needs:

  • A review agent can read, search, and use the language server while edits and shell commands stay denied.
  • A test repair can allow edits in test files and ask before the focused test command runs.
  • A documentation task can deny package managers, deployment commands, and access outside the repository.
  • A normal coding agent can ask before edits and shell commands until its plan matches the requested scope.

The approval prompt is useful only when you read it. Check the full command, working directory, and affected path before allowing a shell action. A safe-looking test command can still call a project script that resets data or rewrites generated files. Put permanent team restrictions in configuration and keep one-off boundaries in the task itself.

OpenCode also exposes a doom_loop permission for recovery prompts when an agent appears stuck. Do not treat recovery as proof that the next attempt is better. Repeated edits to the same file or repeated failures from the same command usually mean the task needs a smaller scope, a different model, or a human decision.

Models and Cost

OpenCode works with more than 75 providers through Models.dev, including direct vendor APIs, OpenCode's own plans, and local models. That range is useful only when you choose a cost path deliberately.

The provider page was checked July 28, 2026. It describes connection options, not a single shared data policy or allowance. A direct API account keeps billing and retention with its vendor, while an OpenCode-managed route adds another service layer. Record the provider, selected model, and account owner in the project decision before a task receives client code.

  • Bring your own API credential for direct billing and the provider's current model catalog. Cost rises with token use, so set provider-side limits before long agent sessions.
  • OpenCode Zen is the optional pay-as-you-go gateway for models the OpenCode team has tested with the agent.
  • OpenCode Go costs $5 for the first month and then $10 monthly. Its July lineup includes Kimi K3 and GLM-5.2, with dollar-based usage limits rather than unlimited requests.
  • Local Ollama removes the per-token API bill. Hardware, electricity, speed, and model quality become the constraints instead.

The July open-model story is moving quickly. Moonshot launched Kimi K3 on July 16 as a 2.8-trillion-parameter MoE flagship with a 1-million-token context, aimed at long engineering sessions and large repositories. OpenCode Go now lists it with a temporary 2x usage allowance.

Z.ai released GLM-5.2 on June 16 for the same long-horizon engineering class. Its official model card reports 753 billion parameters, a 1-million-token context, and an MIT license. The full hardware and availability analysis lives in the OpenCode local-model guide.

Choosing a Provider Route

Direct provider access is easiest to audit when your organization already has an approved vendor account. Billing, retention terms, model availability, and spend controls remain with that provider. The trade is administrative duplication if you want several vendors, because each credential and policy needs its own owner.

OpenCode Zen offers a curated pay-as-you-go route, while OpenCode Go offers a small subscription around selected open models. These reduce provider setup, but they add OpenCode's service layer between the agent and the model host. Read the current retention and billing terms before sending client code.

Local Ollama replaces the hosted inference account with hardware and operating costs. Check whether the model fits available RAM or VRAM, how quickly it completes a representative task, and whether its tool use is reliable enough for edits.

A smaller model that finishes a focused test repair can be more useful than a large model that swaps into memory and stalls.

Keep a fallback model in the configuration only when you understand what changes with the switch. A second provider may have different data terms, tool support, context limits, or model names. Silent failover can cross a policy boundary even when the generated code looks the same.

Compare providers with one repository task that has an objective result. A useful candidate is a failing unit test whose fix touches one implementation file and one test file. Give each model the same AGENTS.md, permissions, prompt, and command. Compare the returned diff, the number of retries, the test result, and the billed usage.

Judge the model by whether it finds the relevant code, stays inside the boundary, and gives you a result you can verify. Long explanations and large patches carry no extra credit. If two providers perform similarly, retention terms, cost controls, and reliability should settle the choice.

Keep the comparison reproducible. Use the same repository revision, AGENTS.md, permission profile, prompt, and focused check for each provider. Record an unavailable model or a rejected command as a result rather than changing the setup until one provider succeeds. That preserves the difference between model capability, permissions, and a broken credential.

Privacy

OpenCode's privacy properties come from the provider you select. A direct cloud API sends the prompt and relevant code to that provider. OpenCode Go says its hosting partners follow zero-retention policies and do not train on customer data, which remains a policy claim you must evaluate against your requirements.

Ollama can keep model inference on your machine, but "local" does not disable every network path. Web search, remote MCP servers, package managers, Git hosting, and a second cloud provider can still send data elsewhere. Review the whole tool configuration before treating a session as offline or suitable for regulated code.

A local-model claim should therefore start with a network map, not a product name. Disable or account for web tools and remote MCP servers, inspect Git remotes and package registries, and confirm that the selected provider is the local endpoint. The local-model guide covers the hardware and configuration path; this overview keeps the decision focused on where the data travels.

Provider Ownership Is a Team Decision

Provider flexibility does not remove ownership. Someone still needs to approve credentials, set a spend cap, review retention terms, and decide whether a fallback model can receive the same code. OpenCode makes those choices visible in configuration, which is useful only when the team is prepared to maintain them.

Use OpenCode's permission documentation, to define the boundary in the agent configuration. A project can allow read and search access while asking before edits or shell commands. That split supports a review task without granting the same reach as an implementation task.

Review the effective permission set after configuration changes, not only the task prompt.

Configuration determines the agent's actual reach.

Task text cannot override a broader configuration.

Review the configuration before every task class.

A practical privacy review follows the data instead of the product label:

  • Identify the active model provider and where its credential is stored.
  • List every enabled MCP server, web tool, package registry, and Git remote.
  • Check whether logs, prompts, or task traces are retained outside the repository.
  • Run a network-isolated test if the requirement is genuinely offline operation.

Limits and Trade-Offs

OpenCode asks you to understand providers, usage limits, permissions, and model hardware. Inline completion still needs a separate editor tool, and provider behaviour varies. Model-specific tool calling, authentication, rate limits, and error messages remain part of the daily workflow.

Provider flexibility also creates more support work. A team must decide which model combinations are approved, who owns credentials, how costs are capped, and what happens when a provider removes a model. Open configuration makes those decisions inspectable while leaving the support work with the team.

OpenCode Verdict

OpenCode accepts more setup in return for provider choice, readable configuration, remote work over SSH, and a route to local inference. That trade-off is justified when model access, data location, or vendor dependence is an active requirement; otherwise an integrated editor or a first-party terminal agent reduces the operating burden.

FAQ

Is OpenCode free?

OpenCode itself is open source and free to install. Your model can still cost money: direct provider APIs and OpenCode Zen charge for usage, while OpenCode Go costs $5 for the first month and then $10 monthly. A local Ollama model has no per-token API charge.

Can OpenCode run local models with Ollama?

OpenCode can use local models through Ollama. Its provider documentation includes a local configuration using Ollama's OpenAI-compatible endpoint at localhost. Ollama handles inference on your machine, and OpenCode remains the agent interface. Model size still has to fit your hardware, and other enabled tools or providers can create separate network traffic.

OpenCode vs Claude Code: when does each fit?

OpenCode separates the agent layer from its provider and can use local inference. Claude Code is Anthropic's first-party terminal workflow. Compare the provider, data path, configuration burden, and review controls for the repository in scope.

Which open models work best with OpenCode in 2026?

GLM-5.2 is a strong choice for long engineering work, with a 1-million-token context and MIT-licensed weights. Kimi K3 is the newer 2.8-trillion-parameter option available through OpenCode Go. For Ollama on one workstation, use a smaller quantized coding model that fits your RAM or VRAM instead of either datacenter-scale flagship.

Do I need API credentials to use OpenCode?

You need credentials for whichever hosted provider you choose. Direct Anthropic, OpenAI, Google, Moonshot, or Z.ai access uses that vendor's credential; Go and Zen issue OpenCode credentials after signup. A local Ollama setup can run without an external model-provider credential, which is the cleanest zero-credential path.

Compare OpenCode

More on OpenCode

Read OpenCode local models with Ollama for hardware, current open models, and the privacy boundary. Read advanced OpenCode agents and automation for permissions, MCP servers, custom agents, and bounded long-running loops.

Read running many OpenCode sessions at once for worktree isolation, remote clients, and headless scripting. Read OpenCode for regulated and enterprise teams for the outbound-path map, self-hosting, and what procurement will ask for.

This July 2026 update uses facts checked against official vendor sources on July 27, 2026.

Sources

  1. [1]
  2. [2]
  3. [3]
  4. [4]
    OpenCode Go plan
    (opencode.ai)
  5. [5]
  6. [6]
    Ollama documentation
    (docs.ollama.com)
  7. [7]
  8. [8]
  9. [9]
  10. [10]
  11. [11]
    OpenCode providers
    (opencode.ai)
  12. [12]
  13. [13]
  14. [14]
  15. [15]
    GLM-5.2 model card
    (huggingface.co)