Goose + Ollama (2026): Run Block’s Open Coding Agent Locally

Yes — Goose, the open-source AI agent originally built by Block (Square/Cash App), runs completely locally on Ollama models with zero data leaving your machine. As of June 2026 the project lives at the Agentic AI Foundation (repo `aaif-goose/goose`, ~49,800 GitHub stars, Apache-2.0, latest release v1.38.0 on June 17, 2026), ships as a Rust CLI plus a desktop app, supports 15+ LLM providers including Ollama, and gains real tools through the Model Context Protocol (MCP). The catch is honest and important: Goose is only as autonomous as the model behind it, and small local models (7–14B) handle tool-calling far less reliably than frontier cloud models. This guide shows the exact local setup, a working example, and where the small-model walls actually are.

Most "run an AI agent locally" tutorials quietly assume you'll plug in Claude or GPT. Goose is different: it was designed from the start to work with any LLM, and the maintainers actively test it against local Ollama models. That makes it one of the few genuinely-local autonomous coding agents you can run today for $0 in API spend.

Heads-up on the name: you'll see this project called "Goose", "codename goose", "Block Goose", and "AAIF Goose". They're all the same agent. In early 2026 governance moved from Block into the Agentic AI Foundation under the Linux Foundation, so the GitHub repo redirects from block/goose to aaif-goose/goose. Block still drives most of the engineering.

What is Goose and can it run fully locally?

Goose is an on-machine, extensible AI agent — not a chat box. It plans a task, then actually executes it: it edits files, runs shell commands, installs packages, runs your tests, reads the output, and iterates until the job is done. The official tagline is "goes beyond code suggestions — install, execute, edit, and test with any LLM."

What makes the local story real:

• Any provider. Goose supports 15+ providers (Anthropic, OpenAI, Google, OpenRouter, Bedrock, Azure…) and — crucially — local ones: Ollama, Ramalama, and Docker Model Runner. With Ollama selected, nothing is sent to a third party.
• Open standard for tools. Capabilities come from extensions, which connect over the Model Context Protocol (MCP). The built-in "developer" extension gives Goose shell access and a file editor; the wider ecosystem adds 70+ community extensions.
• Two front-ends, one engine. A Rust CLI (goose session) and a desktop app. Both read the same config and providers.
• Truly free path. Goose itself is Apache-2.0. Pair it with an Ollama model and the entire stack is free and offline.

If you want the conceptual background on how a loop like this works — plan, call a tool, observe, repeat — read our walkthrough on how to build a local AI agent first; Goose is essentially a polished, production-grade version of that loop.

How do I install Goose?

You need two things: Ollama (to serve the model) and Goose (the agent).

1. Install and start Ollama

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

# Pull a tool-calling-capable model (see model section below)
ollama pull qwen3:8b

Confirm the server is up — by default Ollama listens on http://localhost:11434.

2. Install Goose (CLI)

# macOS / Linux one-liner
curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

On macOS you can also grab the desktop app from the releases page. Verify the install:

goose --version
# goose 1.38.0  (or newer)

Always pull the current release rather than hardcoding a version — Goose ships frequently (v1.38.0 landed June 17, 2026). The official source of truth is the Goose GitHub repository.

How do I configure Ollama as the Goose provider?

There are two equivalent ways: the interactive wizard or environment variables.

Option A — the wizard (recommended first time)

goose configure

Then:

