TL;DR: Goose is an Apache-2.0 AI agent — now donated to the Linux Foundation’s Agentic AI Foundation — that installs, edits, runs, and tests code with any LLM. Point it at Ollama and nothing leaves your machine. The one setup trap that wastes everyone’s first hour: Ollama’s default context window is too small for Goose, and you must raise it.

What you’ll have running after this guide:

• Goose CLI (or desktop app) driving a local model through Ollama — zero API cost, zero data egress
• A context window large enough that Goose’s tool calls actually work instead of silently failing
• At least one MCP extension wired in, so the agent can touch your filesystem and shell

Honest take: Goose + Ollama is the real deal for privacy and cost, but the agent leans hard on tool-calling and long context. A 7B model on a small GPU will disappoint you. Give it a capable tool-calling model and 16GB+ of VRAM, or use it for scoped tasks and accept the ceiling.

What Goose is (and what changed in 2026)

Goose started at Block (the Square/Cash App company) and shipped in early 2025 as a local-first agent framework. In April 2026 Block donated it to the newly formed Agentic AI Foundation (AAIF) at the Linux Foundation, alongside Anthropic’s Model Context Protocol (MCP) and OpenAI’s AGENTS.md. The GitHub repository moved from block/goose to aaif-goose/goose.

If you saw earlier coverage calling the foundation “AIFF” — that’s a garbled acronym floating around. The official name is the Agentic AI Foundation, and its platinum backers include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI.

The practical facts as of July 2026:

• License: Apache 2.0 — commercial use, modification, and embedding with no source-disclosure obligation
• Latest release: v1.39.0 (June 25, 2026)
• Stars: ~50.6k
• Form factors: a Rust CLI plus a desktop app for macOS, Linux, and Windows
• Providers: 15+, including Ollama, OpenAI, Anthropic, Google, OpenRouter, Azure, and Bedrock
• Tools: capabilities come from extensions over MCP — a built-in “developer” extension gives shell + file editing, and there are 70+ community extensions on top

Goose is not a chat box. It’s an agent: give it a goal, and it plans, runs shell commands, edits files, and checks its own work in a loop. That’s exactly why the local-model story matters — you don’t want an autonomous agent shipping your codebase and shell contents to a third party.

How Goose compares to the other self-hostable agents

	Goose	OpenCode	Aider
Best for	Full task automation beyond code (shell, files, MCP tools)	Terminal-native coding across many providers	Git-native, patch-based code editing
License	Apache 2.0	MIT	Apache 2.0
Local via Ollama	Yes (built-in provider)	Yes (OpenAI-compatible config)	Yes (--model ollama/...)
Interface	CLI + desktop app	CLI	CLI
Extensibility	MCP extensions (70+)	MCP servers	Limited (edit formats, hooks)
The catch	Heavy tool-calling + long-context demands strain small local models	Younger ecosystem for non-code tasks	Focused on editing, not general agentic tasks

Goose’s differentiator is scope. Aider is superb at editing a git repo and staying in its lane. Goose will read your files, run a build, parse the failure, and try again — and with MCP it reaches beyond code into databases, browsers, and APIs. That power is also its tax: every turn ships a big system prompt plus tool schemas to the model, which is where local setups fall over if you skip the context step below.

For a pure coding-agent comparison against cloud tools like Cursor and Claude Code, see the coverage on aicoderscope.com. This guide stays on the self-hosted, Ollama-backed path.

Step 1 — Install Ollama and pull a tool-calling model

Goose is useless with a model that can’t call tools. In Ollama terms, you want a model with tool-calling support — plain chat models will make Goose fall back to conversation only, and every extension will be disabled.

Install Ollama (Linux one-liner shown; macOS and Windows have installers):

curl -fsSL https://ollama.com/install.sh | sh

Pull a model that does tool-calling well. Good 2026 choices for a local Goose:

# Solid all-rounder with tool support, ~5GB at Q4
ollama pull qwen3

