Pi vs OpenCode: the minimal coding agent and the full one

The two on a fresh server

Installed side by side on an Ubuntu 24.04 cloud server on October 13, 2026, with each maker’s one-line installer and no account connected:

curl -fsSL https://pi.dev/install.sh | sh             # Pi
curl -fsSL https://opencode.ai/v2/install | bash      # OpenCode 2

OpenCode has two live versions, and the shorter address, https://opencode.ai/install, still gives version 1 (1.19.0); the OpenCode install guide covers the split. Pi moved to a new npm name in May 2026, @earendil-works/pi-coding-agent; the old @mariozechner/pi-coding-agent stops at 0.73.1 and is deprecated.

What each gives you before you add anything

Pi’s README states its design in one line: “Pi ships with powerful defaults but skips features like sub-agents and plan mode. Ask Pi to build what you want, or install a package that does it your way.” It starts with read, bash, edit and write, with grep, find and ls available but off. There is no web search tool, no background shell (its site says to use tmux) and no to-do list; MCP servers have been built in since September 2026. The guide to Pi sets out what it leaves out and why, in its makers’ words.

OpenCode builds those things in. Its agents page lists a Build agent that does the work, a Plan agent that “Explores and plans without editing normal project files”, and two sub-agents, General and Explore, that “run with fresh context in foreground or background child sessions.” It searches the web through one of five providers you choose on first use, runs long commands in the background, and has /undo, which rolls back the conversation and the files together. Version 2 does not run language servers, though its home page still lists “LSP enabled”; version 1 does, off by default.

The cost of Pi’s smallness is that you assemble more yourself; the payoff is a short system prompt, which leaves more of the model’s context for your work, and an agent you can change from inside a session: “If you need a command, tool, provider, workflow, or UI tweak, just ask Pi to build it”, its site says, then /reload.

Whether it asks before it acts

Neither stops to ask before ordinary work. Pi says so plainly in its security guide: it “does not ask for approval before every tool call.” It has no permission system to switch on; a confirmation step is something you build as an extension. What it does ask is whether to load a project’s own extensions, settings and skills the first time it finds them, which it calls project trust, and its guide is clear that this “does not limit what tool calls can access or affect.”

OpenCode has a permission system, and its default lets almost everything through. Its permissions page starts every agent from an allow-all rule with exceptions, and the agents page says the Build agent’s “sensitive environment-file reads and access outside the workspace ask for approval.” With 2.0.28 on October 13, run as opencode run in a git repository, it wrote a file and ran touch in the project without asking, refused to read the project’s .env (“This non-interactive run cannot ask the user for permission, so the request was rejected”), and read /etc/hostname and wrote a file outside the repository without asking. A rule for external_directory set to ask in the project’s opencode.jsonc did not stop the write either, and what does is not established here; so rely on where the agent runs, as the next paragraph says, rather than on that rule. Rules are a list of action, resource and effect, and “The last matching rule wins”. The permissions page’s own example asks before any shell command, allows routine Git inspection and blocks pushes, in opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "permissions": [
    { "action": "shell", "resource": "*", "effect": "ask" },
    { "action": "shell", "resource": "git status *", "effect": "allow" },
    { "action": "shell", "resource": "git diff *", "effect": "allow" },
    { "action": "shell", "resource": "git push *", "effect": "deny" },
  ],
}

Neither is a sandbox, and both say so. OpenCode’s security policy: “OpenCode does not sandbox the agent. The permission system exists as a UX feature” and “If you need true isolation, run OpenCode inside a Docker container or VM.” Pi’s guide calls running it “entirely inside a container, virtual machine, or sandbox” “usually the strongest practical option.” Either way, the files and keys the agent can reach are the ones its user account can reach, so a machine of its own, with nothing on it you haven’t given it, contains a mistake better than the laptop that holds everything. The guide to running agents without prompts compares how Claude Code and Codex handle the same choice.

Models, plans and keys

