Why we chose Pi over OpenCode, Goose, and first-party harnesses

We run a lean, senior-led product studio. AI is not the team; it is the multiplier. When we picked the coding harness that powers our daily work, we evaluated five serious options: OpenCode, Oh-My-Pi (Pi/OMP), Codename Goose, OpenAI Codex CLI, and Claude Code. The winner had to match three non-negotiables: human control over architecture, low friction for everyday work, and predictable cost as we scale.

Here is how the comparison broke down — and why we chose Pi.

The Decision Criteria

We did not look for the tool that matched our habits. We looked for the tool that matched how we deliberately choose to work:

• We want a fast terminal-native loop. We keep engineering close to Neovim, Herdr, and git because a lightweight TUI keeps the human in the loop and removes the friction of desktop GUIs.
• We insist on an explicit planning gate. No agent touches a client codebase until we have agreed on the blueprint. Senior review comes before execution, not after rework.
• We demand model flexibility. We route deep reasoning to one model and fast edits to another, and we refuse to be locked into a single vendor when open models like Kimi 3 are competitive.
• We design skills to load on demand. Reusable rules and conventions should enter context only when relevant, not bloat every prompt.
• We keep spec-driven workflows native. OpenSpec runs through standard commands; we will not duct-tape a new harness around our existing process.
• We reject forced scaffolding. We move across dozens of repos, so we choose a harness that works in any directory without an `/init` step.

The Contenders

OpenCode: structured, declarative, opinionated

OpenCode is the popular choice for good reason. It ships with first-class role-based sub-agents, `.opencode/skills/` and `.opencode/commands/` files, a dedicated plan agent, and a fast terminal UI. With more than 160k GitHub stars, it is a mature, well-supported harness.

For teams that want guardrails out of the box, it is excellent. For us, the same features became friction. Skill files can bloat the context window. Sub-agent roleplay configs are largely obsolete in 2026. And the `.opencode/` scaffolding assumes a workflow we do not always follow. We wanted a kernel we could extend, not a framework we had to fit into.

Goose: autonomous, MCP-first, system-wide

Codename Goose (built by Block, now under the Linux Foundation) is a different animal. It treats your machine as an operating system: 70+ MCP servers, a desktop GUI alongside its CLI, and the ability to jump between code, databases, issue trackers, and cloud APIs in one autonomous loop. It also supports ACP, which can reuse existing consumer subscriptions as model backends.

That power comes at a cost. Autonomous loops burn tokens fast. The planning-first "recipes" flow adds overhead when you just need a quick, bounded edit. And without tight scope boundaries, it can touch files you did not ask it to touch. For a studio that bills outcomes, not hours, unpredictable API spend is a real risk.

Pi / Oh-My-Pi: a lightweight, extensible kernel

Pi is not the tool we picked because it has the most features. We picked it because it gets out of the way.

Base Pi ships with a sub-600 line TUI. It keeps system prompts small, renders fast, and consumes minimal context tokens and system resources. That minimal core is intentional: instead of baking in heavy workflows, Pi gives us a TypeScript extension API we can shape to our process.

What made it the right fit:

• Neovim-like minimalism. A fast terminal-native harness that stays close to the keyboard and does not fight for screen real estate or attention.
• Extension-driven workflow. We do not depend on built-in plan modes or role presets. We add exactly the guardrails we need — a brainstorming lock, a model router, a plan-approval gate — as small TypeScript extensions.
• Low token and resource overhead. Small system prompts and on-demand skill loading keep API costs predictable and the TUI responsive, even in long sessions.
• Parallel processing without bloat. The extension system lets us fan out independent work across sub-agents and worktrees without the overhead of a heavy coordination framework.
• billion-context-pi extension. This was a key factor. It gives us the long-context handling we need without the cost or complexity of a first-party harness built around a single model.
• No lock-in, no forced setup. OMP reads OpenCode skills and MCP configs if a client brings them, and there is no `/init` step. We stay tool-agnostic and repo-agnostic.

Why we skipped first-party harness

OpenAI Codex CLI and Claude Code are polished, fast, and deeply aligned with their own models. They were the obvious commercial alternatives. Three concerns kept them off our stack.

1. Model lock-in. Codex is built around OpenAI models; Claude Code is built around Anthropic models. That is fine if you are committed to one provider, but model capability shifts quarter by quarter. We want to route the right task to the right model — today it might be Claude 3.7 Sonnet for reasoning, tomorrow it might be Kimi 3 or DeepSeek V4 for a fast edit pass. A first-party harness makes that routing harder and usually more expensive.

2. One-go execution is risky for brand-driven work. These tools are designed to take a prompt and run: plan, build, test, iterate in a single autonomous loop. For greenfield experiments that is impressive. For client work where typography, animation timing, voice, and conversion flow must stay on brand, “move fast and fix later” costs more than it saves. We have spent too much time undoing over-eager refactors that drifted off-brand.

3. Open models closed the quality gap. Open-access models such as Kimi 2.7 and Kimi 3 now perform on par with top closed models for the coding tasks we care about. When the model layer is commoditized, the harness layer becomes the differentiator. We would rather bet on an open, extensible harness than on a single vendor’s wrapper.

What we needed was a lightweight, open harness that lets us scope features into small, reviewable trunks, run multiple trunks in parallel under human supervision, and keep every decision aligned with the brand. Pi and OpenCode both fit that philosophy; Pi won on speed and token overhead.

Why we moved to Pi eventually

The decision maps directly to the five reasons clients work with us:

1. Veteran execution. 12+ years of hands-on delivery taught us where AI helps and where it gets in the way. Pi puts the senior engineer in control and uses AI for boilerplate, not architecture.
2. AI as accelerator, not replacement. Pi's minimal core and extension API amplify judgment instead of automating it. We add only the guardrails we need, keep token costs low, and run parallel tracks under human oversight.
3. Tool agnostic, no prerequisites. Pi reads OpenCode skills, OpenCode MCP configs, and standard agent skill layouts. The right tool is the one that serves the project.
4. Strategic and pragmatic. We scope work into reviewable trunks, customize the harness per project through small extensions, and never let the workflow dictate the delivery.
5. Holistic, end-to-end ownership. One continuous session tree carries context from discovery through implementation. No dropped state, no handoff gaps.

How it shows up in your projects

What this means in practice:

• Weekly demo builds stay intact because the plan is agreed before code is touched.
• API costs stay predictable because the lightweight harness keeps context windows compact and extensions route work to the cheapest suitable model.
• Features ship in scoped trunks. We break work into reviewable chunks instead of asking an agent to plan and build an entire feature in one pass. That prevents the back-and-forth rework that burns budget on brand-driven projects.
• Parallel tracks stay human-supervised. Lightweight open-source harnesses let us run multiple feature branches at once without losing oversight. Senior engineers review each trunk before it lands.
• Architecture decisions stay human because Pi's default mode is conversation and consent, not autonomous loop execution.
• Brownfield repos are safer because skills and prompts carry project-specific rules without rewriting the codebase.

READY TO SHIP YOUR VISION?

AI should accelerate execution, not replace the judgment behind it. If you want a senior-led team that uses the right tools under tight human control, let's talk.

Discuss Your Project With Us