The OpenCode difference, and where to point it next

This page is the course’s synthesis. It steps back from the keyboard and asks three questions worth asking at the end of any tool’s learning curve: which of OpenCode’s design commitments are worth keeping, what does each one earn on a real repository, and what do you take with you when the repo is done? Keyboard-driven TUIs and headless runs are common to terminal coding agents, so this page does not claim them as unique to OpenCode; it weighs the form each commitment takes here. Each capability below is stated as what OpenCode does, with a link to the chapter that teaches it in depth - nothing here depends on remembering a particular stretch of work.

The setup here means a model chosen per task, AGENTS.md rules, skills, a permission map, and a headless run. Its measure is a before and after you can state plainly. Before: a repo like feedmill - the course’s illustrative scenario, a small Go feed aggregator with dozens of differently-shaped sources - arrives as code you don’t fully trust, thin on docs, with a parser package full of someone else’s assumptions and a suspected date bug. After: the bug is fixed and committed, the parsers have tests pinning the cases that used to break, the rules that kept biting are written down where every session loads them, and a nightly check runs without anyone watching. None of that transformation requires OpenCode specifically. But three of its design commitments make the getting there faster, and they are the three worth keeping.

The model is always yours to choose

OpenCode is provider-agnostic by design: it speaks to 75+ model providers (as of October 2026; providers documentation), and every model is addressed as a provider/model string - anthropic/claude-sonnet-4-5, openai/gpt-5.2, ollama/llama3.1 - where the slash is what lets several providers coexist in one setup without OpenCode guessing which you meant.

Because the addressing is uniform, switching is cheap, and OpenCode ships per-task and per-agent provider switching as a first-class knob (per-agent models): the model is a setting on each job, not a decision the tool makes once for you. A cheap model handles a throwaway question as a one-shot, with -m naming the model (an illustrative call; CLI documentation, as of October 2026):

$ opencode run -m anthropic/claude-haiku-4-5 "what does the dedupe step key on?"

A heavier one goes on the agent that handles the parser refactor that actually has to land. The deciding question is what a wrong answer costs you. Parsing one feed’s gnarly Atom edge cases produces logic that is hard to check and expensive to get wrong, so a stronger model can pay for itself in fewer retries and less review. A README draft is text you can check at a glance, so a cheap model is enough. That is the capability and cost principles in one decision: pay for a stronger model where its capability saves retries and review, and nowhere else. OpenCode never asks you to pretend one model is right for both (switching models mid-session is the how-to). Used this way, “pick the model that fits this task” stops being a decision and becomes a reflex, the way you’d reach for a different wrench - cheap by default, expensive on purpose, checked against opencode stats (token usage and cost across your sessions) when the bill matters.

The TUI makes the keyboard the fast path

OpenCode’s TUI (terminal user interface) is built to be driven from the keyboard, and the core bindings are few - ctrl+p opens the command palette, the searchable list of every registered command; ctrl+x is the leader key, the prefix most chords hang off; Tab swaps the primary agent - OpenCode’s built-in plan and build - mid-session (bindings as of October 2026; keybinds documentation); /undo reverts the last exchange, file changes included, in a Git repository (TUI documentation, as of October 2026):

  ctrl+p           →  find any command, learn its chord
  ctrl+x  then l   →  list sessions and pick the one where you were stuck
  Tab              →  swap the agent driving this turn
  /undo            →  revert the last bad exchange

In OpenCode 2

ctrl+p, ctrl+x, and /undo work as described, but the agent swap is Shift+Tab, and keymap settings move from tui.json to one global ~/.config/opencode/cli.json with no per-project file. See keybinds and CLI settings, as of October 2026.

The point is not keyboard purism. Feed-aggregator work is constant context-switching - jump to the JSON-parser session, swap a cheaper model onto a throwaway, undo an exchange that went wrong - and an interface that makes each of those a chord instead of a hunt is the difference between fighting the tool and forgetting it’s there (the leader key and the command palette teaches the two doors; undo, redo, and compaction covers /undo). And none of it is fixed: the keymap bends to your hands in tui.json, remapped per project or machine-wide (configuration documentation, as of September 2026; make the TUI yours covers the map).

