Goose

Quick Verdict

Goose is a strong option for developers who want an open agent running on their own machine and capable of doing more than suggesting code. It can inspect and edit files, execute commands, use MCP extensions, and carry a multi-step task through tests and revisions from a desktop application, CLI, or API. That power is also its central risk: a local agent with shell, filesystem, browser, database, or deployment tools can affect real systems, so autonomy must be bounded by permissions and human confirmation.

Goose is not a free AI model. The framework is free and open source, but it needs a cloud model API, a supported subscription or coding agent through ACP, an enterprise endpoint, or a local model. The selected provider changes tool-call quality, regional availability, data flow, latency, and cost. Local inference avoids a per-token cloud bill but consumes hardware and may perform worse on planning and tool use.

As of July 21, 2026, the canonical repository is aaif-goose/goose, the latest official GitHub release is v1.43.0, and the code is licensed under Apache License 2.0. Goose is now part of the Agentic AI Foundation at the Linux Foundation. Official material currently describes 15-plus model providers and 70-plus MCP extensions; these ecosystem counts are snapshots, not durable guarantees, so selection should be based on the provider and tools a team actually needs.

Best For

• Developers who want one observable workflow for repository exploration, code changes, test execution, debugging, and documentation.
• Teams that need to choose among cloud APIs, enterprise model gateways, local inference, or existing ACP-compatible agent subscriptions.
• Organizations that already have internal MCP servers and want to expose narrowly scoped tools to a local agent.
• Engineers who want to capture a repeatable task as a Recipe with declared instructions, parameters, extensions, and dependencies.
• Users prepared to manage shell permissions, service credentials, logs, token budgets, version control, and human review.

Goose is not appropriate for users who treat “runs locally” as permission for unattended production access. Without branches, backups, secret management, and confirmation rules, its ability to execute can turn a plausible model mistake into an actual incident.

Key Features

• Local agent runtime: Runs as a native desktop application on macOS, Linux, and Windows, as a terminal CLI, or through an API for embedded workflows.
• Model and provider choice: Supports cloud APIs, enterprise endpoints, aggregators, and local inference through options such as Ollama and LM Studio. Compatibility and quality vary by model.
• ACP integration: Can communicate with external coding agents and may use existing supported subscriptions, subject to each provider’s limits and terms.
• MCP extensions: Connects the agent to developer tools, browsers, databases, APIs, and other services. The permissions of each server define the real blast radius.
• Recipes: Packages a workflow as shareable YAML with prompts, parameters, required extensions, and subrecipes for repeatable tasks.
• Project instructions and sessions: Keeps task context and allows repository-specific guidance, while creating data that needs retention and access controls.
• Security controls: Current documentation describes tool permissions, sandbox mode, prompt-injection detection, and an adversary reviewer. None removes the need for OS, repository, and service-level isolation.
• Open distribution: Apache-2.0 licensing and custom-distribution support allow organizations to preconfigure providers, extensions, and branding.

Use Cases

A common engineering workflow lets Goose inspect one repository, propose a plan, modify code on a temporary branch, run tests, diagnose a failure, and update the patch. The human should review the plan before execution and the diff afterward. Dependency installation, file deletion, system configuration, network access, publishing, deployment, and any production command should pause for explicit confirmation. For uncertain tasks, run Goose in a container, sandbox, disposable worktree, or otherwise isolated development environment.

MCP can extend the same workflow to issue trackers, browsers, databases, and internal services. Add extensions one at a time and audit their source, authentication method, tool schema, network destinations, and data policy. Disable unused tools. A database extension should receive a dedicated read-only role rather than a general production account; a deployment extension should not be present in an ordinary coding session.

Credentials should be isolated by project, environment, provider, and extension. Store them in an operating-system keychain, secret manager, or restricted environment variables, not in prompts, Recipes, project hints, source files, or chat history. Production identities must remain separate from personal and development credentials. Rotate and revoke keys independently so one compromised extension does not expose unrelated systems.

