Goose

Goose is Block's open-source CLI coding agent, built around MCP as its native extension layer. It runs in your terminal, brings its own model-agnostic core, and lets you wire in databases, browsers, and custom tools without writing adapter code. Free to use if you have an API key.

Block ships a lot of developer infrastructure. Square for payments, Cash App for consumer banking, Spiral for Bitcoin work. In late 2024 they shipped something different: Goose, an open-source autonomous coding agent designed from the ground up around MCP as its native extension layer. The bet is that the next wave of coding agents will be defined less by which model they use and more by how well they connect to the rest of your toolchain. If that bet plays out, Goose is positioned well. If you're evaluating CLI coding agents in 2026, it belongs in the shortlist alongside Aider and Claude Code.

Quick verdict

Goose is a serious open-source option for engineers who want autonomous coding in the terminal without paying a subscription and who care about tool extensibility. The MCP-native architecture is its clearest differentiator: connecting Goose to your database or internal APIs is a first-class workflow, not a workaround. It's newer and has a smaller community than Aider, so you'll hit rough edges in the docs. But Block is a real engineering organization and the release cadence has been consistent since launch. Worth your time if you're in the BYOK, CLI-first camp and want more tool connectivity than Aider offers out of the box.

What Goose actually is

Goose is an autonomous agent, not a pair programmer. That's a meaningful distinction. Tools like Aider are conversational: you describe a task, the model proposes edits, you accept or reject, and it commits. Goose is more hands-off by design. You give it a goal and it plans, executes, reads output, adjusts, and continues until the task is done or it hits something it needs to ask you about.

It runs in your terminal. There's no web UI, no GUI, no editor plugin. You install the binary, configure your model provider and any toolkits you want, and run it inside a project directory. The interface is a REPL where you describe tasks in plain English.

Block built Goose with MCP as the native layer for tool integration rather than bolting on tool support as an afterthought. In practice, this means you can wire in any MCP-compatible server and Goose will use it as a first-class tool during task execution. The out-of-the-box toolkit covers the basics: shell commands, file operations, and some browser automation. The real extension surface is MCP, and the ecosystem of MCP servers is growing fast.

The model situation is important to understand. Goose is model-agnostic by design. You bring your own API key for Claude, GPT, Gemini, or a compatible local model, and you configure it in a settings file. The quality of the agent's reasoning scales with the model you pick, just like every other BYOK tool. In practice, Claude Sonnet 4.6 is a reasonable daily driver; if you're doing complex architectural work, Claude Opus 4.7 or equivalent is worth the cost premium.

Features that matter

MCP toolkits as first-class extensions

Most coding agents support tool use in some form. Goose made MCP the center of its extension story, not a feature added later. The distinction shows up in how the toolkits work. You configure MCP servers in Goose's settings file, restart the agent, and they appear as available tools for any session. Goose will use them during autonomous execution when the task requires them, without you needing to specify which tool to use in the prompt.

Out of the box, Block ships several toolkits covering developer essentials: shell execution, file reads and writes, directory management, and basic web fetching. The community has published additional MCP servers for Postgres databases, GitHub operations, browser automation, Slack, and more. Connecting Goose to a running Postgres database, for example, means it can introspect your schema while writing migrations rather than guessing at column types. That kind of grounding is what separates "the model thinks it knows your schema" from "the model actually read your schema."

For teams building internal tooling, the MCP extension story means you can write a thin MCP server that wraps your internal APIs and expose it to Goose. Once that's in place, the agent can call your internal tooling the same way it calls a shell command.

Plan-and-execute with checkpoints

Goose doesn't just execute blindly. On tasks above a certain complexity, it produces a plan before starting: here's the sequence of steps I intend to take, here are the tools I plan to use, here's my approach. You can review this before execution begins and push back if the approach is wrong.

During execution, Goose surfaces checkpoints where it has made a decision with consequences you should know about: creating a file, running a shell command that modifies state, or deleting something. This is configurable. You can run Goose fully autonomously with interruptions disabled, or you can require confirmation at every action. For anyone using it on a production codebase for the first time, the confirm-everything mode is worth the slower pace. Once you've built trust with how it handles your specific stack, dialing down the interruptions speeds things up significantly.