The architecture is open, so you can open it up

OpenCode is a client/server engine rather than a sealed app: one engine drives both the TUI and headless runs, opencode serve stands it up as a long-running HTTP server (server documentation, as of October 2026), and opencode run --attach connects a run to that server (CLI documentation, as of October 2026). A session is not sealed inside the TUI either: you can hand it to a machine to run, and since v1.19.1 the old way of handing it to a person, a public share link, is gone.

In OpenCode 2

opencode run --attach does not exist in v2. Commands that talk to a server take --server <url> (or --standalone for a private one), and opencode serve starts the v2 API server with a new API contract. See the CLI documentation, as of October 2026.

To a person, there is no share link any more. /share and its public opncd.ai/s/<id> links were discontinued in v1.19.1 (release notes, as of October 2026). For a second opinion on a stuck session, send a minimal reproduction or a reviewed opencode export file, and keep the control principle where it always lived: what your prompts and file reads send to the model provider is governed by your provider choice and permission map (sharing, discontinued, and what still leaves).

To a machine, as a headless run. The same engine runs with no TUI at all: opencode run for a one-shot job, --format json when a script needs the run as a stream of events, opencode serve for automation to point at, and CI wiring on top (run OpenCode headless; the server, CI, and GitHub). For a repo that already runs unattended on a cron, that is the missing half: the agent joins the cron. A headless run drives the local engine itself, which is the client/server architecture at work.

What carries past this repo

Here’s the part that makes the setup worth more than one fixed repo. Some of it travels as files that other tools read as they are; the rest travels as ideas you configure again in each tool. The standing rules live in AGENTS.md - the open agents.md spec, the same file Codex and Cursor read (as of September 2026; agents.md) - committed to the repo’s git root, so the next person or tool inherits the hard-won context instead of relearning it. That is the context principle: an agent decides with what reaches it, and a committed rule reaches every session. The skills (SKILL.md procedures the agent loads on demand) are portable packages, not OpenCode-flavored macros: besides .opencode/skills/, OpenCode also searches .claude/skills/ and .agents/skills/ (as of October 2026; skills documentation; reuse a portable skill). That portability runs inward: a skill kept in .opencode/skills/ loads only in a tool that searches that directory, so a skill meant to travel belongs in a directory the next tool also reads, such as .claude/skills/ for Claude Code or .agents/skills/ for Codex (as of September 2026; Claude Code skills, Codex skills). The permission posture, the agents-as-policy split (switching agents switches what’s allowed: plan denies the edit tools, build does not), the headless invocation - those travel as ideas, not files. The permission map, the agent definitions, and the opencode run flags are OpenCode configuration, and the next tool needs its own version of each. The same handful that can tame one untrusted repo scales to a team workflow: agents to isolate work, permissions to bound it, AGENTS.md to encode the shared rules, a headless run to put it in CI. If you have built those pieces, you didn’t learn a tool. You learned a setup whose files come with you and whose ideas you rebuild in each tool’s own terms.

One honest caveat before you go further

OpenCode drifts fast - it’s young and shipping hard. Some of what this course described will have moved by the time you reach for it: a config key renamed, a TUI command or keybind relabeled, a flag that grew or lost an option. That’s not a reason to distrust it; it’s a reason to keep one habit. When something doesn’t behave the way this course described, check the current docs at opencode.ai/docs before assuming you’re holding it wrong - the concepts here are stable, but the exact names underneath them are not. Treat this course as a strong starting point, and the live docs as the tiebreaker.

Where to point it next

Once these pieces are in place, the setup is a model you chose, a TUI you drive blind, an open engine you can automate, and habits that travel. The natural next move isn’t a new feature of OpenCode - it’s noticing which parts of the setup were about OpenCode at all. Strip the TUI away and what’s left is a small set of primitives: written-down rules, procedures you load on demand, work you hand to an isolated agent, a permission map that says no, and a run that happens with nobody watching. Each one has a spec-level treatment in Foundations, and each one shows up under a different name in every other tool worth using - which is the point of the sibling courses.

feedmill isn’t finished, and neither is any repo worth working on. But the durable output isn’t one fixed parser. It’s the setup that fixes the next one, and that setup is yours to take anywhere.