Useful audit records include the model, extension, tool, command, path scope, confirmation event, exit code, and change summary. Do not write raw tokens, passwords, or full sensitive file contents to logs. Define who can read sessions, where they are stored, how long they remain, and how deletion works. Local execution alone does not guarantee local data: cloud providers receive the context sent to them, and remote MCP servers receive the arguments and files required by their tools.

Pricing

The Goose desktop application, CLI, API framework, and source code are free under Apache License 2.0. Organizations may use, modify, and redistribute the software while complying with the license, copyright, and NOTICE obligations. The free classification does not include a model, cloud account, external API, hosted MCP service, or compute infrastructure.

Model spending depends on input and output tokens, prompt caching, context size, tool-result volume, retries, subagents, and the number of execution loops. An ACP integration may use an existing supported agent or subscription, but its quota and acceptable-use terms still apply. Local models replace token billing with GPU or CPU capacity, memory, power, maintenance, and often slower or less reliable tool calls. A cheaper model that repeatedly chooses the wrong command can cost more than a stronger model that finishes in fewer steps.

Teams should separate provider keys by project, set model allowlists and budgets, monitor token and cache usage, and alert on unusual retry or extension activity. Third-party MCP services may have independent subscription or usage charges that are not part of Goose.

Pros

• Apache-2.0 licensing and AAIF governance support inspection, customization, and vendor-neutral integration.
• Desktop, CLI, and API surfaces cover interactive work and embedded automation.
• Multiple providers, local models, ACP, and MCP reduce dependence on one model vendor.
• Recipes and project guidance can turn a successful procedure into a reviewable team asset.
• Current security features include permission controls and sandbox-oriented options rather than assuming unrestricted execution.

Cons

• Shell, filesystem, browser, and service access create a large blast radius unless tools and directories are tightly scoped.
• Provider quality varies substantially; weak planning and tool use can produce long, expensive, or unsafe loops.
• Community MCP extensions have independent code quality, permissions, maintenance, and data-processing policies.
• Sessions and tool logs can accumulate source code, business data, commands, and model output.
• Setup involves choosing and securing providers and extensions rather than receiving a single fully managed service.

Alternatives

FAQ

Is Goose free and open source?

Yes. The canonical repository uses Apache License 2.0, and the framework is free. Model APIs, paid agent subscriptions, external services, MCP products, and infrastructure may still cost money.

Does Goose require one specific model provider?

No. It supports multiple cloud, enterprise, aggregator, local, and ACP options. Choose a model with reliable tool calling; nominal provider support does not guarantee equal task quality.

If Goose runs locally, does my code stay local?

Not necessarily. Local files and commands are handled on the machine, but selected context may be sent to a cloud model. Remote MCP extensions also receive tool arguments and relevant data. A fully local provider and local toolchain reduce external transfer.

How can I stop Goose from running a dangerous command?

Restrict its working directory and enabled tools, use permission controls and a sandbox, and require explicit confirmation for installation, deletion, network, system, publishing, deployment, and production actions. Work on temporary branches and review every diff and test result.

How should Goose credentials be stored?

Keep provider and extension secrets in a keychain, secret manager, or restricted environment. Never put them in a Recipe, project hint, prompt, repository, or log. Use separate, least-privilege credentials for each project and environment.

How can a team control Goose model costs?

Use model allowlists, project-specific keys and budgets, limited context and extensions, caching where appropriate, and monitoring for retries and long tool loops. For local models, track hardware utilization, latency, and completion quality instead of token price.

Bottom Line

Goose is an open, local, and highly extensible agent runtime, not a free model or a reason to remove human oversight. Pilot it on one well-tested repository task in an isolated branch or sandbox and measure completion quality, command confirmations, MCP reliability, total model usage, and review effort. Production adoption should enforce minimum directory and tool permissions, per-environment credential isolation, explicit confirmation for high-risk commands, provider budgets, redacted audit logs, and mandatory diff, test, and human review before changes are accepted.