Providers & models

This is the chapter where OpenCode stops looking like a single-vendor terminal agent. As of September 2026, Claude Code is built around Anthropic’s models and Codex around OpenAI’s. OpenCode talks to whatever you point it at - Anthropic, OpenAI, Google, Groq, OpenRouter, a model running on your own laptop - and it lets you change that choice without leaving the session. More than 75 providers are supported as of October 2026, drawn from the Models.dev catalog behind the providers documentation. That isn’t a checkbox feature. Once you can put a different model behind every job, matching the model to the work becomes a capability decision and a cost decision at once: the model has to be smart enough for the task, and cheap enough for the volume.

The course’s illustrative project, feedmill, makes the stakes easy to see. feedmill is a small self-hosted feed aggregator - a Go CLI plus a sync server pulling RSS, Atom, and JSON feeds into one reading queue - and the jobs it throws at you are not the same size. A timezone bug buried in the Atom date parser, where a feed publishing +0530 lands in the reading queue five and a half hours off, is a finicky reasoning problem you want a strong, expensive model chewing on. A sweep across all hundred-odd configured feeds to find which ones still emit a deprecated field is bulk pattern-matching that a cheap, fast model finishes for a fraction of the cost. Run both through the same model and you’re either overpaying for the scan or under-powering the bug. By the end of this chapter you’ll stop doing that.

The five moves

• Wire up more than one provider so the choice exists at all - Wire up more than one provider
• Switch models mid-session with /models, without losing your place - the thread carries over, so the next model inherits the full conversation - Switch models without leaving the session
• Pin a model to each of OpenCode’s agents (built-ins such as build, plan, and the explore subagent, plus any you define) so a cheap scout scans while a strong model builds - Give each agent its own model
• Run the same task against two providers and diff the answers to settle a disagreement - Run two providers side by side
• Point OpenCode at a local or custom model for feeds you can’t send to a cloud API - and lean on Zen, OpenCode’s curated gateway (as of October 2026; Zen documentation), when you’d rather trust a vetted shortlist than benchmark the whole catalog - Drive it with a local or custom model

The moves compound. Wire two providers once and switching becomes a keystroke; pin a per-agent model once and every later fan-out of work across subagents (secondary agents with their own context, run by @mention or by the primary agent) inherits the cheap-scout / strong-builder split instead of re-earning it per task. Spend strong reasoning on the timezone bug and cheap throughput on the hundred-feed scan in one session, and keep a feed that can’t leave your network in a session of its own on a model that never touches the network. That session stays local only while every model it reaches is local, including small_model, the lightweight model that writes session titles, so point it at the local model too (local and custom models). A /models switch hands the whole thread, feed content included, to the next provider, and a subagent with its own model, such as an explore pinned to a cloud model, sends its prompt and everything it reads to that provider (task.ts in source, as of October 2026). OpenCode ships per-task provider switching as a first-class knob; out of the box, a single-vendor agent treats the provider as a fixed configuration choice. That knob is the lever this chapter hands you. Get the wiring right once and you stop thinking about it; the model just fits the job.