OpenCode vs deepagents: Is a Human Waiting?

OpenCode is something you install and use. deepagents is something you import and build with.

That sounds like a distinction too obvious to write down, and yet these two get compared constantly, because they contain the same machinery. Both plan. Both read and write files. Both run commands, spawn subagents, load skills, and manage a context window that would otherwise overflow. The parts list is nearly identical.

What differs is who the machinery is pointed at.

The question that decides it

Is a human waiting for the result?

If yes, and you are at a terminal wanting a refactor done that you will read as a diff, that is OpenCode. The interface is the product, and everything about it assumes a developer present and reviewing.

If no, because a webhook fired or a nightly job started or a ticket arrived that something has to triage before anyone is awake, that is deepagents. It is a library, so the agent it produces is a function your program calls, which is what you need when the caller is another program.

Everything below is detail on that.

What each one is

OpenCode is a terminal-first coding agent from SST. Install it, open a repository, and work. Three things make it more than a chat box in a terminal:

• LSP integration. It reads real diagnostics from your language server, so the model is corrected by your actual compiler rather than by its own guess about whether the code is valid.
• Plan and Build modes. Plan explores and proposes without touching files; Build executes.
• 75+ providers through Models.dev, including local and open models, which is what keeps a bring-your-own-model arrangement possible.

deepagents is LangChain's opinionated harness, MIT-licensed, in Python and JavaScript. It sits on create_agent, which sits on the LangGraph runtime, and it bundles the parts you would otherwise assemble by hand:

from deepagents import create_deep_agent

agent = create_deep_agent(
    tools=[search_tickets, post_reply],
    instructions="Triage inbound support tickets against the runbook.",
)

agent.invoke({"messages": [{"role": "user", "content": ticket_text}]})

Planning, a filesystem backend with pluggable storage, subagents with isolated context, skills, context management that summarises and offloads to disk, shell access, persistent memory, and human-in-the-loop approval on tool calls. Because LangGraph is underneath, you also inherit durable execution and streaming.

Head-to-head

The star gap is a distribution artefact rather than a quality signal. Anyone can install an application, while a library's audience is people building something specific. Read it that way.

Where each one is genuinely better

OpenCode is better at being corrected. The LSP integration is the underrated feature of the whole category. An agent that can see Property 'user' does not exist on type 'Session' gets a tight, factual feedback loop from your own toolchain. Reproducing that inside a library means wiring a language server yourself.

deepagents is better at being embedded. When the agent has to be part of a product, triaging tickets in your queue or running on a schedule or writing to your database behind an approval gate, you need a function you can call, test and deploy. The human-in-the-loop hook on tool calls is the piece that matters most for anything touching a system of record.

deepagents is better at delegation you control. Subagents with isolated context are a first-class primitive, so a long job can hand a sub-question to a fresh context and keep the main thread clean. That is available rather than programmable in a finished application.

Using both, which is common

The usual arrangement in a working team is not a choice at all.

Developers use OpenCode for their own work, since it is the better place to sit while writing code. The product's automated agents are built with deepagents, because they run without anyone watching and have to be tested and deployed like the rest of the codebase.

They meet in one useful place: MCP. Tools you write for your product's agents can be exposed over MCP and picked up by OpenCode, so the internal tooling a developer uses interactively and the tooling the automated agent uses can be the same code.

Running open models behind either

Both keep the model choice open, which is the property worth checking before adopting anything in this category.

OpenCode's provider list covers open models directly, so pointing it at GLM-5.2 or a local endpoint is configuration. deepagents inherits LangChain's model abstraction, so the same swap is one line.

That means the routing arrangement in running open models at frontier level works under either, and the cost per solved task arithmetic applies to both. Neither tool ties you to a vendor, and both would be worse if they did.

In one line

Install OpenCode for the work you do yourself. Import deepagents for the work that has to happen while you sleep.

Next in this series: OpenCode vs Pi, two terminal harnesses that disagree about how much a harness should do. The map for the whole series is runtime, harness, product.

Sources

• OpenCode
• deepagents on GitHub