Verdict: OpenCode is the best fit for developers who want the model to be a replaceable component rather than the identity of their coding agent. Its MIT-licensed core, provider breadth, local-model support and inspectable client/server design are real advantages. In audited fixed-model results, it was competitive: 34 of 42 matched GPT-5.6 Sol task-trials and 26 of 37 matched DeepSeek V4 Flash task-trials. It was not the undisputed winner in either bundle, and none of its pairwise differences was statistically significant.
That is the point. OpenCode makes it easier to change the model, provider and interface without changing the entire operating model. It does not make harness effects disappear.
Choose OpenCode if portability, an open runtime and automation surfaces matter enough that you will harden its configuration. Stay with Claude Code or Codex if you prefer a more integrated model-and-harness product with stronger isolation options and less configuration work. For sensitive repositories, OpenCode can be suitable only after an explicit security review: disable public sharing, restrict provider and tool access, change permissive defaults, and add an operating-system or container sandbox. OpenCode’s own permissions are policy checks, not OS isolation.
The flexibility has measurable value as optionality, not as a universal performance or cost advantage. Public evidence shows that rankings change when the model changes. It does not show that OpenCode is always cheaper after failures, retries and provider pricing are counted.
Testing disclosure: This review source-audited current documentation, tagged code, raw benchmark files and primary research on August 16, 2026. We also installed OpenCode 1.18.18 locally and performed a credential-free smoke test in a synthetic repository. We did not provide a model key, run paid inference, upload a repository, measure code-generation quality, test undo after an AI edit, or publish a session. Performance conclusions therefore come from audited public evidence, not an original Kingy benchmark.
What OpenCode is—and what it is not
OpenCode is an agent harness: the runtime between a language model and a working repository. It selects context, exposes tools, applies permission rules, persists sessions, coordinates agents and presents the experience through terminal, desktop, IDE and programmable interfaces. The official documentation supports installation by shell script, JavaScript package managers, Homebrew, Arch Linux, Chocolatey, Scoop, Mise and Docker; it recommends WSL for Windows terminal use. The GitHub repository is MIT-licensed and active, while the audited stable release was v1.18.18, published August 13, 2026.
It is not a foundation model and it is not proof that every supported model will work equally well. OpenCode routes to more than 75 providers through the AI SDK and Models.dev, supports custom endpoints and can use local models, according to its provider documentation. That breadth increases choice. It also increases the number of model, endpoint and tool-behavior combinations a team may need to validate.
Nor is “open source” the same as “self-contained.” A local OpenCode process still sends prompts and selected repository context to whichever remote model provider the user configures. Optional OpenCode services add another boundary: Zen is a pay-as-you-go model gateway; Go is a subscription; and public session sharing uploads conversation data to OpenCode’s service. Enterprise deployments can centralize configuration and route to internal gateways, but OpenCode’s own share service was described as a self-hosting roadmap item in the enterprise documentation at retrieval time.
OpenCode specification, verified August 16, 2026
| Item | Verified state |
|---|---|
| Stable release | 1.18.18, August 13, 2026 |
| License | MIT |
| Main surfaces | Terminal UI, desktop app, IDE/ACP integrations, web/server, GitHub and GitLab workflows |
| Installation | Shell installer; npm, Bun, pnpm, Yarn; Homebrew; Arch; Chocolatey; Scoop; Mise; Docker |
| Providers | 75+ via AI SDK/Models.dev; custom base URLs; local-model support |
| Built-in runtime | File read/write/edit, shell, search/glob, web fetch/search, task agents, LSP integration, patching and planning tools |
| Architecture | Local client/server; HTTP API; OpenAPI 3.1 document at /doc; generated JavaScript/TypeScript SDK |
| Agents | Build and Plan primary agents; general-purpose and exploration subagents; configurable custom agents and child sessions |
| Context | Session persistence, compaction and summarization; project instructions; agent skills |
| Compatibility | AGENTS.md, CLAUDE.md, Agent Skills, MCP, plugins, custom tools, commands, formatters and ACP |
| LSP default | Disabled until lsp: true or an LSP configuration is supplied |
| Headless use | opencode run, server mode and CI integrations |
| Permission default | Mostly allow; selected operations ask; .env reads restricted by default |
| OS sandbox | None built into the OpenCode permission layer |
| Local storage | Sessions and related data persisted locally; credentials stored under OpenCode’s local data directory |
| Sharing | Manual by default; public link accessible to anyone with the URL until unshared |
Sources: OpenCode introduction, providers, tools, agents, server, LSP, permissions and sharing.
Architecture: the model is a cartridge; the harness is the machine
The cleanest way to understand OpenCode is as five layers.
- Model and provider. The model proposes actions. The provider determines availability, price, retention and rate limits. OpenCode can route to a direct provider, its Zen gateway, a subscription-backed service or a compatible local endpoint.
- Harness. OpenCode builds prompts, selects tools, manages turns, compacts context, persists sessions and coordinates primary agents and subagents.
- Tools. File operations, patches, shell commands, searches, web access, MCP servers, custom tools and language services convert a text proposal into effects.
- Workspace. The repository, configuration and project instructions define what the agent can see and how it should behave.
- Guardrails. OpenCode permission rules can allow, deny or ask before a tool action. Provider policy, credentials, network controls and an external OS/container sandbox must protect the boundaries that the harness does not.
This separation is OpenCode’s strongest design decision. Its server mode exposes an OpenAPI 3.1 interface and the terminal UI acts as a client. That makes alternative clients, automation and integrations easier to build than in a monolithic terminal loop. The JavaScript/TypeScript SDK is generated from the same server surface. An optional HTTP basic-auth password can protect the server; without it, a local server can start unauthenticated, so it should not be bound to an untrusted interface.
The same modularity applies inside a session. Build and Plan are primary modes, with general-purpose and exploration agents available for delegated work. Project rules can come from AGENTS.md; compatibility layers also recognize CLAUDE.md and Agent Skills. MCP, plugins, custom tools, slash commands and formatters extend the action space. ACP connects editor clients. LSP supplies diagnostics and code intelligence—but the current LSP page says it is disabled by default. Any homepage wording that implies LSP is simply present should be read as capability, not default activation.
Model replacement is therefore technically real, but it is not frictionless. A model must still support the provider’s tool-call format, context size and required modalities. Some inexpensive or local models will be weaker at structured tool use, long-horizon recovery or precise patches. A long provider list is not evidence of feature parity.
What we observed locally—and what we did not test
We downloaded the official macOS arm64 asset for v1.18.18 and ran it with isolated XDG data, config and cache directories against a synthetic repository. The compressed download was about 44 MB and the extracted executable about 137 MB. opencode --version returned 1.18.18.
The command surface included the terminal UI, run, serve, web, model listing, session import/export, MCP and GitHub operations. A local server reported version 1.18.18 at its health endpoint and exposed an OpenAPI 3.1 document with 162 paths. We created and exported a local session with zero model calls, zero tokens and zero cost. Session state was stored in a local SQLite database. No session was shared.
The default-agent debug output matters more than the command count. It showed broad tool access and a general allow posture, with special handling for endless-loop detection, access outside the workspace and environment files. OpenCode’s documentation similarly says most permissions default to allow. The --auto flag was explicitly marked dangerous because it auto-approves prompts. Plan mode prevented edits in our inspection, but its debug representation did not justify treating the name “Plan” as an isolation boundary. Teams should enforce explicit deny/ask rules instead of relying on mode labels.
The local LSP endpoint was empty under the default configuration, matching the current documentation: code intelligence is available, not on by default. We did not configure a language server, so this is not a latency or quality test of LSP support.
We also did not test model-generated edits, AI-assisted undo, compaction quality, multi-agent correctness, provider failover or rate-limit behavior. Those require model access and introduce cost. A controlled original comparison would need accounts for every selected provider, identical model snapshots, at least 30–50 independent task-trials per harness, frozen repositories, deterministic test oracles and a budget that covers failures and retries. No such spend was authorized.
What OpenCode’s own benchmark actually establishes
The anomalyco/opencode-bench repository presents a useful benchmark prototype, not evidence that OpenCode beats rival agents.
The README describes a rigorous evaluation with three episodes and a 30-minute timeout. The audited evaluation code, however, used a 20-minute default and ran one episode per invocation; the CLI did not implement the promised three-episode loop. The public results file contained one result: one OpenCode plus GPT-5 Codex run on one task, with a score of roughly 0.123. There was no comparative leaderboard to audit.
Its scoring design combines three LLM judges—Claude, GPT-5 Codex and Kimi—across five binary dimensions, then applies a variance penalty. That is a thoughtful attempt to reduce single-judge dependence, but binary model judgments are not deterministic test oracles. The authors’ own benchmark observations record judge disagreement, instability caused by re-derived diffs and skipped scoring when no diff appeared.
There is also a harness-parity problem. The OpenCode adapter grants permissive access and automatically creates a public share URL, while the Codex adapter runs in a workspace-write sandbox. That changes both the action boundary and the data path. A harness comparison must hold those conditions steady or treat them as product-default differences.
The honest conclusion is narrow: OpenCode’s repository documents an intended evaluation framework and several known failure modes. Its published data does not establish superiority, average performance or reliability.
Independent fixed-model evidence
The strongest public evidence we found was OpenBench’s sealed raw JSONL, because it evaluates several harnesses with the same named model inside each release bundle. We independently parsed the raw rows, applied the release’s checker-owned verdict and starved-output classification, formed matched task-trial intersections and recomputed Wilson 95% confidence intervals and exact two-sided McNemar tests.
GPT-5.6 Sol product-harness bundle
This release used 15 tasks with three trials each and a declared 2,400-second cap. The release contained 315 rows across seven harnesses. Exact version stamps were OpenCode 1.18.3, Claude Code 2.1.214, Codex 0.144.5, Pi 0.80.10, Grok 0.2.103 and Devin 3000.2.17; Cursor did not report a CLI version. OpenCode and Cursor reported native/hosted token telemetry, while several other harnesses used proxy-metered telemetry. The strict all-harness matched intersection was 42 task-trials, not the nominal 45.
| Harness | Solved / matched | Solve rate | Wilson 95% CI | Exact McNemar vs OpenCode |
|---|---|---|---|---|
| Cursor Agent | 36 / 42 | 85.7% | 72.2–93.3% | p = 0.625 |
| OpenCode | 34 / 42 | 81.0% | 66.7–90.0% | Reference |
| Grokbuild | 34 / 42 | 81.0% | 66.7–90.0% | p = 1.000 |
| Devin | 34 / 42 | 81.0% | 66.7–90.0% | p = 1.000 |
| Claude Code | 32 / 42 | 76.2% | 61.5–86.5% | p = 0.625 |
| Pi | 32 / 42 | 76.2% | 61.5–86.5% | p = 0.625 |
| Codex CLI | 31 / 42 | 73.8% | 58.9–84.7% | p = 0.250 |
Source: OpenBench GPT-5.6 release, raw JSONL and provenance manifest, retrieved August 16, 2026.
OpenCode is competitive here, but “second place” would overstate what 42 matched cells can tell us. Every interval overlaps, and no pairwise test against OpenCode reaches the conventional 0.05 threshold. Cursor’s numeric lead is six percentage points, not a statistically established advantage in this sample.
DeepSeek V4 Flash product-harness bundle
The DeepSeek release used 15 tasks and three trials, with five harnesses and 225 raw rows. Its methodology states a 1,200-second cap, although archived result rows did not consistently carry a timeout value and OpenCode rows included mixed 1.17.15/1.17.18 version stamps. All compared harnesses used proxy-metered token telemetry. The strict matched intersection was 37 task-trials.
| Harness | Solved / matched | Solve rate | Wilson 95% CI | Exact McNemar vs OpenCode |
|---|---|---|---|---|
| Claude Code | 30 / 37 | 81.1% | 65.8–90.5% | p = 0.125 |
| Pi | 28 / 37 | 75.7% | 59.9–86.6% | p = 0.688 |
| OpenCode | 26 / 37 | 70.3% | 54.2–82.5% | Reference |
| Grokbuild | 25 / 37 | 67.6% | 51.5–80.4% | p = 1.000 |
| Codex CLI | 24 / 37 | 64.9% | 48.8–78.2% | p = 0.688 |
Source: OpenBench DeepSeek release, raw JSONL and provenance manifest, retrieved August 16, 2026.
OpenCode moved from a numeric tie near the top in the GPT bundle to the middle with DeepSeek. Claude moved the other way. The intervals still overlap and no OpenCode comparison is statistically significant, so this is evidence of interaction worth investigating, not proof of a stable ordering.
Why can the same harness rank differently? Models differ in tool-call reliability, prompt sensitivity, context use, willingness to inspect files, recovery behavior and patch style. Harnesses choose prompts, tool schemas, observations and retry policies. The outcome belongs to the model–harness pair. Recent primary research reinforces that view: Harness-Bench treats the pair as the unit of comparison, while The Scaffold Effect reports material token-efficiency differences when models are held fixed across harnesses, even when pass-rate differences are modest.
Important caveats remain. These are separate OpenBench releases, not one randomized crossover experiment; task fingerprints and telemetry bases differ. A release seal proves that a file matches its manifest. It does not prove the sample was not selected, recreate private transcripts or validate every hosted environment. Running the current repository verifier reproduced the result-file hashes and schemas but also found task-tree drift relative to the archived fingerprints. That is a reproducibility warning, not evidence that the published JSONL was altered.
OpenCode versus Claude Code, Codex CLI, Gemini CLI, Aider and OpenHands
No single product dominates every layer. The practical choice is which constraints you want the harness to own.
| Harness | Source and portability | Guardrails | Best fit |
|---|---|---|---|
| OpenCode | MIT; broad provider/local-model support; terminal, desktop, IDE and server | Mostly-allow permission defaults; no built-in OS sandbox | Developers and teams that prize model optionality and will harden policy |
| Claude Code | Public source under restrictive commercial terms; centered on Anthropic models | Tool approval rules plus optional OS-level Bash sandboxing | Claude-first teams wanting a cohesive, mature workflow |
| Codex CLI | Apache-2.0; centered on OpenAI models; CLI, IDE, desktop/cloud ecosystem | Platform-native sandbox plus approval policies | OpenAI-first users wanting conservative local execution boundaries and cloud handoff |
| Gemini CLI | Apache-2.0; Gemini-centered but extensible; terminal/headless/IDE | Approval modes plus Seatbelt, container and other sandbox options | Google/Gemini users and extension-heavy terminal workflows |
| Aider | Apache-2.0; many providers/local models | Git-centric changes and commands, but not a comparable OS isolation layer | Focused pair programming with strong repo-map and edit-format workflows |
| OpenHands | MIT; model-flexible; CLI, GUI, web, ACP and self-hosted control plane | Docker/remote sandbox architecture; process mode explicitly unsafe | Teams needing a heavier multi-user agent platform or isolated runtimes |
Claude Code is OpenCode’s closest premium workflow competitor. It spans terminal, IDE, desktop, web, remote execution and CI; supports CLAUDE.md, skills, MCP, hooks and subagents; and offers managed organization settings. Its permissions system can be combined with OS-level sandboxing for Bash filesystem and network isolation. The trade-off is model lock-in and a source-available repository governed by commercial terms, not an OSI open-source license.
Codex CLI is Apache-2.0 and also exposes a scriptable SDK, MCP, AGENTS.md, non-interactive operation and multiple user surfaces. Its main advantage for risk-sensitive local use is the separation between approval policy and a platform-native sandbox. Codex remains model-family-specific, however. OpenCode is the better abstraction if switching among OpenAI, Anthropic, Google, open-weight and local endpoints is a core requirement.
Gemini CLI is Apache-2.0, supports terminal, headless JSON output, IDE integration, MCP, extensions, hooks, skills and experimental subagents. Its sandbox options include macOS Seatbelt and container-based isolation. It is an appealing open client for Gemini-centered work; OpenCode offers broader provider neutrality and a more explicit server/API product shape.
Aider is the focused instrument in this group. Its provider support, repository map, edit formats, Git integration, linting and test loop make it excellent for developer-directed pair programming. Its public leaderboard is primarily a model/edit-format benchmark, not a controlled proof that Aider’s harness beats OpenCode. Aider is less of an agent platform: teams seeking persistent sessions, server APIs, MCP ecosystems and parallel agent orchestration will find OpenCode or OpenHands closer to the target.
OpenHands goes further toward a platform. Its runtime architecture separates the agent from Docker, process or remote sandboxes, and the project supports CLI, headless, GUI/web and ACP workflows. That isolation and self-hosting story is stronger for multi-user operations, at the cost of more infrastructure and complexity. Its sandbox overview explicitly calls process mode unsafe, which is the sort of boundary OpenCode users must supply externally.
Cost, latency and context efficiency
OpenCode is free software, but the software license is not the cost of completing a task. The bill can include model tokens, provider premiums, retries, context replay, failed attempts and engineering time spent on configuration.
OpenCode Zen publishes pay-as-you-go prices per million tokens on its current model page. OpenCode Go was $5 for the first month and $10 per month at retrieval time, with stated usage caps of $12 per five hours, $30 per week and $60 per month; requests consume different amounts depending on the model, according to the Go documentation. Those are dated product terms, not a forecast of task cost.
The cleanest comparable efficiency slice in the audited evidence is the DeepSeek bundle, where all five harnesses used proxy-metered tokens. Restricting to 20 task-trials solved by every harness, median wall time and total tokens were:
| Harness | Median wall time | Median total tokens | Scope |
|---|---|---|---|
| Pi | 14.7 s | 16,544 | 20 all-solved matched trials |
| OpenCode | 16.7 s | 52,949 | 20 all-solved matched trials |
| Claude Code | 19.8 s | 21,883 | 20 all-solved matched trials |
| Grokbuild | 22.9 s | 89,396 | 20 all-solved matched trials |
| Codex CLI | 20.8 s | 93,356 | 20 all-solved matched trials |
OpenCode was fast in that narrow slice, but it was not token-minimal. Nor can those figures be multiplied by a universal token price: cached input, output, reasoning tokens and provider markups differ. The GPT bundle mixes native and proxy telemetry, so a single cross-harness token chart would imply comparability the release does not provide.
Execution itself can be an efficiency trade-off. To Run or Not to Run analyzed 7,745 agent traces and 3,000 repair attempts across 200 SWE-bench instances. It found that the benefit of code execution was concentrated rather than universal, and that prohibiting execution in some commercial-agent settings reduced cost and time with only a small, statistically non-significant accuracy gap. That does not mean tools are useless. It means a harness should spend tokens and wall time on actions that change the probability of success.
So, is OpenCode cheaper? Sometimes, especially when a lower-priced model or local endpoint is good enough. Not demonstrably in general. A fair cost metric is dollars per accepted task, including failures and retries. The current public evidence does not provide a stable answer across models and environments.
Permissions, sandboxing, privacy and public sharing
OpenCode’s marketing theme of privacy needs qualification. Local session storage is privacy-friendly compared with a cloud-only agent, and direct-provider mode keeps OpenCode from acting as the model gateway. But prompt content still goes to the chosen provider, whose retention policy governs that path. The provider documentation says credentials are stored locally in ~/.local/share/opencode/auth.json; that is a storage fact, not end-to-end proof about every provider.
Zen routes prompts through OpenCode’s hosted service. Its privacy table describes model-specific retention exceptions; at retrieval time, the documentation said most paid endpoints were zero-retention while some OpenAI and Anthropic paths could retain data for 30 days, and free endpoints had separate exceptions. Go likewise publishes model-specific privacy terms. Teams must verify the row for the exact model snapshot they intend to use.
Sharing is a separate data path. Share documentation says manual sharing is the default. Once shared, the full conversation is synchronized to OpenCode’s servers and anyone with the link can view it until it is unshared. Auto-share mode is convenient and inappropriate for sensitive work unless the organization has explicitly accepted that disclosure boundary. The share page and enterprise page were not perfectly aligned about self-hosting: the latter said self-hosted sharing was on the roadmap. Treat it as unavailable until a deployable, supported artifact is verified.
The largest safety issue is execution. OpenCode permissions decide whether a tool call is allowed, denied or requires confirmation. Most default to allow, with selected protections for external directories, loops and .env files. This is useful policy, but it is not a kernel-enforced sandbox. A permitted shell command runs with the user’s operating-system rights. A compromised MCP server or over-broad custom tool can create its own path around an apparently careful prompt policy.
For a sensitive repository, the minimum credible baseline is:
- pin the OpenCode version and model/provider snapshot;
- disable sharing and verify the resolved configuration;
- restrict providers to approved endpoints and document retention;
- default shell, network, external-directory and destructive actions to ask or deny;
- permit only required MCP servers and custom tools;
- run in a disposable VM, container or OS sandbox with a narrow filesystem mount and egress policy;
- use short-lived, least-privilege credentials and keep secrets outside readable paths;
- retain local audit logs and test the policy with synthetic canaries before real code.
OpenCode can fit a team after that work. It is not the safest default for a team that equates an approval prompt with containment.
Model portability and lock-in
Portability is OpenCode’s durable value proposition. A team can keep project instructions, tool integrations and session habits while changing the model behind them. It can route sensitive work to an internal or local endpoint, expensive reasoning to a frontier model and routine edits to a cheaper model. Zen and Go are optional conveniences rather than prerequisites.
This reduces one kind of lock-in, but it creates a test obligation. Different models may interpret the same tools differently, use incompatible reasoning budgets or need different prompting. A provider can expose a model name without supporting every tool behavior. The fixed-model results show the inverse problem too: the same model can produce different outcomes under different harnesses.
The right abstraction is a compatibility envelope, not a provider count. For each approved model–harness pair, teams should qualify tool calls, patch correctness, secret handling, context limits, retry behavior, latency and cost. OpenCode makes that portfolio possible. It does not perform the qualification for you.
Best use cases—and poor fits
Choose OpenCode when:
- you actively use more than one model provider or need a credible migration path;
- local or internally hosted models are part of the plan;
- an inspectable HTTP API and generated SDK matter;
- you want terminal, desktop and IDE clients over one session-oriented runtime;
- your team can own configuration, external sandboxing and provider governance;
- you are building repeatable workflows around MCP, plugins, custom tools or subagents.
Stay with Claude Code or Codex when:
- the chosen model ecosystem is already an acceptable commitment;
- you prefer the vendor to co-design the model, prompts, tools and user experience;
- platform-supported sandboxing and centrally managed controls are higher priorities than provider switching;
- you need fewer combinations to validate and support.
Consider Aider when the real job is disciplined developer-led editing with Git, tests and a repository map rather than an extensible agent runtime. Consider OpenHands when isolated execution, a multi-user control plane and self-hosted agent infrastructure justify a heavier deployment.
Poor fits for OpenCode include security-sensitive teams unwilling to add containment, buyers expecting one provider subscription to make all supported models free, and users who want a benchmark-certified universal winner. The evidence supports none of those assumptions.
Final verdict
The thesis survives the audit, with one important amendment: OpenCode’s real advantage is not only that the model is replaceable and the runtime inspectable. It is that those properties let the user decide where integration should end. That is powerful engineering leverage.
It is also responsibility transferred to the operator.
OpenCode earned its recommendation for model-diverse individual developers, infrastructure-minded teams and organizations building an internal coding-agent layer. It did not earn a blanket recommendation as the most accurate, safest or cheapest harness. Its own benchmark is not mature enough to support competitive claims. Independent results put it in the competitive set, with overlapping uncertainty and clear model–harness interaction. Its permission defaults are more permissive than its privacy-forward positioning may lead some buyers to expect.
If you want one answer: choose OpenCode for controlled optionality. Choose Claude Code or Codex for tighter model-harness integration. For sensitive code, use OpenCode only inside a hardened environment with sharing disabled and provider policy verified. Flexibility is valuable—but only after success rate, retries and governance are included in the bill.
FAQ
Is OpenCode really open source?
Yes. The main OpenCode repository is published under the MIT License. Hosted services such as Zen, Go and public sharing are separate services with their own operational and data boundaries.
Is OpenCode better than Claude Code?
Not universally. OpenCode offers broader model portability and an open client/server runtime. Claude Code offers a tightly integrated Claude workflow, managed controls and optional OS-level Bash sandboxing. In the audited DeepSeek fixed-model bundle, Claude’s numeric solve rate was higher, but confidence intervals overlapped and the pairwise difference was not statistically significant.
Is OpenCode better than Codex CLI?
OpenCode is better for provider and local-model choice. Codex is stronger when an OpenAI-centered workflow and platform-native sandboxing are the priority. OpenBench’s audited samples did not establish a statistically significant solve-rate difference between them.
Does OpenCode have a sandbox?
It has configurable permission rules, not a built-in OS-level execution sandbox. For untrusted commands or sensitive repositories, add a VM, container or operating-system sandbox and restrict filesystem and network access.
Is LSP enabled by default in OpenCode?
No. The current official LSP documentation says it is disabled until enabled with lsp: true or a language-server configuration. Our credential-free v1.18.18 smoke test also returned no active LSP entries under default configuration.
Can OpenCode use local models?
Yes. It supports local and custom provider endpoints. Capability still depends on the selected model’s context window, tool calling and code-editing reliability.
Is OpenCode private?
It can store sessions locally and connect directly to a chosen provider, but remote inference still sends selected content to that provider. Zen and Go add hosted routing, and public sharing uploads the conversation to OpenCode’s service. Privacy must be evaluated per provider, model and sharing mode.
Is OpenCode cheaper than Claude Code or Codex?
Not automatically. It can access lower-cost and local models, but cost per successful task includes failures, retries, context and provider pricing. The public evidence reviewed here does not prove a general cost advantage.
Can teams use OpenCode on sensitive repositories?
Yes, conditionally. Teams should disable sharing, restrict providers and tools, harden permissions, isolate execution, apply least-privilege credentials and test the resulting policy before introducing sensitive code.
Methodology and source notes
Research was refreshed on August 16, 2026. Product claims were taken from official documentation, repositories, releases and licenses. Benchmark claims were recomputed from OpenBench raw JSONL and checked against release manifests. Research-only observations are attributed to their sources; the local observations in this article are limited to the explicitly described no-inference smoke test.
The OpenBench solve-rate tables use the strict intersection of task-trial cells present for every compared harness in each release. Confidence intervals are Wilson 95% intervals. Pairwise significance uses exact two-sided McNemar tests on matched cells. No adjustment for multiple comparisons was applied; none of the OpenCode comparisons was significant even before adjustment. Efficiency medians use only trials solved by every harness in the selected bundle.
The audited GPT and DeepSeek releases are not directly comparable as one experiment. They differ in model, harness versions, telemetry basis and some task fingerprints. “Solved” follows the release’s checker-owned outcome and documented starved-output rule. Missing telemetry is not silently treated as zero. The accompanying evidence ledger, comparison CSV, calculation script and recomputed cells provide the reproducibility trail.
Other primary sources consulted include SWE-bench’s evaluation FAQ, the Aider leaderboard, OpenHands, Harness-Bench, The Scaffold Effect and To Run or Not to Run. Each answers a narrower question than “which product is best?” That is why this review reports model–harness pairs, denominators and uncertainty instead of turning a rank into a universal winner.