Field Notes on Coding Agents: OpenCode, Local Models, and Production Workflows, Does OpenCode Costs More? Yes and in Quality Too.

amy 22/09/2026

Over the past two years, AI coding tools have transitioned from novelties to core engineering infrastructure. My daily stack started with Cursor, moved through various IDE forks and GPT Codex implementations, and eventually expanded to systems like Antigravity and Claude Code.

A key part of my work involves testing these environments systematically to advise client companies on which tools to integrate into their software development lifecycle. The criteria for an enterprise-ready tool are straightforward: reliability, predictability, clean context management, and support for both proprietary APIs and privacy-conscious local infrastructure.

Recently, I integrated OpenCode into my daily workflow to see if its terminal-first, open-source model could replace commercial alternatives. While the ergonomics showed promise early on, its real-world implementation introduced functional and operational bottlenecks that make it difficult to recommend for commercial teams.

Context Routing and API Overhead

OpenCode presents itself as a flexible, model-agnostic terminal environment. It allows users to wire up direct provider keys, configure OpenRouter gateways, and customize agent behaviors via opencode.jsonc.

However, its token consumption architecture is opaque. Unlike commercial environments that heavily cache repository graphs, OpenCode handles tasks through multi-step agent reasoning loops that reload wide context buffers repeatedly.

In day-to-day use, this approach leads to several practical issues:

  • Context Bleed: The underlying agent harness repeatedly passes conversational history and workspace state back and forth across intermediate steps, resulting in rapid token drain compared to tools with integrated deduplication.
  • Model Availability: Built-in community or free endpoints often suffer from rate limits, high latency, or dropped connections during longer multi-file edits.
  • Provider Complexity: Switching to top-tier commercial models requires juggling individual gateway limits and usage thresholds that lack clear in-session feedback.

The Local LLM Disconnect

A primary requirement for many client organizations is local model execution. For teams handling sensitive intellectual property or compliance-constrained codebases, running models locally via Ollama (such as qwen2.5-coder or deepseek-coder) is non-negotiable.

In standard environments like VS Code (via extensions) and Google Antigravity, pointing an agent to a local OpenAI-compatible endpoint (http://localhost:11434/v1) works cleanly. The engines respect local context parameters, stream tokens steadily, and parse tool-call syntax predictably.

OpenCode struggled significantly here:

  • It frequently mishandled structured tool calling when routed through local Ollama servers.
  • It often overshot local context windows, causing unhandled runtime exceptions.
  • While it handled standard commercial cloud APIs as intended, its local inference pipeline felt unoptimized and brittle.

If your team relies on an air-gapped, on-premise development setup, OpenCode currently falls short compared to established IDE alternatives.

Technical Breakdown: Pros and Cons

Strengths

  • TUI Ergonomics: The terminal interface is responsive. Keyboard navigation, command palettes, and mouse selections within the terminal feel native.
  • Status Visibility: The session status indicators clearly delineate between generation, pending review, and completed states.
  • Inline Git Diffs: File modifications are presented directly in the terminal with clean diff formatting before commits are staged.
  • Configurability: Agent definitions, sub-tasks, and provider configurations are exposed directly through text configuration files.

Weaknesses

  • Orchestration Overhead: The internal planning and execution agents pass state back and forth extensively, spending significant compute on internal coordination rather than direct file edits.
  • Terminal Quirks: The view automatically scrolls to the bottom on prompt submission, interrupting review of prior diffs or terminal output.
  • Local Runner Support: Brittle integration with local endpoints compared to native IDE implementations.

How It Compares to Claude Code

For developers who prefer terminal-native workflows, Claude Code offers a contrasting approach to the multi-agent design of OpenCode.
Instead of orchestrating multiple sub-agents to negotiate code edits, Claude Code pairs a single reasoning model directly with your workspace tree and terminal environment:

  • Direct Execution: It diagnoses errors, reads repository files, runs local tests, and applies targeted patches without intermediate agent handoffs.
  • Deterministic Tooling: Shell execution and git actions are straightforward, reducing translation loss between planning and execution.
  • Effective Caching: It leverages API prompt caching out of the box, keeping context operations lean across extended refactoring sessions.

The Community Perspective

The friction between single-agent efficiency and complex multi-agent orchestration is a broader industry topic. A user on Reddit captured this dynamic when assessing OpenCode:

“The opencode TUI is the only AI coding interface that didn’t annoy me. I hate the whole ‘orchestrator agent’ trend — it’s a deaf telephone game that spends 10x tokens for 1.1x quality. Just write your own modal agents + skills instead…
If you’re not after the visuals and ergonomics, and instead you want a ‘powerful agentic harness with orchestration and god knows what,’ opencode is not handling that… I think the orchestrator-agent idea boils down to:

10x cost1.1x quality0.9x time-to-finishJust write the modal agents you need — in place of or alongside the plan and build agents — plus some nice skills, and I think that’s far better than any orchestrator framework currently available.”

The core takeaway matches my testing: while a polished TUI improves developer comfort, an over-engineered orchestration layer introduces systemic inefficiencies.

Deployment Recommendations

When recommending tools across different team profiles and project requirements:

  1. For Hobby Projects and Terminal Tinkering: OpenCode
    Well-suited for developers who want an open-source terminal interface, enjoy customizing config files, and run lightweight experiments where operational overhead is not a primary concern.
  2. For Resource-Heavy Experimental Setups: Custom Multi-Agent Frameworks
    Suited for teams specifically researching multi-agent autonomous coordination who have ample compute infrastructure and do not mind extended iteration cycles for code generation.
  3. For Local-Only, Compliance-Heavy Workflows: VS Code with Ollama
    The most stable foundation for teams requiring fully offline inference with strict data privacy constraints and deliberate, developer-controlled completions.
  4. For Serious Daily Production: Codex, Cursor, and Antigravity
    For client teams delivering production code under real-world deadlines, stability and context efficiency remain critical:
    • Cursor: The most consistent general-purpose IDE for cross-repository edits and daily developer velocity.
    • GPT Codex: Highly reliable for low-latency completions and direct integration within standard development pipelines.
    • Google Antigravity: The preferred option for managing multi-file context, handling structured agent workflows, and maintaining seamless compatibility across diverse project configurations.

Resources

《Field Notes on Coding Agents: OpenCode, Local Models, and Production Workflows, Does OpenCode Costs More? Yes and in Quality Too.》