OpenCode, Pi, and Goose: Three Layers of the AI Agent Stack

There are many open-source AI agent tools now, but I do not think they all live at the same layer of the stack.

Three projects I have been looking at recently are:

• OpenCode: https://github.com/anomalyco/opencode
• Pi: https://github.com/earendil-works/pi
• Goose: https://github.com/aaif-goose/goose

They are easy to group together as “AI coding agents,” but that label hides an important distinction. My current mental model is this:

• Pi is closest to an agent kernel, agent harness, or agent toolkit.
• Goose is closest to a local AI agent workbench and orchestration surface for developers.
• OpenCode is closest to a coding-first software-development agent.

This is not a ranking. It is a layer distinction.

1. Pi: Agent Kernel, Harness, and Toolkit #

Pi feels less like a single end-user coding assistant and more like a foundation for building, studying, and extending agent systems.

The repository describes itself as the Pi agent harness project and includes packages such as:

• an interactive coding-agent CLI
• an agent runtime with tool calling and state management
• a unified multi-provider LLM API
• a terminal UI library

That structure matters. Pi is useful not only as something you can run directly, but also as a place to understand the moving parts of an agent system: model calls, tool calls, state, provider abstraction, terminal interaction, and workflow control.

A practical way to think about Pi:

• Use it if you want to understand how agents are built.
• Use it if you want a lower-level base for your own agent tools.
• Use it if you care about agent runtime design, provider abstraction, and reproducible workflows.
• Use it if you want to experiment with the structure of agent systems rather than only use a finished assistant.

One important detail is its permission model. Pi is explicit that it does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it. If you need stronger boundaries, you need to provide containerization or sandboxing.

That is not necessarily a weakness. In some ways it is a clear architectural statement: Pi is the harness; the security boundary belongs to the environment around it.

So I would not primarily describe Pi as “a coding agent.” I would describe it as an agent harness and toolkit that happens to include a coding-agent CLI.

2. Goose: Local Agent Workbench and Orchestration Surface #

Goose feels broader than coding.

The project describes itself as a native open-source AI agent with a desktop app, CLI, and API. It is positioned for code, workflows, and everything in between. It is also now part of the Agentic AI Foundation at the Linux Foundation.

That institutional context is interesting because Goose seems to be moving beyond the narrower idea of “AI programming assistant.” It looks more like a developer-facing agent workbench: a local system where models, tools, files, terminal workflows, APIs, and extensions can be brought together.

A practical way to think about Goose:

• Use it if you want a local AI agent workbench.
• Use it if you want desktop and CLI surfaces.
• Use it if you want provider flexibility.
• Use it if you want MCP-style extension workflows.
• Use it if your tasks are not limited to editing code.

Goose may be useful for coding, but I would not reduce it to coding. Its natural scope seems to include research, writing, automation, data analysis, and local developer workflows.

If Pi is closer to the harness layer, Goose is closer to the orchestration surface: the place where an agent becomes a usable local tool for a developer.

3. OpenCode: Coding-First Software-Development Agent #

OpenCode seems the most focused of the three.

Its positioning is direct: an open-source AI coding agent. It has a terminal UI, a desktop app, and built-in agent modes such as a full-access build agent and a read-only planning agent.

That makes its layer easier to understand. OpenCode is aimed at software development work inside repositories:

• exploring a codebase
• planning changes
• editing files
• implementing features
• running development tasks
• working through a software project

A practical way to think about OpenCode:

• Use it if your main task is software development.
• Use it if you want an agent that lives close to the repository.
• Use it if you care about planning and implementation workflows.
• Use it if you want a coding-first interface rather than a general agent platform.

OpenCode may have broader agent capabilities, but its center of gravity is software engineering.

Compared with Pi, it feels more like a finished coding-agent product. Compared with Goose, it feels less like a general local workbench and more like a specialized software-development harness.

A Simple Layer Model #

My current model is:

Pi
Agent kernel / harness / toolkit

Goose
Local AI agent workbench / orchestration surface

OpenCode
Coding-first software-development agent

Another way to frame it:

If you want to build agents, study Pi.

If you want to organize local agent workflows, study Goose.

If you want an agent for day-to-day coding work, study OpenCode.

Of course, these categories overlap. Pi includes a coding agent. Goose can be used for coding. OpenCode can perform agentic workflows. But their design centers feel different.

Configuration and Provider Questions #

For practical use, the comparison should not stop at positioning. The important operational questions are:

1. How easy is it to configure providers?
2. Does it support custom OpenAI-compatible base URLs?
3. How does it manage API keys and local credentials?
4. How does it handle model names across providers?
5. Does it support streaming reliably?
6. How does it handle tool calls?
7. How does it expose permission prompts?
8. Can it run inside a container or sandbox?
9. Can it be scripted or embedded?
10. How does it behave when a multi-step task goes wrong?

These questions matter more than benchmark-style comparisons. In real use, agent reliability is not just model quality. It is also context handling, tool design, permission boundaries, retries, failure recovery, and how visible the agent’s reasoning and actions are to the user.

When I Would Reach for Each One #

I would currently reach for Pi when the goal is learning or building the agent system itself.

For example:

• experimenting with agent loops
• studying tool calling
• building a custom agent
• designing provider abstraction
• controlling runtime behavior
• composing an agent with external sandboxing

I would reach for Goose when the goal is a broader local agent environment.

For example:

• using AI across coding and non-coding tasks
• connecting tools through MCP-style extensions
• combining desktop and terminal workflows
• building a local developer workbench
• automating research, writing, data, or workflow tasks

I would reach for OpenCode when the goal is coding inside a repository.

For example:

• exploring an unfamiliar codebase
• planning a change
• implementing a feature
• editing files
• running tests or development commands
• using an agent as a coding partner

The Main Distinction #

The distinction I find most useful is not “which is better?”

It is:

Which layer of the agent stack are you trying to work at?

If you are working at the agent architecture layer, Pi is especially interesting.

If you are working at the local workflow orchestration layer, Goose is especially interesting.

If you are working at the software-development task layer, OpenCode is especially interesting.

That layer distinction makes the ecosystem easier to understand. It also helps avoid comparing tools that are trying to solve different problems.

Open Questions #

The questions I still find most important are practical ones:

• Which tool has the best day-to-day ergonomics?
• Which one has the clearest permissions model?
• Which one works best with custom OpenAI-compatible endpoints?
• Which one is easiest to configure with multiple providers?
• Which one is most reliable in long multi-step tasks?
• Which one fails most transparently?
• Which one is easiest to extend without fighting the framework?

The answers probably depend less on the README and more on real workflow use.

My current conclusion is simple:

OpenCode, Pi, and Goose are not three versions of the same thing. They are better understood as three different layers of the open-source AI agent stack.

source & further reading

gist.github.com — original article Per-tab Claude Code session resume in agterm (zsh): each tab resumes its own conversation after a terminal restart Additional instructions for AGENTS.md focusing on token optimization Research Gate: Runtime enforcement hooks for Claude Code — blocks infrastructure commands without prior research