Course · OpenCode
The OpenCode course
This is a hands-on course, not a reference. Its illustrative scenario is feedmill, a small self-hosted, terminal-first feed aggregator: a Go CLI plus an HTTP sync server that pulls dozens of RSS, Atom, and JSON feeds, dedupes them, and serves a reading queue you read from the terminal. It mostly works, it’s thin on docs, and one feed type is suspected of parsing its dates wrong. Across the course, OpenCode takes it from code you don’t fully trust to something you can leave running unattended. Every lesson takes a problem you’ll really hit and shows the exact OpenCode move that fixes it.
This course is differentiator-first. OpenCode isn’t tied to one vendor’s model, it lives in a full-screen TUI (terminal user interface) instead of a chat sidebar, and it’s an open client/server you can drive headless and serve. So we lead with what sets it apart - bring-your-own-model across 75+ providers (as of October 2026; providers documentation), the keyboard-driven TUI, the client/server architecture - before settling into the agent primitives every tool shares (AGENTS.md, skills, subagents, MCP/LSP). If you want the spec-level “what is this primitive” view, that’s Foundations. This course is the other half: the muscle memory.
Already use another CLI? The Codex and Claude Code courses are two of its siblings - same teach-by-doing spine, a different tool. OpenCode shares the AGENTS.md standard with Codex, so that chapter will feel familiar.
The authors wrote these examples against a private feedmill fixture, and it is not published with this site. Follow the same exercises in a disposable repository (Go matches the examples most closely) and adapt the named paths to your project; there is no companion download.
Four principles for making the tradeoffs
Section titled “Four principles for making the tradeoffs”The course uses four principles to explain why a feature matters, not just where its keybinding lives:
- Capability is what the agent can accomplish with its model and tools. OpenCode makes this unusually visible when you compare providers or give a specialist agent a different model.
- Context is the information available when the agent decides. Rules, skills, files, tool results, and session history help only when they are relevant and trustworthy.
- Control is what guides execution or enforces a boundary. Per-agent permissions, approval gates, and an outer container provide different strengths of control.
- Cost includes model spend, time, retries, review effort, and rework. A cheaper call is not cheaper overall if it needs three attempts and a manual repair.
Context is the organizing theme: most of the course is about what reaches the agent, when it arrives, and what deserves trust. The other three frame the decisions around it.
These principles interact. A more capable model cannot infer a private requirement it never received as context. A tighter control can prevent damage but also block a needed tool. Verification adds cost and often saves more rework than it consumes. Later lessons name the principle when it changes a concrete choice: capability when you give each agent its own model, context and cost when you hand a scan to a built-in subagent, and control across Permissions & isolation and again when you gate moves with plugin hooks.
Cost and control meet in an unattended run. A headless or CI job spends model calls and time with nobody watching, and an ask rule (a permission setting that pauses a tool for your approval) has nobody to answer it, so opencode run rejects the request instead (as of October 2026; run.ts source). What the run may do has to be settled before it starts: by the agent you pick, by that agent’s permission map (its allow, ask, and deny rules per tool), and by run flags such as --auto, which approves every request that is not explicitly denied (CLI documentation). Run OpenCode headless treats that map as a contract you decide in advance.
The curriculum
Section titled “The curriculum”Ten chapters, in reading order. Each works on the same illustrative feedmill project and stands on its own - start at the top, or pick the problem in front of you.
How to read it
Section titled “How to read it”Every chapter uses the same illustrative project, feedmill, and each page restates the project facts it uses, so a lesson stands on its own if you drop in from a search with one specific problem in front of you. Reading in order still helps, because later chapters assume the moves earlier ones teach. The habits from chapter one, reading the code before any edit and committing only after the tests pass and you have reviewed the diff, carry through every later chapter. LSP runs as a quiet through-line: you switch it on beside your editor in chapter one, and Extending treats it as the in-tree code-intelligence channel.
What you won’t find is a fixed template stamped onto every lesson. Some need a long worked transcript, some a single command and a warning, some a digression into why the tool behaves the way it does. The shape follows the content, the way a good book varies its chapters.