Pi vs opencode — a product and a toolkit, wearing the same clothes

On paper these two are the same tool twice. Pi and opencode are both MIT-licensed, both written in TypeScript, both terminal-first, both bring-your-own-model, both installable in one line. Every feature table that puts them side by side ends up with two nearly identical columns, and every one of those tables is useless.

The difference is not a feature. It is stated, in one sentence each, in their own READMEs.

opencode:

OpenCode includes two built-in agents you can switch between with the Tab key — build (full-access) and plan (read-only, denies file edits, asks permission before running bash commands).

Pi:

Pi ships with powerful defaults but skips features like sub agents and plan mode. Instead, you can ask pi to build what you want or install a third party pi package that matches your workflow.

Those are not two points on a roadmap. They are opposite answers to the same question, and everything else about the two projects follows from them.

A product versus a toolkit

opencode is shaped like a product. It installs through Homebrew, Scoop, Chocolatey, pacman, the AUR, mise, nix, or a curl-to-bash script. There is a beta desktop app with signed builds for macOS, Windows and Linux. The README is translated into twenty-two languages. It ships built-in agents, a subagent you invoke with @general, and a documented permission model.

Pi is shaped like a toolkit. It is a monorepo whose parts are meant to be imported separately:

Package	What it is on its own
pi-coding-agent	The interactive CLI — the part most people mean by “pi”
pi-agent-core	The agent runtime: tool calling and state management
pi-ai	A unified LLM API across providers
pi-tui	A terminal UI library with differential rendering

That table is the actual pitch. If you are building your own agent and want somebody else’s provider abstraction and terminal renderer, pi hands you those as libraries. opencode does not offer that, because it is not trying to.

So the first question is not which is better. It is are you adopting an agent, or building one?

The permission question

This is the sharpest practical difference, and it is the one most likely to decide the matter at a company.

opencode’s plan agent is read-only: it denies file edits by default and asks before running shell commands. You switch to it with Tab. It is there on first run, and it is the reason a lot of people are comfortable pointing opencode at an unfamiliar repository.

Pi has no permission system at all, and says so directly:

Pi 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.

This is a design position, not an oversight — the README goes on to document three containerisation patterns instead: a micro-VM extension that keeps pi and provider auth on the host while routing tools into a Linux VM, plain Docker for the whole process, and a policy-controlled sandbox.

Both answers are defensible. Neither is free:

• opencode’s in-process permission model is convenient and, like every in-process permission model, is enforced by the same program it is restricting. It raises the cost of an accident. It is not a security boundary.
• Pi’s position is that if you want a boundary, use a real one. That is more honest and strictly stronger — when someone actually does it. In practice a lot of people will run it straight on the host, and then there is nothing between the agent and their SSH keys.

If your environment requires that the tool refuse things, opencode does that today and pi does not. If your environment already puts development work in containers, pi’s position costs you nothing and opencode’s buys you nothing.

Extension: writing code versus writing config

Pi’s four built-in tools are read, write, edit and bash. Everything beyond that is something you add, in one of four shapes: TypeScript extensions, skills, prompt templates, and themes. Bundle them into a Pi Package and publish over npm or git.

The distinguishing detail is that extensions are TypeScript, not configuration. You are not filling in a schema someone designed for you; you are writing code against the runtime. That is more power and more maintenance, and which of those two words you noticed first is a good indicator of which tool you want.

The ecosystem is real rather than theoretical — pi-skills alone has around 2,500 stars, and there are separate published packages for diff review, review loops, transcription, Telegram bridging and session sharing. But note who wrote most of them: they come from the maintainers’ own accounts. That is a young ecosystem with a strong centre, not yet a broad one.

opencode’s extension story runs through configuration (opencode.json), a plugin mechanism, and the built-in agent definitions. Lower ceiling, lower floor, far more people who have already done what you are about to do.

Models: both agnostic, but not equally

Both let you bring your own model, and this is the dimension where the raw numbers actually diverge.

opencode advertises 75+ providers, sourced from Models.dev through the AI SDK, plus an escape hatch for any OpenAI-compatible endpoint. Pi maintains its own curated list of tool-capable models per provider, with automatic catalogue refresh, covering the major hosted providers plus Bedrock, Vertex, Azure, Groq, Cerebras, Mistral, DeepSeek, and Cloudflare’s two offerings.

