TL;DR: Goose has a native Ollama provider, so wiring it to a local model is a two-minute goose configure — no proxy, no OpenAI-compat shim, no base-URL surgery. It’s also the only agent in the local-first pack that ships a built-in fallback parser for qwen3-coder’s malformed tool calls. The catch is the same one every local agent has: Ollama’s 4,096-token default context silently cripples the agent until you raise it.

• What you’ll be able to do after this guide: run goose — shell commands, file edits, multi-step agent tasks, MCP extensions — entirely against a local Ollama model, with zero API spend and no code leaving your machine.
• What you’ll need: Ollama v0.32.x (current stable is v0.32.5, July 27, 2026), goose v1.44.0 (July 23, 2026), and realistically a 24 GB GPU or a 32 GB unified-memory Mac for the models that survive agentic tool calling.
• What you’ll avoid: the two failure modes that kill most goose + Ollama attempts — the silent 4K context truncation, and tool calls coming back as XML text instead of executing.

Honest take: Among the free local agents, goose + qwen3-coder:30b on a 24 GB card is the most forgiving setup you can build right now, specifically because goose parses Qwen’s XML-flavored tool calls instead of stalling on them the way Cline does. If your card has less than 16 GB, run goose against a cheap cloud model instead — a 7B model driving an 11-tool agent loop wastes more time than it saves.

Where goose sits in the local-agent lineup

Every local-first coding agent we’ve wired to Ollama this year — OpenCode, Kilo Code, Claude Code, Codex CLI — talks to the local daemon through some flavor of API-compatibility shim. Goose is the exception: Ollama is a first-class provider in its provider list, sitting next to Anthropic and OpenAI, configured with one environment variable (OLLAMA_HOST) and nothing else. There’s a reason Ollama’s own ollama launch integration picker (which covers Claude Code, OpenCode, Codex, VS Code, and Droid) doesn’t list goose — goose never needed the help.

Two things changed since our full goose review in June. The project completed its move to the Linux Foundation’s Agentic AI Foundation — the canonical repo is now aaif-goose/goose and the docs live at goose-docs.ai — and the release train kept rolling: v1.44.0 landed July 23, 2026, seven minor versions past the v1.37.0 we reviewed. Still Apache 2.0, still CLI plus Desktop, still free.

The pitch for running it against Ollama is the standard local-first trio: privacy (prompts and code stay on localhost:11434), zero marginal cost, and offline operation. What this guide adds is the part the official docs undersell — which models actually hold up under goose’s tool-calling load, and the two settings that decide whether the agent works or flails.

Pick a model before you configure anything

Goose leans on tool calling harder than most agents. Its default developer extension alone exposes 11 tools, and the official docs are blunt about the consequence: models without tool-calling support can only do chat completion, and you’d have to disable all extensions to use one. That rules out the bottom half of the Ollama library for agent work.

The docs point at the Berkeley Function-Calling Leaderboard for model selection, and their own walkthrough example is qwen2.5 — a model two generations stale at this point. Here’s the July 2026 reality on consumer hardware:

	qwen3-coder:30b	devstral:24b
Download size (Q4)	~19 GB	~15 GB
VRAM for weights (Q4_K_M)	~18.7 GB	~14.6 GB
Architecture	MoE, ~3B active per token	Dense
Speed on the same GPU	Faster	Slower
Tool-call reliability in goose	Good — XML quirk is auto-handled (see below)	Good — clean JSON
Fits on	24 GB GPU / 32 GB Mac	16 GB GPU / 24 GB Mac

qwen3-coder:30b is the default pick for the same reason it is in every other agent we’ve tested: the mixture-of-experts design activates roughly 3B parameters per token, so it’s fast for its quality tier. Its documented weakness — occasionally malformed tool invocations — matters less in goose than anywhere else, for a reason covered two sections down. devstral:24b is the dense fallback that fits a 16 GB card, at the cost of speed.

