OpenCode Technical Review: Tooling, Search, and Context Management

This review examines whether OpenCode exposes practical mechanisms for measuring tool latency, repository discovery, output growth, and memory pressure during coding-agent work. The assessment is based on public source and documentation at one development commit.

Because the reviewed ref is the default development branch, it should be treated as a moving implementation snapshot rather than a stable-release guarantee. Performance conclusions require a pinned build, fixed model, fixed repository corpus, and repeated runtime measurements.

The reviewed implementation provides distinct file, grep, glob, read, and language-server paths. Ripgrep-backed operations use explicit result limits, while file-finding code records duration. The repository also includes a search benchmark script covering file, grep, and glob queries.

That architecture changes the original diligence question. Measuring “large codebase indexing” as one operation could misdescribe actual behavior. The stronger test measures cold and warm latency for each discovery path, result completeness under limits, and scaling as file count and repository size increase.

The read tool pages large files and truncates unusually long lines. Search tools cap returned results. The newer core paths also distinguish complete structured results from bounded model-facing previews and can retain oversized output in managed files.

These controls are relevant because tool output becomes model context. The key test is whether bounding reduces token load without hiding the evidence needed to complete a task. Measure returned bytes, estimated tokens, follow-up reads, missed targets, and task success together.

CodeMode defines a catalog budget using an estimated character-to-token ratio and offers deterministic search when the full tool catalog is not inlined. It also supports limits for execution time, tool-call count, and output bytes.

This is a concrete response to tool-schema bloat, but the trade-off remains empirical. A reduced catalog can save prompt tokens while requiring extra discovery calls. Benchmarks should compare total tokens and completion time across small, medium, and very large tool registries.

The application UI includes a file-content cache with byte accounting and eviction, while the agent runtime manages sessions, messages, and tool results separately. Treating all of these as one memory system would produce an ambiguous result.

Profile peak resident memory for the CLI or server process independently from browser cache behavior. Track session database growth, managed tool-output storage, open file count, and retained context after long tasks. Repeat after process restart to distinguish durable state from transient memory.

OpenCode exposes enough separate search, tool, and context-management paths for a useful engineering benchmark. Bounded reads, capped searches, tool discovery budgets, execution limits, and existing benchmark scaffolding are positive testability signals.

Our source-only conclusion is that the project is benchmarkable, not that it is fast or memory-efficient under every repository. The defensible next step is a corpus-based test across repository sizes with cold and warm runs, process telemetry, and task-quality scoring.