Fewer providers, hand-checked for tool capability, is not obviously the worse deal — a provider in a catalogue that cannot reliably call tools is not a usable option for an agent. But if you need Ollama, LM Studio, llama.cpp or one of the long tail of gateways, opencode lists them and pi does not.

Both support signing in with a subscription rather than an API key: Claude Pro/Max, ChatGPT Plus/Pro, and GitHub Copilot. One caveat is worth knowing before you build a team workflow on it. opencode’s own documentation flags it explicitly:

There are plugins that allow you to use your Claude Pro/Max models with OpenCode. Anthropic explicitly prohibits this.

Pi lists Claude Pro/Max under its supported subscription logins without an equivalent note. That is a difference in how the two projects present the same grey area, not a difference in what the underlying vendor terms say — and if you are deciding for a company rather than for yourself, it is the sort of thing to check directly with the vendor rather than infer from a README.

What the numbers say, and what they do not

Checked against the GitHub API on 2026-09-08:

	Pi	opencode
Repository	earendil-works/pi	anomalyco/opencode
Stars	102,775	205,702
Forks	12,821	26,834
Open issues	156	5,718
First commit	2025-08-09	2025-04-30
Licence	MIT	MIT

Two of these rows are routinely misread.

The open-issue gap is not a quality signal. Pi auto-closes new issues and pull requests from new contributors by default, with maintainers reviewing the closed ones daily. That policy mechanically produces a small number. opencode’s 5,718 is what an open triage queue looks like at that scale. You cannot compare the two columns; you can only observe that the projects have opposite intake philosophies, which is the same story the rest of this comparison keeps telling.

Star counts measure attention, not fit. opencode has a four-month head start and a much wider distribution surface. What the numbers do tell you honestly: both are large, both are active — opencode was pushed to the day this was written, pi the day before — and neither is a weekend project you are gambling on.

One thing pi does that is worth flagging regardless of which you pick: it treats npm dependency changes as reviewed code changes. Exact-pinned direct dependencies, a two-day minimum release age to dodge same-day supply-chain incidents, a shipped shrinkwrap, --ignore-scripts in its own install instructions, and scheduled npm audit in CI. For a tool you are about to give shell access, that is not a small thing, and it is more than most agents in this category bother with.

Choosing

Take opencode if you want to install an agent and start working; if you want a read-only mode you did not have to build; if you need a provider from the long tail; if a desktop app or a non-English UI matters to your team; or if you would rather adopt the path several thousand people have already walked.

Take pi if you are building on the agent rather than only using it; if you want the runtime, provider layer or TUI as libraries; if your workflow already runs in a container so the missing permission system costs you nothing; or if your team’s instinct when a tool does not fit is to write fifty lines of TypeScript rather than to file a feature request.

Take neither if the model vendor and the tool are allowed to be the same decision. Both of these exist to keep those two decisions separate, and that separation costs configuration time and prompt quality. If you already pay for a plan and do not need portability, Claude Code or Codex CLI will be less work and better tuned. The comparison on this page is a real one, but it is only worth having if vendor independence is an actual requirement rather than a preference.

A note on how this was written

Every claim about behaviour, licensing, packaging and provider support here was taken from the projects’ own repositories and documentation, not from summaries of them. The star, fork and issue counts came from the GitHub API on 2026-09-08 and will drift.

One correction is worth recording: several third-party write-ups of pi cite around 46,000 stars and the npm package name @mariozechner/pi-coding-agent. Both are stale — the current figure is 102,775 and the published package is @earendil-works/pi-coding-agent. If a comparison you are reading gets those wrong, it was assembled from other comparisons rather than from the source.

Neither tool has been through a long hands-on trial by the author. Where this page makes a judgement rather than reports a fact, it is reasoning from documented design decisions, and it is labelled as such.

The two illustrations are generated rather than photographed or screenshotted. The architecture diagram is compiled from a typed specification of the facts above, so it carries no claim the text does not; the opening image is a metaphor and carries none at all.