On hardware: a used RTX 3090 remains the cheapest 24 GB ticket into the top row of that table, and the spare ~5 GB after weights is exactly what the larger KV cache in the context-length section needs. For the full VRAM-to-model ladder, the sister-site breakdown at runaihome.com’s local models by VRAM guide covers every tier. No GPU at all? Renting one on RunPod and pointing OLLAMA_HOST at it is a legitimate middle path — remote hardware, but your own daemon and no per-token billing.

Step 1: Ollama running, model pulled

Install Ollama from ollama.com or your package manager, then in two terminals:

$ ollama serve
# leave this running

$ ollama pull qwen3-coder:30b
pulling manifest
pulling 8f2ea23eb1a4... 100% ▕████████████████▏  19 GB
verifying sha256 digest
success

Sanity-check the daemon before touching goose — this one curl rules out the entire connection-refused family of errors up front:

$ curl http://localhost:11434/api/version
{"version":"0.32.5"}

Step 2: Install goose and run goose configure

The CLI installs with one command (note the aaif-goose org — older guides point at block/goose, which redirects):

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

Homebrew users: brew install block-goose-cli (the formula kept its original name). Already installed? goose update brings you to v1.44.0.

Then run goose configure, choose Configure Providers, and pick Ollama:

┌   goose-configure
│
◇  What would you like to configure?
│  Configure Providers
│
◆  Which model provider should we use?
│  ○ Anthropic
│  ○ Databricks
│  ○ Google Gemini
│  ● Ollama (Local open source models)
│  ○ OpenAI
│  └

It asks for two values. The host — accept the default unless your daemon lives elsewhere:

◆  Provider Ollama requires OLLAMA_HOST, please enter a value
│  http://localhost:11434

And the model:

◇  Enter a model from that provider:
│  qwen3-coder:30b
│
└  Configuration saved successfully

Per the official provider docs, goose defaults OLLAMA_HOST to localhost:11434 if you leave it empty and prepends http:// when no scheme is given. If Ollama runs on another box (or that RunPod pod), set OLLAMA_HOST=http://{host}:{port}.

One naming trap while you’re in the provider list: Ollama and Ollama Cloud are different providers. The first is your local daemon. The second is a hosted service on ollama.com that wants an OLLAMA_CLOUD_API_KEY and sends your prompts to a datacenter — picking it defeats the entire point of this setup. Kilo Code users hit the identical trap in that tool’s picker.

The result lands in ~/.config/goose/config.yaml (Windows: %APPDATA%\Block\goose\config\config.yaml), which you can also edit directly:

active_provider: ollama
providers:
  ollama:
    enabled: true
    model: qwen3-coder:30b
    configured: true

For scripts and CI, the GOOSE_PROVIDER and GOOSE_MODEL environment variables override the config file per-process — handy for keeping a cloud model as your default and dropping to local for sensitive repos:

GOOSE_PROVIDER=ollama GOOSE_MODEL=qwen3-coder:30b goose session

The setting that decides everything: context length

Ollama serves every model with a 4,096-token default context window unless told otherwise. Goose’s system prompt, 11 developer tools, your .goosehints/AGENTS.md files, and the conversation itself blow through 4K before the model sees your actual request — and Ollama truncates silently, no error. The visible symptom, which goose’s own docs call out, is an agent that “has trouble using extensions” or ignores your hints file entirely. It looks like a dumb model. It’s a starved one.

Two ways to fix it, and they’re not equivalent:

Daemon-wide (recommended): set the context length where Ollama starts:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

32K is the working floor for agent use; 64K is better if your VRAM allows, since the KV cache for the bigger window is what that headroom on a 24 GB card is for.

Goose-side: goose has a lever most tools lack — GOOSE_INPUT_LIMIT maps directly to Ollama’s num_ctx on each request, and GOOSE_CONTEXT_LIMIT overrides what goose believes the model’s window is (for models goose doesn’t recognize, it falls back to assuming 128K — optimistic for a Q4 local model):

export GOOSE_INPUT_LIMIT=32768
export GOOSE_CONTEXT_LIMIT=32768

If goose behaves worse than the same model does in other tools, this mismatch — goose assuming a bigger window than the daemon is actually serving — is the first thing to check. The mechanics of why truncation breaks agents (and the same fix in Cline, Continue, and Aider) are in our Ollama context-length deep dive.