• A ChatGPT plan works in both. OpenAI’s Sign in with ChatGPT page lists OpenCode and Pi among its open-source integrations, and says “App usage counts toward your existing plan limits.”
• A Claude plan has a sign-in only in Pi, and Pi warns about it. Pi’s /login offers Anthropic, and once you use it, Pi 1.2.0 shows: “Anthropic subscription auth is active. Third-party harness usage draws from extra usage and is billed per token, not your Claude plan limits.” OpenCode 2 has no Claude sign-in at all; Claude models go in with an API key. Anthropic’s own pages read this more than one way, and the OpenCode pricing guide sets them side by side.
• GitHub Copilot works in both, and so do local models: OpenCode finds Ollama, LM Studio and vLLM running on the machine by itself; Pi connects to llama.cpp directly and to the others through its models.json.
• OpenCode’s free models need no account. Its FAQ: “Free models include Big Pickle plus promotional models available at the time, with a quota of 200 requests/day.” Its paid Go plan, $10 a month, also works from Pi, which takes an OpenCode key like any other provider’s.
• Signing in on a server. Pi’s Anthropic sign-in has a “Copy code login (headless)” choice beside the browser one, and for other providers its docs say to “paste the final redirect URL or authorization code back into Pi.” OpenCode’s providers page offers API keys, device codes and browser sign-ins, and reads keys from the environment without saving them.

Pi keeps keys and tokens in ~/.pi/agent/auth.json; OpenCode 2 keeps them in its database, ~/.local/share/opencode/opencode.db.

Extending them

A Pi extension is a TypeScript module that can add tools, commands, keyboard shortcuts, model providers or screens, loaded with no build step; Pi’s own examples include a sub-agent, a plan mode, a permission gate and protected paths. Extensions, skills, prompt templates and themes travel together as packages, installed with pi install npm:<package>, and Pi’s catalogue listed 5,468 on October 13. An extension “runs inside the Pi process with the same operating-system permissions”, so it can read whatever Pi can.

OpenCode adds plugins (packages or local files listed in opencode.json), custom agents and slash commands written as Markdown files, skills, and MCP servers. Plugins written for version 1 do not run in version 2. Both read skills in the shared Agent Skills format, and both route MCP tools through a small JavaScript runtime by default rather than listing every tool to the model. For instructions, Pi reads AGENTS.md or CLAUDE.md; OpenCode 2 reads AGENTS.md only.

On a server, and from your phone

This is where the two differ most. OpenCode 2 runs one background server per user account, and every client talks to it: the terminal interface, the desktop app, and a web interface it serves itself, “available by default and password protected” on port 49374, listening only on the machine. From a laptop you reach it through an SSH tunnel, and opencode pair prints one-time links that sign a browser in. opencode pair --remote goes further and, in its own warning, “will expose your OpenCode server to the internet”, through OpenCode’s tunnel service, OpenTunnel, with your server password as the lock. The guide to OpenCode’s web interface on a server covers both routes and what each exposes.

Pi has no server and no web interface. It is a terminal program, and its makers describe it as “built to run on your (remote) machine, inside a terminal, driven by one person.” On a server that means SSH and tmux, which keeps each Pi running after you disconnect; Pi’s tmux page asks for set -g extended-keys on so it can tell Enter from Shift+Enter. From a phone you reach it through an SSH app, or you run Pi on the phone itself, which Pi supports on Android through Termux. For scripts, Pi has a print mode (pi -p), a JSON event stream and an RPC mode for driving it from another program; OpenCode has opencode run, with --format json, and its server’s API.

Sessions are kept differently too: Pi writes each one as a JSON Lines file under ~/.pi/agent/sessions/, stored as a tree so you can branch from any earlier message, and OpenCode 2 keeps them in its database. OpenCode 2 cannot share a session yet; Pi’s /share uploads one as a private GitHub gist, or to Earendil’s Radius service when you have set that up.

Which to pick

• You want it to work on the first command, with a plan step, sub-agents and web search already there: OpenCode.
• You want to reach the agent from a browser or a phone without an SSH app: OpenCode, whose web interface is part of it.
• You want to try a coding agent with no account and no card: OpenCode’s free models.
• You want a small, predictable prompt and to build only the features you use: Pi.
• You want to sign in with a Claude plan: only Pi offers it, and Pi itself says the usage is billed per token as extra usage; for Claude models on your plan, Claude Code is the route Anthropic supports.
• You will leave it working unattended: either, inside a container or on a machine of its own, since neither will stop and ask.

Both are popular in their own right on October 13, 2026: OpenCode had 213,139 stars on GitHub and Pi 114,816, and Pi’s npm package was downloaded 4.2 million times in the week to October 11, though npm counts installs from every source and the two install through different routes. On what each scores with the same model, the evidence is thin; the Pi guide summarises the one independent test that ran both.