Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 4 — Tool System Design
Token Usage: ~7,900 input + ~1,650 output

4.2 Shared Tool Inventory

One of the most striking findings in this three-system comparison is not how different the tool sets are, but how similar their core inventory has become. OpenCode, Claude Code, and OMO differ in packaging, naming, orchestration depth, and product polish, yet they converge on a common minimum toolkit for practical coding autonomy. That convergence is important because it suggests a de facto standard architecture for AI coding agents in 2026.

At the highest level, all three systems expose tools in six broad categories: file operations, search, command execution, web access, composition, and interactive clarification. These categories correspond closely to the real workflow of software engineering. A coding agent must inspect code, modify code, search for symbols or strings, run commands, retrieve external information, delegate subtasks, and occasionally ask the user a question. Remove any one of these and the agent becomes noticeably weaker.

The first shared category is file operations. All three systems include read, write, and edit capabilities. The details differ, but the pattern is stable: read returns bounded file content; write creates or replaces content; edit performs targeted structured modification, often with diff-like semantics. This matters because software engineering is not merely text generation. It is stateful transformation of an existing artifact. A useful coding agent must be able to inspect current state and produce incremental edits rather than regenerate whole files unnecessarily.

The second shared category is search. The common primitives are grep, glob, and some kind of code-oriented search. grep performs regex-based content search across files. glob performs filename or path-pattern matching, such as src/**/*.ts. Code search goes one step further by searching source structure or indexed code content rather than raw file names alone. These tools are fundamental because an agent cannot reason well about a repository it cannot navigate. Search tools are the eyes of the coding agent.

The third shared category is execution, centered on a shell tool such as bash. In all three systems, command execution is not a casual extra; it is a central capability. Tests, builds, linters, package managers, Git operations, local scripts, and environment inspection all flow through shell access. In practice, the shell tool is the highest-leverage tool in the system, which is precisely why it also becomes the highest-risk one. Claude Code adds deeper classification and sandbox logic, while OpenCode and OMO wrap execution with permissions and truncation, but all three accept the same basic reality: a coding agent that cannot execute commands remains only half-empowered.

The fourth shared category is web access. All three systems expose some version of webfetch, typically combining HTTP retrieval with a conversion layer that returns text or markdown instead of raw HTML. All three also support web search, either directly or through provider-dependent enablement. This is an important evolution beyond early “offline” coding agents. Modern software work often depends on package documentation, API references, issue threads, release notes, and current ecosystem knowledge. The web tool turns the agent from a repository-local assistant into a networked researcher.

The fifth shared category is composition. Here the common tools are task and skill. A task tool delegates work to a subagent or background worker. A skill tool loads reusable instruction bundles, templates, or domain-specific prompt modules. This category reveals a major shift in agent design. Tools are no longer only world-interaction primitives like file I/O and shell. They are also cognition-structuring primitives. Delegation and skill loading are mechanisms for reorganizing the model’s problem-solving process.

The sixth shared category is interactive clarification, represented by tools like question or ask user. Even highly autonomous coding agents still need a safe channel for explicit user input. Sometimes the issue is ambiguity. Sometimes it is permission. Sometimes the user must choose among alternatives or provide a secret that the runtime cannot infer. The existence of a dedicated question tool is therefore a design acknowledgement that autonomy has limits and that explicit human checkpoints remain valuable.

The equivalence is easiest to see in table form.

This table should not be read as claiming one-to-one identity. The tools are not always semantically identical. Claude Code’s AgentTool participates in a more productized background-task system. OMO’s delegation tools integrate with its specialized multi-agent architecture. OpenCode’s tools remain comparatively direct and kernel-like. Yet the capability lattice is unmistakably shared.

That shared inventory reveals a deeper architectural truth. The tool system of a coding agent is converging toward an operating-system-like substrate. File tools correspond to storage operations. Search tools correspond to indexing and lookup. Shell tools correspond to process execution. Web tools correspond to network I/O. Task tools correspond to scheduling and parallel work. Skill tools correspond to dynamically loaded procedures or operator manuals. Question tools correspond to privileged interrupts from the human supervisor.

This is why tool count alone is a misleading metric. A system with fifty tools is not necessarily more capable than one with twenty if the extra thirty are just aliases, UI conveniences, or narrow variants. What matters more is whether the system covers the full workflow graph of software engineering. On that test, all three systems already cover the essentials.

OMO then demonstrates what happens when one keeps the shared base inventory but extends the composition layer aggressively. OpenCode supplies the foundation. Claude Code broadens and hardens the base set within a commercial product surface. OMO adds orchestration-centric tools like session management, background output retrieval, and agent spawning, but it does so without abandoning the common substrate. That is why OMO feels familiar despite being much more interventionist.

The design lesson is that the field has already discovered a stable minimum viable tool stack for coding agents. New systems can innovate above it, but they rarely replace it. If you are designing an agent from scratch, you should assume you need at least the shared inventory described here. Everything else is an optimization, specialization, or product strategy layered on top of that core.