1. Choose Configure Providers.
2. Select Ollama.
3. Confirm the host (default http://localhost:11434).
4. Enter the model name, e.g. qwen3:8b.

Option B — environment variables (great for scripts/CI)

export GOOSE_PROVIDER=ollama
export GOOSE_MODEL=qwen3:8b
export OLLAMA_HOST=http://localhost:11434   # default; only set if remote

goose session

If your Ollama runs on another box, point OLLAMA_HOST at it (e.g. http://192.168.1.50:11434). To use Ollama's hosted cloud instead of local hardware, set OLLAMA_HOST=https://ollama.com and add an API key — but that defeats the "fully local" point, so we'll stay on localhost.

Which local model should Goose use?

This is the decision that makes or breaks a local agent. An agent must emit structured tool calls, which is a much harder skill than chatting. Plenty of capable local models are weak at it. Below is a grounded comparison of practical picks (figures are approximate — throughput depends heavily on your hardware and quant).

Recommendation: start with qwen3:8b. The official Goose write-up "Goose and Qwen3 for Local Execution" reported a Qwen3 8B model at 4-bit quantization doing successful multi-turn tool calling — something that's historically been shaky at that size. If you have 16–24GB of VRAM, jump to qwen3:14b or the qwen3:30b-a3b MoE for fewer dropped tool calls on longer tasks.

What the arithmetic says about speed: you can bound throughput on paper, because local decoding is memory-bandwidth bound. At Q4_K_M a model moves roughly 0.6 GB of weights per billion parameters for every token it emits, and the ceiling is card bandwidth ÷ weight bytes. qwen3:8b is about 6 GB of weights, so against an RTX 3090's 936 GB/s the arithmetic upper bound is roughly 150 tokens/sec — with real output landing well below that once sampling, Goose's long system prompt, ~11 tool schemas and a 32K KV cache are all in the loop. Apple Silicon runs the same weights over unified memory at a fraction of a discrete card's bandwidth (Pro-tier chips sit in the low hundreds of GB/s against the 3090's 936), so the identical model has a ceiling several times lower on a laptop — consistent with the Goose project's own framing of local models on a 64GB M1 Pro as usable but noticeably slower. Treat every figure here as a ceiling your hardware cannot exceed, not a benchmark result; your actual mileage varies with quant, context size, and how many tools are loaded.

For a deeper ranking of which local models actually write good code, see our best local AI models for programming guide — just remember "good at coding" and "good at tool-calling" are different skills, and an agent needs both. If you want to see how the models that power agents like Goose stack up on real bug-fixing tasks, our best AI coding models ranked by SWE-bench leaderboard is the place to start.

How do I give Goose tools (extensions & MCP)?

Out of the box, Goose enables the developer extension, which is what turns it from a chatbot into an agent. It exposes tools such as:

• shell — run terminal commands (build, test, git, install).
• text_editor — view, write, and patch files.
• file/codebase helpers — list directories, search, read files.

That built-in developer toolkit ships roughly 11 tools, which matters for the small-model caveat below. You add more capability via MCP extensions:

# Launch the extension manager inside Goose
goose configure
#  -> Add Extension  -> Command-line Extension (an MCP server)
#  e.g. a filesystem, fetch, GitHub, or Playwright MCP server

Each extension is just an MCP server, so anything in the broader MCP ecosystem works with Goose. If MCP is new to you, our Ollama + MCP integration guide explains the protocol and how local models talk to MCP tool servers.

A real example: Goose fixing a bug locally

Here's an end-to-end local run. The point is to give Goose a small, verifiable task — which is exactly where local models succeed.

export GOOSE_PROVIDER=ollama
export GOOSE_MODEL=qwen3:8b
export OLLAMA_CONTEXT_LENGTH=32768

cd my-python-project
goose session

Then, at the prompt:

( O)>  The function average() in stats.py crashes on an empty list.
       Reproduce it by running pytest, then fix it so it returns 0.0
       for an empty list, and confirm the tests pass.

A capable local model will, on its own:

1. Call shell to run pytest and read the ZeroDivisionError.
2. Call text_editor to open stats.py and view average().
3. Patch it to guard the empty case (e.g. return 0.0 if not values else sum(values)/len(values)).
4. Re-run pytest via shell and report green.

That whole loop runs offline, on your CPU/GPU, with your code never leaving the machine. Scope is everything: "fix this one failing test" works; "refactor my entire service and add auth" will overwhelm an 8B model's planning. Keep tasks tight and let the agent iterate.

Speed tip for reasoning models: Qwen3 "thinks" before acting, which is slow on local hardware. Appending /no_think to the system prompt makes it skip the reasoning phase and jump to tool execution — faster and, per Goose's maintainers, often more reliable for short agent tasks (at the cost of being weaker on genuinely hard, multi-step work).