Goose: Block’s Free, Open-Source AI Coding Agent (What It Is + How It Works)

Goose: Block’s Free, Open-Source AI Coding Agent (What It Is + How It Works)

AI coding assistants are moving from “suggest the next line” to “run the workflow.” That shift is why local, open-source agents are getting attention right now.

One of the most talked-about new entrants is goose, an open-source, on-machine AI agent from Block.

In this post, we’ll keep it practical:

• •what goose is (according to Block)
• •how it differs from “chat + autocomplete” tools
• •how a common setup works (Goose + Ollama + a local coding model)
• •what to verify before you bet your dev workflow on it

What is goose?

Block describes goose as a local, extensible, open-source AI agent that automates engineering tasks.

Unlike code completion tools that stop at suggestions, goose is positioned to:

• •write and execute code
• •debug failures
• •edit and test changes
• •orchestrate workflows and interact with external APIs

Primary source: GitHub — block/goose

https://github.com/block/goose

Why “on-machine” matters (and when it doesn’t)

The headline benefit of an on-machine agent is straightforward: your prompts and code don’t automatically have to leave your computer.

That can matter for:

• •privacy-sensitive repos
• •regulated environments
• •cost control (if you run open-weight models locally)

But “local” doesn’t automatically mean “safe.” You still need to evaluate:

• •what tools the agent can run
• •what files it can access
• •whether it can reach the network
• •whether you (a human) must approve actions

In other words: the permission model matters as much as the model.

How people are using goose with local models (Goose + Ollama)

A common “free/local” stack is:

• •goose as the agent interface (desktop app or CLI)
• •Ollama as the local model server
• •a local coding model (for example, Qwen3-coder) running through Ollama

ZDNET walked through a setup where goose is configured to connect to Ollama, then the user selects a local coding model and runs a real coding task (iterating with retries when outputs don’t compile or behave correctly).

Source: ZDNET — “I tried a Claude Code rival that's local, open source, and completely free - how it went”

https://www.zdnet.com/article/claude-code-alternative-free-local-open-source-goose/

Practical takeaway

If you’re evaluating goose, don’t judge it by the first “hello world.” Test it on a workflow you actually run:

• •add a feature behind a flag
• •fix a bug with a failing test
• •refactor a module with a measurable performance constraint

And measure:

• •time-to-first-working-change
• •number of retries needed
• •whether it can run tests reliably
• •whether it stays within the repo boundaries you expect

Goose isn’t just a “coding app” — it’s an agent framework

An important distinction: goose is increasingly treated like an agent engine that can sit behind other automations.

For example, a Block goose blog post shows a developer experimenting with building an “OpenClaw-like” messaging bot using goose as the backend.

That post also highlights a reliability pattern that’s becoming common with agentic development:

• •Research first (collect real docs + constraints)
• •Plan next (break into phases)
• •Implement last (ship in chunks)

Source: Block goose blog — “How I Used RPI to Build an OpenClaw Alternative”

https://block.github.io/goose/blog/2026/02/06/rpi-openclaw-alternative/

What to watch before you adopt goose

If you’re thinking “this could replace my $X/month coding agent,” focus on the boring questions:

1) Action boundaries

Can goose:

• •modify any file on disk?
• •run shell commands?
• •make outbound network calls?

If the answer is “yes,” you want strong defaults (and ideally human approval) before you point it at anything important.

2) Repeatability

Agent workflows live or die by repeatability.

Run the same task twice:

• •do you get similar outcomes?
• •does it follow your repo conventions?
• •can it recover when tests fail?

3) Model choice and hardware reality

Local models are not “free” in practice:

• •they cost RAM/VRAM
• •they can be slow on weaker machines
• •large models can require significant storage

Your best setup might be hybrid:

• •local for sensitive work
• •hosted models for heavy lifting

Bottom line

Goose is one of the clearest signals that agentic coding is moving into a new phase: tools that can edit, execute, test, and iterate — not just suggest.

If you’re curious, start with a small repo, turn on the strictest permissions you can, and treat the first week as an evaluation period (not a migration).