# Stronger for coding/agentic work if you have the VRAM (~14GB)
ollama pull gpt-oss:20b

Confirm it’s there:

$ ollama list
NAME              ID              SIZE      MODIFIED
gpt-oss:20b       a1b2c3d4e5f6    13 GB     10 seconds ago
qwen3:latest      f6e5d4c3b2a1    5.2 GB    2 minutes ago

Rough VRAM guidance: a Q4 7B–8B model fits comfortably on a 12GB card; a 20B-class model wants 16GB or more, and you’ll be happier on 24GB. If you’re picking hardware for local agents, an RTX 3090 (24GB, used) remains the best price-per-VRAM option for this workload — the full breakdown lives on runaihome.com.

Step 2 — Install Goose

The cross-platform CLI install:

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

macOS users can also use Homebrew, and there’s a desktop app for all three platforms if you prefer a GUI. Verify:

$ goose --version
goose 1.39.0

Step 3 — Configure the Ollama provider

Run the interactive configurator:

goose configure

You’ll get a menu. Choose Configure Providers, then select Ollama from the provider list. Goose will ask for the host (accept http://localhost:11434 unless you moved Ollama) and the model name — enter the model you pulled, e.g. qwen3 or gpt-oss:20b.

Goose stores this in a config file at ~/.config/goose/config.yaml. You can edit it directly instead of using the wizard:

GOOSE_PROVIDER: ollama
GOOSE_MODEL: qwen3

Environment variables override the file, which is handy for one-off runs or when Ollama lives on another box:

export GOOSE_PROVIDER=ollama
export OLLAMA_HOST=http://localhost:11434
export GOOSE_MODEL=gpt-oss:20b

One gotcha worth knowing up front: if you set the provider both in the config file and via environment variables with conflicting values, Goose can get confused about which provider is active. Pick one source of truth. (This has bitten enough people to land as a tracked GitHub issue.)

Step 4 — The context-window fix everyone hits

This is the single most common reason a local Goose setup fails with a vague “Request failed” error. Goose sends a large prompt on every turn: a long system prompt, the descriptions of every enabled tool, and the running conversation. Ollama’s default context window is far too small to hold that, so the model silently truncates the tool definitions and the agent breaks.

The fix is to raise num_ctx for the model. The clean, persistent way is a Modelfile:

cat > Goosefile <<'EOF'
FROM qwen3
PARAMETER num_ctx 32768
EOF

ollama create qwen3-goose -f Goosefile

Then point Goose at qwen3-goose instead of qwen3. Expected result:

$ ollama create qwen3-goose -f Goosefile
gathering model components
using existing layer sha256:...
creating new layer sha256:...
writing manifest
success

Use at least 8k of context; 32k is a safer floor for real agentic loops. The tradeoff is VRAM — larger context costs memory — so on tight hardware, balance num_ctx against model size. If Goose starts a task, runs one tool, then loses the plot, undersized context is the first thing to check.

Step 5 — Run it

Start an interactive session:

goose session

Then give it a real task:

( O)> Create a Python script that reads sales.csv, computes total revenue per
region, and writes region_totals.csv. Then run it and show me the output.

Goose will use the built-in developer extension to write the file, execute it in your shell, read the result, and report back. Because you’re on Ollama, none of that — not the file contents, not the shell output — leaves your machine. Verify the point directly: with Ollama selected, watch your network monitor during a run and you’ll see no outbound traffic to any model API.

For non-interactive automation, goose run executes a recipe or a one-shot instruction and exits — useful in cron jobs or CI where you want the agent to do a scoped task headlessly.

Step 6 — Add an MCP extension

Extensions are where Goose gets its reach. Run goose configure again, choose Add Extension, and you can wire in community MCP servers — a fetch/browser tool, a SQLite or Postgres connector, a git server, and so on. Each extension exposes its tools to the agent through MCP, the same standard Goose now shares a foundation with.

Keep two things in mind on local models:

1. More tools = more context. Every enabled extension adds its tool schemas to each prompt. On a small model, enabling ten extensions can blow past your num_ctx and degrade quality. Enable only what the task needs.
2. Tool-calling quality is the model’s job. A model that’s mediocre at structured tool calls will misuse extensions no matter how good the extension is. This is why model choice matters more than extension count.

When NOT to use Goose on local models

Be honest with yourself about the ceiling:

• You need frontier-level reasoning on complex, multi-file refactors. Local 7B–20B models trail the cloud frontier badly on hard agentic coding. If correctness on a gnarly task matters more than privacy or cost, a cloud model — via Goose’s other providers, or a dedicated cloud coding tool — will finish where a local model spins.
• Your GPU is small (8GB or less). You can technically run Goose on a tiny model, but the combination of long context and heavy tool-calling means it’ll be slow and error-prone. Consider renting a GPU by the hour instead — a RunPod instance with a 24GB+ card runs a capable model for pocket change per hour, and you still control the stack.
• You want a plain chat assistant. Goose is an agent that acts. If you just want to chat with a local model, Open WebUI or Jan.ai is a better, lighter fit — see our Open WebUI setup guide.

Troubleshooting quick reference

Symptom	Likely cause	Fix
”Request failed” on first task	Context window too small	Raise num_ctx (Step 4)
Extensions do nothing / agent only chats	Model lacks tool-calling	Switch to a tool-calling model (qwen3, gpt-oss)
Wrong provider used	Config file + env var conflict	Use one source of truth
Very slow responses	Model too large for VRAM, spilling to CPU	Smaller model or bigger GPU
Agent loses track mid-task	Context truncation under tool load	Fewer extensions, larger num_ctx

FAQ

Is Goose really free for commercial use? Yes. It’s Apache 2.0, which permits commercial use, modification, and embedding in closed-source products without a source-disclosure requirement. Your only real cost on a local setup is the hardware and electricity.

Do I need the desktop app or the CLI? Either works. The CLI is scriptable and headless-friendly (great for recipes and automation); the desktop app is easier for interactive, exploratory work and shows Ollama’s installed models in a dropdown. They share the same config.

Which local model should I pick? Prioritize tool-calling ability over raw size. A model like qwen3 is a strong general default; step up to gpt-oss:20b for tougher coding and planning if you have 16GB+ of VRAM. Avoid chat-only models — Goose will disable extensions for them.

Why does my local Goose fail when the same task works on a cloud model? Two usual suspects: the context window is too small (raise num_ctx), or the model is weak at tool-calling. Cloud models paper over both because they ship with huge context and strong function-calling. Fix the context first — it’s the more common culprit.

Can I run Ollama on a separate machine and Goose on my laptop? Yes. Set OLLAMA_HOST to the remote server’s address (e.g. http://192.168.1.50:11434) and make sure that host is reachable and bound correctly. If you expose Ollama on a network, read our Ollama security guide first — exposed Ollama APIs are a real-world attack surface.

The verdict

Goose earns its Linux Foundation home: it’s a genuinely capable, genuinely open agent, and the Ollama path makes it one of the few autonomous agents you can run with zero data egress and zero per-token cost. The gap between “it installed” and “it works well” is almost entirely two things — a model that can call tools, and a context window big enough to hold Goose’s prompts. Get those right and you have a self-hosted agent that installs, edits, runs, and tests on your terms. Get them wrong and you’ll blame the model for a config problem.

Start with qwen3 at num_ctx 32768, add extensions sparingly, and scale the model up as your hardware allows.

Sources

• aaif-goose/goose — GitHub repository (release v1.39.0, June 25 2026; Apache 2.0; ~50.6k stars)
• Linux Foundation — Formation of the Agentic AI Foundation (AAIF)
• goose docs — goose moves to the AAIF (April 2026)
• Block — Block, Anthropic, and OpenAI Launch the Agentic AI Foundation
• Ollama — Goose integration docs
• harishkotra/goose-ollama-examples — local agent recipes
• The New Stack — Why Block handed Goose to the Linux Foundation