Goose vs OpenCode
Two open-source AI agents that keep landing on the same shortlist. Goose is a general-purpose agent with two faces — a native desktop app and a terminal CLI — wrapped around an extensions ecosystem where every extension is an MCP server. OpenCode is a provider-agnostic terminal agent: a fast TUI you drive from the keyboard, with its providers and tools declared in one JSON file. Both are free, both are model-agnostic, both speak MCP. The split is about how much surface you want and where you want to work. Here is how to choose, with facts from each project’s repo and docs.
On this page · 9 sections▾
TL;DR + decision line
Pick Goose if you want a desktop-plus-CLI agent with a deep extensions ecosystem; pick OpenCode if you want a pure terminal agent with config-as-code. That one sentence settles it for most people. The rest is detail.
- Want a windowed app and a CLI in one tool? Install Goose. It ships a native desktop app for macOS, Linux, and Windows alongside a full CLI, and it treats every extension as an MCP server you add with
goose configure. It is also general-purpose — code, research, automation, data — not a coding-only harness. - Want to stay in the terminal, always? Install OpenCode. It is a keyboard-driven TUI with provider-agnostic config in
opencode.json, built so you never have to leave the shell. Its MCP servers and providers live in version control. - Can’t decide? Both cost nothing and install in minutes, so run both for a week. Most people keep one as the daily driver and reach for the other on specific tasks.
Neither is a thin wrapper around a single model. Both are bring-your-own-key and provider-agnostic, so the choice is not about which LLM you get — it is about the surface you want and where you want to work. If you’re weighing these two against Claude Code, Cline, and Aider as well, jump to the five-way roundup that compares all of them at once.
What these coding agents do
Both Goose and OpenCode are agentic tools: you describe a change in natural language, the agent reads the relevant files, proposes edits, runs commands, and iterates until the task is done. They are not autocomplete. They take a goal (“add a rate limiter to the auth route and write a test for it”) and work through it across multiple files, calling tools as they go. The human stays in the loop, approving or auto-approving the steps.
Where they diverge is the shape of the tool around that loop. Goose gives you two surfaces from one agent — a native desktop app and a terminal CLI — and leans into being general-purpose, so the same agent that edits code can also run research or automation. OpenCode is a single, focused terminal surface: a TUI you drive from the keyboard, configured through a JSON file. Both extend through the Model Context Protocol, so an agent in either tool can reach a database, a docs server, or a browser MCP without custom glue — the difference is how you wire those servers in.
Side-by-side matrix
Every cell is sourced from each project’s repository and official docs. Star counts and exact provider lists move; the shapes below do not.
| Dimension | Goose | OpenCode |
|---|---|---|
| Primary interface | Desktop app + terminal CLI (and API) | Terminal TUI (also desktop + IDE extension) |
| Scope | General-purpose agent (code, research, automation) | Coding agent |
| Maintainer | Agentic AI Foundation (started at Block) | Anomaly (anomalyco/opencode) |
| License | Apache 2.0 | MIT |
| Language | Rust | TypeScript |
| Model support | 15+ providers (Anthropic, OpenAI, Google, Ollama, OpenRouter, Bedrock…) | Any provider via API key (provider-agnostic) |
| MCP support | Yes — each extension is an MCP server (goose configure) | Yes — mcp block in opencode.json (local + remote) |
| Config | Interactive setup + config.yaml | config-as-code in opencode.json |
| Notable extra | Recipes (portable YAML), subagents, ACP server | Client/server design, language-server awareness |
| Cost (the tool) | Free, open source | Free, open source |
| MCP.Directory page | /clients/goose | /clients/opencode |
Two things stand out. First, Goose hands you more surface area — a desktop app, a CLI, an API, and a general-purpose remit — where OpenCode deliberately stays one focused terminal product. Second, both are genuinely model-agnostic, so anyone claiming one “only works with Claude” is wrong: Goose lists 15+ providers and OpenCode reads providers from config.
Goose — what it does best
What it does best
Goose is the most flexible agent in this pair. Its signature is breadth: one agent that runs as a native desktop app and a terminal CLI, framed as general-purpose rather than coding-only, sitting on top of an extensions ecosystem where every extension is an MCP server. That makes adding tools feel native — you are not bolting MCP onto a code agent, you are using the agent’s primary extension mechanism. Add Recipes (portable YAML workflows) and subagents, and Goose reads less like a single command and more like an agent platform you can shape to your team.
Pick this if you...
- Want a real desktop app and a CLI from the same tool, not a terminal-only experience
- Use the agent for more than code — research, writing, automation, data analysis all fit Goose’s general-purpose framing
- Want a deep, curated extensions catalog where adding a tool is the same as adding an MCP server
- Like capturing workflows as shareable Recipes your team can run, or spinning up subagents for parallel tasks
Where it shines: add a browser extension and capture it as a recipe
You run goose configure, pick Add Extension, choose Command-line, and point it at a stdio MCP server — say a browser automation server. Goose registers it in the extensions block of ~/.config/goose/config.yaml, and the agent can now drive a browser as part of its loop. Once the workflow works, you capture it as a Recipe: a portable YAML file with the instructions, the extension, and parameters baked in, ready to share with a teammate or run in CI. The desktop app gives you a chat-style view of the whole thing; the CLI runs the same Recipe headless. That “configure once, package, reuse” arc is where Goose pulls ahead.
Skip it if...
You want the leanest possible terminal agent and nothing else. A desktop app, an extensions framework, Recipes, and subagents are power when you need them and surface area you don’t when you just want a TUI in a tmux pane. If minimalism in the shell is the goal, OpenCode is the tighter fit.
Setup, config path, and compatible servers: /clients/goose.
OpenCode — what it does best
What it does best
OpenCode is the terminal agent that doesn’t feel like a compromise. It runs as a TUI you drive entirely from the keyboard, backed by a client/server architecture, with language-server awareness so the agent works from real symbol-level context instead of guessing from raw text. Because it is provider-agnostic and configured through a single JSON file, the whole setup is reproducible and version-controllable — the agent, its providers, and its MCP servers can all live in your repo and clone with it.
Pick this if you...
- Already work in a terminal-centric setup (tmux, SSH, remote dev boxes) and want the agent there, not in a GUI
- Want config-as-code: providers and MCP servers declared in
opencode.jsonand checked into version control - Value a fast, keyboard-only loop and a client/server design for driving the agent from scripts or a separate front end
- Want one terminal agent that can drive any model — Claude, GPT, Gemini, or a local model — without being tied to a vendor
Where it shines: an agent that lives on your dev box
You SSH into a remote machine, launch OpenCode in the repo, and point it at whichever provider your key allows. The agent reads code with language-server help, runs your build, and iterates — all inside the terminal you were already in, no port-forwarding a GUI back to your laptop. Add a database MCP server in the mcp block of opencode.json ("type": "local" with a command array for stdio, "type": "remote" for a hosted URL) and commit it, and the next engineer who clones the repo gets the same agent setup for free.
Skip it if...
You want a windowed desktop app or a general-purpose agent that ranges well beyond code. OpenCode is a focused terminal coding agent; it offers a desktop and IDE path, but the terminal is the center of gravity. If you want a native app, a broad extensions catalog, and a tool framed for research and automation too, Goose is the better match.
Setup, config path, and compatible servers: /clients/opencode.
Head-to-head: Goose vs OpenCode
Strip away the marketing and the comparison comes down to four practical questions.
How much surface do you want?
Goose gives you a desktop app, a CLI, and an API; OpenCode gives you one focused terminal TUI. Want a windowed app or options → Goose. Want a single lean shell tool → OpenCode. Answer this honestly about your own habits before weighing anything else.
How do you like adding MCP servers?
Goose makes it an interactive flow — goose configure → Add Extension — and an extension is an MCP server. OpenCode makes it a JSON edit in the mcp block. Prefer a guided prompt? Goose. Prefer config you commit? OpenCode.
Code-only, or more than code?
OpenCode is a coding agent and stays in that lane. Goose is general-purpose — the same agent handles research, writing, and automation. If your tasks spill past the codebase, that breadth leans Goose.
Which models matter to you?
Mostly a wash — both are model-agnostic. The nuance: Goose lists 15+ providers and lets you switch in the app or guided CLI, while OpenCode treats every provider the same way through opencode.json. If config-in-version-control matters, that leans OpenCode; if a guided picker matters, Goose.
The community read backs this up. In an r/LocalLLaMA thread asking whether anyone uses Goose, one developer captured its character cleanly — a tool you attach utility to rather than a purpose-built coder:
“I like it. It's an MCP client with what I consider a agentic utility metaphor rather than a purpose-built agentic coder. I mean, you can, but you have to work a little harder at it with the prompting. It's been baking for a few months now and is pleasant to setup and use.”
u/this-just_in · Reddit
r/LocalLLaMA — 'Anyone using Block's goose?'
That is a fair framing of the trade-off. Goose’s extensions-and-recipes model makes it a flexible agent platform; OpenCode’s tight terminal focus makes it a fast, predictable coding agent. Whether the extra surface is a feature or a distraction depends entirely on how you work.
Goose in action
If you want to see the desktop-app side of Goose before installing, the project’s own channel has a short walkthrough of building with it:
It is a quick look at the agentic loop — describe a change, let Goose execute and iterate — rather than a deep config tutorial. For the exact MCP-extension setup, the Goose setup page is the faster reference.
Frequently asked questions
Is Goose better than OpenCode?
Neither is strictly better; they optimize for different surfaces. Goose wins if you want a single agent that runs as a native desktop app and a terminal CLI, with an extensions ecosystem where each extension is an MCP server you add interactively. OpenCode wins if you live in the terminal and want a provider-agnostic TUI with config-as-code in opencode.json. The honest split most teams land on: Goose for an app-plus-CLI workflow and a richer extension catalog, OpenCode for a pure keyboard-driven terminal agent. Many people try both because both are free and open source.
Does Goose support MCP extensions?
Yes — MCP is central to Goose. In Goose, an extension essentially is an MCP server, and the project was one of the earliest MCP adopters with one of the deepest integrations in the ecosystem (its docs list 70+ documented extensions). You add one interactively with `goose configure` then Add Extension — choosing Command-line for a stdio server or Remote for a Streamable HTTP server — or you edit the extensions block in `~/.config/goose/config.yaml` directly. Goose Desktop can also render interactive UIs from an extension. See /clients/goose for the exact steps.
Goose vs OpenCode for local models?
Both can drive a local model, so this rarely decides it. Goose works with 15+ providers including Ollama, and the Goose Desktop and CLI both let you pick a provider without editing files. OpenCode reads any provider from API keys in opencode.json, which suits a scripted, reproducible local setup that lives in version control. For a laptop running a quantized model through Ollama, both work — pick Goose if you want a desktop or guided CLI flow for switching providers, OpenCode if you want the provider config committed to your repo.
Goose desktop vs OpenCode terminal — which surface fits me?
That is the core decision. Goose ships a native desktop app for macOS, Linux, and Windows on top of its CLI and API, so you can point-and-click through a chat-style agent and still drop to the terminal when you want. OpenCode is a terminal product first: its native interface is a TUI you run in your shell (it also offers a desktop app and IDE extension, but the terminal is where it is strongest and best documented). If you want a windowed app, Goose. If you want to never leave the shell, OpenCode.
Do Goose and OpenCode both support MCP servers?
Yes, both speak the Model Context Protocol. In Goose an MCP server is added as an extension via `goose configure` → Add Extension, or in the extensions block of config.yaml. In OpenCode you declare servers in the `mcp` block of opencode.json — `"type": "local"` with a command array for stdio servers, or `"type": "remote"` with a URL for hosted ones, and an `enabled` flag to toggle them. See the setup pages for each: /clients/goose and /clients/opencode.
Are Goose and OpenCode free?
Both clients are free and open source — Goose under Apache 2.0, OpenCode under the MIT license. Neither charges for the agent itself. What costs money is the model you point it at: a hosted API (Claude, GPT, Gemini) bills you per token, while a local model through Ollama costs only your own hardware. There is no subscription gate on either tool to add MCP servers or run agentic loops.
Is Goose only for code?
No. Goose describes itself as a general-purpose AI agent that runs on your machine — useful for research, writing, automation, and data analysis as well as code. That breadth is part of its character: it behaves like an agentic utility you can attach tools to, rather than a coding-only harness. OpenCode is more tightly framed as a coding agent. If your tasks range beyond the codebase, Goose's general-purpose framing and extension catalog give it more room; if you only want a code agent in the terminal, OpenCode stays focused.
Who maintains Goose and OpenCode?
Goose began at Block and is now developed in the open as part of the Agentic AI Foundation at the Linux Foundation, which keeps it vendor-neutral and community-governed; its repository is one of the more active open-source agent projects, built in Rust. OpenCode is developed in the open under the anomalyco/opencode repository and written in TypeScript. Both are actively maintained with frequent commits. If you are weighing them against Cline, Aider, and Claude Code too, the five-way roundup linked below puts all of them side by side.
Sources
Goose
- block.github.io/goose — docs home (desktop + CLI + API, 15+ providers, MCP extensions, Recipes, subagents, AAIF)
- github.com/aaif-goose/goose — repo, Apache 2.0, built in Rust
OpenCode
- opencode.ai/docs — terminal interface, providers, MCP config (
mcpblock, local + remote) - github.com/anomalyco/opencode — repo, MIT, TypeScript
Community & video
- r/LocalLLaMA — “Anyone using Block’s goose?” — the discussion quoted above
- Build Apps Faster with AI | Vibe Coding with Goose — goose OSS channel
Related
- /blog/goose-vs-cline-vs-aider-vs-claude-code-vs-opencode-2026 — the five-way roundup these two come from
- /blog/cline-vs-opencode-2026 — OpenCode against an editor-native agent
- /clients/goose — Goose MCP setup guide
- /clients/opencode — OpenCode MCP setup guide
- /blog/what-is-mcp — what the Model Context Protocol is