Related dial: GOOSE_MAX_TURNS caps how many turns goose takes without your input (default 1,000). On a local model that can wander, setting it to something like 25 keeps a confused loop from burning an afternoon.

The problem we hit: tool calls arriving as XML text

First agentic run with qwen3-coder in an older goose build, the model answered a “list the files and fix the failing test” task with a wall of text containing <tool_call> markup — and then did nothing. No file read, no shell command. The tool call was in the message, as prose.

This is a documented failure, not bad luck. Issue #6883 (filed February 1, 2026) pins it down: once qwen3-coder sees more than roughly 5–6 tool definitions via Ollama, it stops emitting structured JSON tool calls and starts writing XML-style invocations into the content field. Goose’s default developer extension alone is 11 tools, so a stock install triggers it immediately. Any agent parsing strictly reads that as a message with no tool call — which is exactly the stall we documented in Cline’s qwen tool-use loop.

The reason this section is short: goose fixed it at the parser level. PR #6882, merged February 7, 2026 and shipped in v1.24.0, added regex-based XML tool-call extraction as a fallback in the Ollama provider path — JSON tool calls take precedence, XML-in-content gets detected (including mid-stream) and converted into real tool requests. On v1.44.0 the same prompts that stall Cline just… execute. If you’re seeing XML-as-text today, you’re on a pre-1.24 build: run goose update.

Two residual pieces of advice hold anyway. Keep your enabled extensions lean — every extra MCP extension adds tool definitions, and local models degrade as the tool count climbs, fallback parser or not. And know the fallback is Ollama-provider-only; route the same model through a generic OpenAI-compat custom provider and you lose it. Broader JSON repair for sloppy local-model output is still an open feature request (issue #6688).

First session

$ goose session
    __( O)>  ● new session · ollama qwen3-coder:30b

Start small — “add a docstring to parse_config” — before handing it a refactor. Local models reward short, focused tasks; goose’s auto-compaction (which summarizes old context at 80% full) helps long sessions, but a 30B Q4 model is a competent assistant, not a Fable-class planner, and multi-hour agentic marathons are where that gap shows.

FAQ

Does goose Desktop work with Ollama too, or just the CLI? Both. In Desktop it’s Settings → Models → Configure providers → Ollama, and locally installed models appear in the model dropdown automatically. CLI and Desktop share the same config.yaml.

Can I use a model without tool-calling support, like a bare distill? Only for chat. Goose’s docs are explicit: without tool calling you must disable all extensions, which removes file edits, shell access, and everything that makes it an agent. Pick from Ollama’s tools-tagged model list instead.

Is goose + Ollama actually free? The software is Apache 2.0 and per-token cost is zero. The honest total cost is hardware and electricity — the runaihome VRAM guide has the amortization math. For the open-source ecosystem angle beyond coding agents, aifoss.dev tracks the FOSS AI stack.

My agent ignores .goosehints — broken install? Almost always the 4K context trap from this guide, not a broken install. Raise OLLAMA_CONTEXT_LENGTH (or set GOOSE_INPUT_LIMIT) and it starts obeying.

Sources

• Configure LLM Provider (Ollama section) — goose official docs
• Install goose — goose official docs
• goose repository (v1.44.0, July 23, 2026) — GitHub, aaif-goose/goose
• Issue #6883: Qwen3-coder tool calling fails with many tools via Ollama — GitHub
• PR #6882: XML tool-call parsing fallback for Ollama provider — GitHub
• Issue #6688: JSON repair/coercion for local models — GitHub
• Context window size default (4,096) — Ollama FAQ
• Ollama releases (v0.32.5, July 27, 2026) — GitHub
• goose moves to the Agentic AI Foundation — goose blog
• Linux Foundation announces the Agentic AI Foundation — linuxfoundation.org

Last verified July 28, 2026, against goose v1.44.0 and Ollama v0.32.5. Both projects release weekly; re-check the docs above before wiring this into anything permanent.