How to Evaluate OpenCode as a Working Coding System
This final synthesis evaluates OpenCode as a working coding system by following one repository task across its client, project scope, Session, model, context, tools, permissions, and extension boundaries. The question is not whether OpenCode can produce an impressive answer in a short demonstration. It is whether the surrounding runtime makes a real coding task useful, observable, and appropriately governable. The reader can use the model below to judge what OpenCode actually provides, what the repository supports, and what must remain an operator or deployment responsibility.
One task, one runtime
Consider a task such as: “Find the authentication flow, update its error handling, run the relevant checks, and explain any remaining risk.” The task looks like one sentence, but it contains several kinds of work. The agent must locate the right project, discover the relevant code, interpret local instructions, choose a model that can handle the required tools, read files, make a change, execute checks, and preserve enough state to explain what happened. OpenCode’s architecture is valuable when it coordinates those steps without pretending they are one operation.
The task can enter through the terminal UI or through the HTTP client contract. The transport may be an embedded worker and in-memory bridge or an external server connection, but the request still reaches the same domain boundary. The active project Location establishes which directory, worktree, project identity, and workspace context the request belongs to. That first association is more consequential than it sounds: configuration, context sources, tool registrations, permissions, model catalog state, and the session runner are resolved for the Location.
The Session then gives the task continuity. OpenCode can admit the prompt as durable pending input before promoting it into model-visible history. That lets the runtime distinguish a request it has accepted from a request the model has already seen. At a safe provider-turn boundary, the Session runner selects the agent and model, loads the current context, materializes available tools, and assembles the request. A steering message can be admitted into a still-running task without rewriting an in-flight provider request; a queued message can wait until the current work would otherwise become idle.
The selected agent contributes a role and policy. A development-oriented role can have a different action surface from a read-only planning role. The selected model contributes a different set of capabilities, limits, variants, and provider semantics. The context layer contributes the project facts and instructions currently effective for that Location. The tool layer contributes operations such as reading, searching, editing, shell execution, or loading a skill. The permission layer decides whether a requested action is allowed, requires user approval, or is denied.
The model is called for one provider turn. It might return a direct explanation, or it might request a repository search. In the second case, OpenCode does not treat the request as an arbitrary function call that jumps directly into the host. It resolves the effective tool registration, decodes the input, performs the tool’s authorization checks, executes the handler, validates and projects the output, bounds oversized model-facing content, and records the settlement. The runner then reloads the updated Session history and starts another provider turn.
That loop is where the orchestration thesis becomes concrete. The model supplies the next decision within the request. OpenCode supplies the Location, the current context, the available capability, the policy check, the durable identity, the result representation, and the continuation rule. If the authentication file changed after approval, an exact edit can fail rather than silently applying to a different version. If a tool registration became stale, the call can be rejected rather than redirected. If a provider route is unsupported, the runtime can say so rather than silently changing the transport.
The Session makes the result more than a stream of text. Durable events and projected messages give different consumers different views of the same work. A TUI can show live output, while a client can replay committed Session events after an aggregate sequence. A later provider turn can use the projected history after compaction. A user can inspect what was admitted, what tool calls settled, which model was selected, and whether the Session is still active in the current process. These are system-level properties that a model endpoint alone cannot provide.