The Agent Harness Matters
Most discussions about coding agents compare models. I use OpenCode and Claude Code every day. In my experience, the harness (the program around the model) changes my results about as much as the model does. The same model behaves differently depending on its tools, what it can run, the feedback it gets after an edit, and what it remembers.
What the harness decides
Tools and their descriptions. The harness decides which tools exist and how they are described to the model. A harness that gives the model a dedicated search tool gets fewer shell pipelines than one that offers only a shell.
Permissions. OpenCode resolves rules in order and the last match wins (docs). Claude Code evaluates deny, then ask, then allow, whatever the order (docs). The same intent needs different configuration in each. I wrote about this in Permissions for AI agents.
Feedback after an edit. OpenCode V1 integrated with language servers and used their diagnostics as feedback for the agent. In practice, this meant that its edits usually compiled and passed the linter on the first try, because the agent saw the errors before it reported back. The V2 migration guide says that V2 does not run language servers or produce LSP diagnostics, and recommends running the project's lint, typecheck or compiler commands instead. So two versions of the same tool, with the same model, give different results because one feedback loop changed.
Context management. The harness decides how to compact a long session and what to load at the start. It also decides whether instructions load on demand (skills) or on every turn. These choices decide how much context is left for your problem.
Subagents and multi-agent work. In my experience, Claude Code uses subagents and parallel work more than OpenCode does. That helps for broad searches. It is a problem when I want one agent to keep the whole investigation in one context.
Session persistence. Where sessions live, and whether they survive an upgrade, is a harness decision too.
A UI over another agent is still that agent
The Agent Client Protocol (ACP), which Zed started, standardizes how an editor or client talks to a coding agent, using JSON-RPC over stdio for local agents. OpenCode can run as an ACP agent with opencode acp, and there are adapters that expose Claude Code over ACP.
This is useful, but it is easy to misunderstand. If one tool is the client and another agent runs behind ACP, you get the client's interface and the other agent's tools, system prompt and permission model. I once looked at driving Claude Code from OpenCode this way. The result would be Claude Code with a different UI, without the OpenCode tools and prompts that I preferred. Decide which part you want before you connect the two.
Keep repositories harness-agnostic
Teams will not agree on one harness, and the best one changes every few months. I keep project instructions in AGENTS.md, an open format that many agents read, including OpenCode. Claude Code reads AGENTS.md when the repository has no CLAUDE.md, and a CLAUDE.md can import it with @AGENTS.md.
For skills, agents and commands, the formats are not shared yet. I keep the content (the procedures, the safety rules, the memory) in plain Markdown, and keep the vendor-specific part to a thin wrapper of frontmatter.
Keep important state in files
Major upgrades can change how a tool stores sessions. When I moved to OpenCode V2, the upgrade was a clear improvement, and I also lost my earlier sessions. The migration guide is about configuration and plugins, and it does not say what happens to session history.
Nothing important was lost, because I had already stopped treating sessions as storage. Investigation findings go into a memory wiki in the repository. Plans go into a file. Handoffs between agents are prompts written to a file or passed in full. A session is a working space, and anything you want next month belongs in git.
How I evaluate a harness now
When I try a new harness or a major version, I check four things before I look at benchmark scores:
- Permission model. Can I default to "ask", allow reads by pattern, and make writes win? How are pipelines and compound commands checked? What happens when nobody is there to answer a prompt?
- Context handling. What loads at session start? Can instructions load on demand? What happens to a long session, and can I see it happen?
- Extensibility. Does it support skills, custom commands, subagents and MCP servers? Does it read
AGENTS.md? Is there an SDK so I can run it from a script or a chat bridge? - Observability. Can I see every tool call, its input and its output? Can I export a session? Can I review afterwards which commands needed approval?
Both tools I use do well on some of these and worse on others, and the balance changes with each release. That is why I keep my setup portable: Markdown instructions, file-based state, and permission rules that I can translate from one format to another in an afternoon.
References
- OpenCodehttps://opencode.ai/docs/
- Claude Codehttps://code.claude.com/docs/en/overview
- docshttps://opencode.ai/v2/docs/permissions/
- docshttps://code.claude.com/docs/en/permissions#manage-permissions
- diagnostics as feedback for the agenthttps://opencode.ai/docs/lsp/
- migration guidehttps://opencode.ai/v2/docs/migrate-v1/
- subagentshttps://code.claude.com/docs/en/sub-agents
- Agent Client Protocolhttps://agentclientprotocol.com/overview/introduction
- Zedhttps://zed.dev/acp
- run as an ACP agenthttps://opencode.ai/docs/acp/
- AGENTS.mdhttps://agents.md/
- reads AGENTS.mdhttps://code.claude.com/docs/en/memory#agents-md
- MCPhttps://modelcontextprotocol.io/