The trick I've found is to be specific in the initial goal. "Add input validation to every user-facing form field in this Next.js app, using Zod, and update the corresponding API handlers to return structured errors" produces better plans than "improve input validation." The more context you front-load, the fewer clarifying interruptions you get mid-task.

Session context and memory

Goose maintains a session memory across a task run and can persist context in a project file, similar to how Claude Code uses CLAUDE.md. You can write down architecture decisions, preferred libraries, coding conventions, and Goose will carry those into every session on that project. It's a straightforward mechanism but effective for reducing the "re-explain the project context every session" tax.

Cross-session memory is less developed than Claude Code's auto-memory feature, which actively writes observations back to the project file. Goose's memory is currently more manual: you tell it what to remember and it does. That's honest about what it is and doesn't lead to stale or incorrect facts getting baked into the memory layer.

Model flexibility and provider switching

Because Goose doesn't care which model you use, you can make provider decisions based on cost and capability at the task level. Use a cheaper model for mechanical refactors where the changes are well-specified. Use a stronger model for architectural decisions where reasoning quality matters. Goose doesn't make that decision for you, which is sometimes a weakness (it doesn't auto-route by task type) and sometimes a strength (you stay in control of the API costs).

For engineers who want to run local models via Ollama or LM Studio on sensitive codebases, Goose's model-agnostic architecture means local model support is not a special case. Configure the compatible API endpoint and it works the same way as a cloud provider. The quality gap between current local models and frontier cloud models is real, but the option is there.

Pricing

Goose is free. The Apache 2.0 license covers commercial use, modification, and redistribution. Block made a deliberate choice to open-source the agent rather than build a commercial SaaS around it, at least for now.

Your real costs are API costs to the model provider you choose. A day of active work with Claude Sonnet 4.6, running maybe three to five hours of agentic sessions, will typically run between five and fifteen dollars depending on context window sizes and how many tool calls the tasks require. Autonomous agents tend to use more tokens than conversational tools because they do more back-and-forth reasoning internally. If you're using Claude Opus 4.7 for everything, that estimate climbs significantly.

The cost management strategy most engineers land on: set a daily API spend limit on your provider account, use Sonnet for the majority of work, and pull out Opus for sessions where the reasoning quality difference is worth paying for. Goose has no built-in cost tracking, so your provider's dashboard is where you monitor usage.

Compared to Claude Code at $17 a month (Pro plan) or Cursor at $20 a month, moderate Goose usage with Sonnet often comes in under those figures. Heavy autonomous sessions can exceed them. The BYOK economics work in your favor when you're disciplined about model choice.

Who Goose is built for

The clearest fit is backend engineers who want autonomous task execution in the terminal and have existing infrastructure they need the agent to interact with. If you're running Postgres, have internal APIs, or use services that have MCP servers available, Goose's toolkit architecture means those connections are natural rather than hacked together.

Open-source contributors who want a capable agent without subscription costs are another strong fit. Same story as Aider here: no corporate account, no seat license, just an API key and a git repo.

Teams evaluating whether to build internal AI tooling on top of an open-source agent will find Goose more forkable and extensible than managed tools. The MCP layer means you can add capabilities without forking the core.

Goose is not the right tool if you want an IDE-embedded experience, inline completions as you type, or a polished onboarding flow. It's a power tool. The docs are good enough and getting better, but there's still a "figure it out yourself" quality to some of the configuration that you don't get with a commercial product.

Goose vs the alternatives

Goose vs Aider

Aider is the most comparable tool in the open-source CLI space. Both are free, both are BYOK, both run in the terminal. The core difference is architecture philosophy.

Aider is git-first. Every accepted change becomes a commit. The safety mechanism is the commit log, and the workflow is conversational: propose, accept, commit, repeat. Aider is excellent at this and has three years of refinement behind it.

Goose is MCP-first and more autonomous. It will run a longer sequence of actions before surfacing for input. The toolkit layer means it can interact with systems beyond the filesystem in a way Aider doesn't natively support. Aider has a larger community and more documentation. Goose has better tool integration out of the box.

For pure coding tasks on a single codebase with no external dependencies, Aider is more mature. For tasks that require talking to databases, APIs, or other external systems, Goose's architecture is better suited.

Goose vs Claude Code

Claude Code is Anthropic's official terminal agent. It's also MCP-compatible, also autonomous, and also CLI-first. The differences come down to model lock-in, pricing structure, and polish.

Claude Code requires an Anthropic subscription and uses only Anthropic models. The $17/month Pro plan gives you Claude Sonnet 4.6. Goose costs zero dollars and lets you use any model. For engineers who want to use Claude anyway, this comparison tilts toward Claude Code for the tighter model integration and better-developed project memory. For engineers who want model flexibility or want to control costs closely, Goose wins.

Claude Code also has more mature project memory features (the CLAUDE.md system and auto-memory) and a larger user base producing community resources. Goose is newer and that shows in the ecosystem depth. Both are valid tools; the choice mostly comes down to whether you want to pay for a subscription or manage your own API spend.

Goose vs Cline

Cline is an open-source VS Code extension that takes a similar model-agnostic, BYOK approach to Goose but lives inside an IDE rather than the terminal. Cline has a visual interface, explicit approval flows for each action, and integrates with your editor's file view and diff UI.

Goose is the terminal counterpart to that experience. If you want a GUI and VS Code integration, Cline is the better fit. If you want a terminal agent that can run in headless environments, CI pipelines, or remote servers over SSH, Goose is more practical.

Getting started

Install the latest release from the GitHub releases page at github.com/block/goose. On macOS with Homebrew: brew install block/goose/goose. On Linux, download the binary from the releases page and add it to your PATH.

Once installed, run goose configure to set up your model provider. You'll need to provide an API key for whichever provider you're using. For Claude, set ANTHROPIC_API_KEY before running configure, or enter it interactively. Choose your default model (Sonnet 4.6 is a reasonable starting point).

Navigate into a project directory and run goose session. On first run in a new directory, it will ask if you want to create a project file for persistent context. Say yes and write two or three sentences about the project's stack and conventions.

Give it a real task for your first session, something that would normally take you twenty minutes and involves reading and modifying at least two files. Watch the plan it produces before it starts executing. That first plan review is where the tool's reasoning quality becomes clear. If the plan is off, push back before it starts; the correction costs less than undoing a wrong execution.

The bottom line

Goose is a legitimate open-source alternative to commercial coding agents, backed by a real engineering organization and built on an extension architecture that will matter more as the MCP ecosystem matures. It's not as polished as Claude Code and doesn't have Aider's years of community refinement, but it's also not a weekend side project. Block is serious about this.

For engineers who want autonomous CLI coding, model flexibility, and tool extensibility without a monthly subscription, Goose belongs on your evaluation list. The setup is real work, the docs have gaps, and you'll need to manage your own API costs. Those are known trade-offs for any BYOK open-source tool. What you get in return is an agent architecture that was designed for extensibility from day one, which is a meaningful technical advantage as the agent tooling ecosystem expands.

Key features

• Autonomous multi-step task execution in your terminal
• MCP-native architecture for connecting tools, databases, and APIs
• Extensible via community and custom MCP toolkits
• Works with Claude, OpenAI, Gemini, and local model providers
• Session memory and persistent context across runs
• Built-in toolkit for shell, files, and browser automation
• Plan-and-execute loop for safer autonomous operation

Pros and cons

Who is Goose for?

• Engineers who want an autonomous CLI agent without paying a monthly subscription
• Teams building internal tooling that connects Goose to their own databases and APIs via MCP
• Developers who want model portability and need to switch between Claude, GPT, and local models
• Backend engineers running autonomous refactors on large repos with custom tool integrations

Alternatives to Goose

If Goose isn't quite the right fit, the closest alternatives are aider , claude-code , cline , and continue . See our full Goose alternatives page for side-by-side comparisons.