OpenCode 2.0

Original Article ↗ Hacker News Discussion ↗

OpenCode 2.0, an open‑source AI coding harness with a client–server architecture, is seen as a substantial feature upgrade over v1, adding background tasks, hot‑reloaded plugins, better config handling, and stronger multi‑client support. At the same time, many users report serious concerns: heavy RAM/CPU usage, a slow and GPU‑hungry promotional website and installer, security regressions around sandboxing and remote config, and a perception of “vibe‑coded” quality and support. Several commenters say they’ve switched or are considering switching to alternatives like Pi, Claude Code, Codex, or DeepSeek’s harness, often citing better performance, simpler UX, and clearer pricing, though some still view OpenCode’s Go subscription and ecosystem as a strong value.

Overall reception of OpenCode 2.0

  • Many long‑time users see 2.0 as a substantial improvement over 1.x (client/server model, background tasks, subagents, auto‑reloading skills/plugins, config-from-project-folder, built‑in config editor).
  • Some use it as a daily driver and praise model‑agnostic design, remote access via server, and non‑TUI UIs (web/desktop).
  • Others are disappointed: regressions, broken basics (e.g., sidebar hiding), clunky feel, and confusion about how to install or even get “2.0” from npm.

Performance, resource usage, and daemon

  • Strong complaints about the promo website: heavy animations/WebGL‑like behavior, slow scrolling, high CPU/fan usage, especially on phones and laptops; some find it nearly unusable.
  • Tool performance is a recurring issue: high RAM/CPU, large file watcher counts, previous temp‑file blowups, and a reputation for “memory leak” behavior.
  • 2.0’s persistent background server improves startup and enables multi‑client use, but some strongly object to an always‑running daemon by default.
  • A few report Opencode continuing to drive local models even after the UI is closed.

Security, sandboxing, and plugins

  • Multiple users describe 2.0 security regressions:
    • Background process bypassing existing TUIs’ sandboxes.
    • Tools added by plugins not obeying permission configs.
    • Hot‑reloading plugins so agents can immediately change their own environment.
    • Mandatory remote config loading from providers’ .well-known/opencode, described as effectively remote code execution.
  • The minimal custom JavaScript interpreter is seen as especially risky compared to using a mature engine.
  • Recommended mitigations: --standalone, running in containers/VMs, or dedicated sandbox tools; some argue true security is unattainable for harnesses and isolation is mandatory.

Installer, packaging, and tooling

  • curl | sh installer had an extremely slow “progress bar” due to a misused curl trace; later fixed.
  • Copy‑paste hijacking in the TUI remains a major annoyance.
  • npm packaging is criticized: postinstall downloads the real code, often fails (“postinstall script not run”), and there’s confusion over tagged releases.

Comparisons with other harnesses and pricing

  • Pi, Codex, Claude Code, DeepSeek harness, and others are frequently compared:
    • Pi is praised for low resource usage, minimal prompts, simplicity, and strong performance with local/open models; several users migrated from OpenCode due to UX, performance, or security concerns.
    • Others stick with OpenCode for client/server design, UI options, and provider flexibility.
  • OpenCode Go subscriptions are widely viewed as a very good deal with generous, subsidized limits, though the pricing model and request/limit tables are confusing.
  • One user reports being consistently overbilled relative to documented per‑token prices and ignored after initial acknowledgement, which damaged their trust.

UX, ecosystem, and workflows

  • Some prefer OpenCode mainly as a backend and use alternative UIs like OpenChamber, Paseo, Termic, or editor integrations (Vim/Neovim/VSCode/Zed).
  • Debate over TUI vs GUI: keyboard‑driven TUIs are seen as powerful by some; others find TUIs terrible for long prose and markdown, preferring rich GUIs.
  • Extension/plugin ecosystems (MCP, tools, skills) are a major draw, but also a source of complexity and potential security issues.
  • Harness benchmarks are mentioned; results vary, and users stress that behavior depends heavily on harness design, tools, and prompts, not just the base model.