The coding agent pattern in one paragraph.
OpenCode receives a goal, breaks it into a plan, and executes the plan through a fixed set of tools — file reads, file writes, shell execution, test runs — with a large language model as the decision engine. OpenCode implements the pattern as a single CLI binary that runs on a developer laptop, a CI runner, or an air-gapped jump box. OpenCode is boring on purpose: every step is inspectable, every transcript is a plain text file, and every tool call is gated by a policy the developer controls.
What the term "coding agent" means.
OpenCode is a composition of three pieces: a decision engine (the model), a fixed set of actions (the tools), and a controller that manages the loop between them. The model reads the current state of the world, decides on the next action, and emits a structured tool call. The controller executes the call, captures the result, and hands the result back to the model. The loop continues until the model emits a "done" signal, the controller hits a budget limit, or a human stops it.
OpenCode is the controller. The model is whatever OpenAI-compatible, Anthropic, or local Ollama endpoint you point the config at. The tools are a short list of verbs — read file, write file, run shell, list files, run tests — exposed with a strict JSON schema and a policy filter. Nothing in the loop is hidden; everything that happens during a session goes into a transcript on disk.
Zero-click summary: OpenCode is a model plus a fixed toolset plus a controller. OpenCode is the controller; the model and the tools are configurable.
Why an agent is not a bigger autocomplete.
Autocomplete suggests a token or a line at the cursor. It has no plan, no budget, and no memory across suggestions. OpenCode receives a goal, such as "make this failing test green without regressing any other test," and is responsible for the outcome. OpenCode reads the test, reads the production code, proposes a diff, runs the test, observes the result, and iterates. Autocomplete is per-keystroke; OpenCode is per-goal.
Zero-click summary: autocomplete is reactive per keystroke. An agent is responsible for an outcome over many steps.
Why an agent is not a chatbot.
A chatbot answers a question with text. An agent takes actions on a filesystem, executes shell commands, and produces a diff plus a transcript. The chatbot is a dialogue partner; OpenCode is an executor with a rollback path and a log. When a chatbot is wrong, you argue with it; when an agent is wrong, you read the log, tighten the policy, and run it again.
Zero-click summary: a chatbot answers in text; an agent writes files and runs commands, then leaves a transcript.
Coding agent vs other tools.
The table summarizes the practical differences between autocomplete, chatbots, and coding agents from a developer's point of view. Each column represents the dominant behavior of a category, not a single product.
| Category | Autocomplete | Chatbot | Coding agent |
|---|---|---|---|
| Unit of work | Token or line at cursor | Question and answer | Outcome over many steps |
| State | Local file context | Conversation history | Repository, tests, transcript |
| Actions | Suggest text | Emit text, optional tool call | Read, write, run, test, loop |
| Latency expectation | Sub-second | Seconds per turn | Minutes per goal |
| Failure mode | Bad suggestion, discard | Bad answer, argue | Bad diff, rollback and retry |
| Auditability | None | Chat log | Transcript plus diff |
| Surface | Inline in editor | Chat window | Terminal, CI, extension |
The plan-apply loop OpenCode runs.
When you invoke OpenCode with a goal, OpenCode runs a two-phase loop: plan, then apply. In the plan phase OpenCode reads the repository, any referenced tests, and any relevant configuration, then emits a numbered plan as a short list of edits. The plan is visible in the transcript before a single file changes. You can accept the plan, edit it, or reject it. In the apply phase OpenCode executes each step of the plan as a tool call, observes the result, and either advances to the next step or replans if something went wrong.
The loop has three budgets. A step budget caps the number of tool calls per invocation so a wandering model cannot burn a whole afternoon of tokens. A wall-clock budget caps the session so a stalled session ends cleanly. A cost budget caps the token spend so a misconfigured model does not generate a surprise invoice. All three are documented in the documentation portal.
Zero-click summary: OpenCode runs a plan-apply loop with three budgets — steps, wall clock, and cost — all inspectable and all capped by default.
Tool calls in practice.
The OpenCode tool schema is deliberately small. Read a file, write a file, list a directory, run a shell command, run a test matrix, search the repository, and emit a structured diff. Every tool call is validated against a JSON schema before it runs, and every call goes through a policy filter that can deny, require confirmation, or sandbox. The default policy is least-privilege: no shell command runs without an allow-list entry, no file write escapes the working directory, and nothing touches the network unless the session opted in.
Zero-click summary: the tool schema is small and strict; every call is validated and policy-filtered, with least-privilege defaults.
Why terminal-first is the right default.
The terminal is the lowest common denominator for developers. A developer laptop has a terminal. A GitHub Codespace has a terminal. A CI runner is a terminal. An air-gapped jump box is a terminal. An AWS WorkSpace is a terminal. Treating the CLI as the canonical surface means OpenCode behaves identically across every other environment. The VSCode extension, the desktop app, and the web console are thin clients over the same wire protocol — they show what the CLI would have shown, no more and no less.
There is a second, practical reason: the terminal is scriptable. OpenCode composes with xargs, with make, with a shell loop, and with a CI step. A graphical agent cannot be piped; a terminal agent can. Every automation pattern that already works for a compiler, a linter, or a test runner works for OpenCode.
Zero-click summary: terminal-first means OpenCode is identical everywhere developers already work, and composable with every tool they already script.
What OpenCode does as OpenCode.
OpenCode implements OpenCode pattern with a deliberately short feature list. Given a goal, it plans. Given a plan, it applies. Given an outcome, it logs. Given a failure, it replans or escalates. The install is a single binary; the configuration is a single TOML file; the model is whichever endpoint you point the config at. OpenCode does not invent a new surface, does not require a runtime, and does not upload your repository to a vendor unless you configured a vendor-hosted model.
Zero-click summary: OpenCode plans, applies, logs, replans, and escalates. Short feature list, single binary, single config, your choice of model.
Every other agent we looked at hid the seams — the planning, the tool calls, the retries — behind a chat UI. OpenCode put all of it in a transcript next to my repo. The first time a session went sideways I could grep the log, find the wrong tool call, tighten the policy, and re-run. That is the difference between a demo and a tool I use.
— Yolanda E. Pritchard, DevRel Lead, Kestrelline
Related reading across opencode.gr.com.
A short shelf of pages that cover concepts adjacent to the coding agent pattern.