Pi: the minimal, self-extending coding agent that writes its own tools

👁️ — views

Pi is an open-source terminal coding agent built around a sub-1,000-token system prompt and four core tools (Read, Write, Edit, Bash). Instead of shipping built-ins, it writes its own TypeScript extensions on demand. MIT-licensed, v0.78.1 (June 4, 2026).

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

What Pi is

Pi is an open-source command-line coding agent that takes the opposite bet from most 2026 harnesses: instead of a large system prompt and dozens of bundled tools, it ships a system prompt under roughly 1,000 tokens and only four core tools — Read, Write, Edit, and Bash. The pitch on its site is blunt: “There are many agent harnesses, but this one is yours.”

The project started as Mario Zechner’s work and is now developed under Earendil Inc., with contributions from Armin Ronacher (the creator of Flask and Jinja2). The code lives in the badlogic/pi-mono monorepo under an MIT license, and is published to npm as @earendil-works/pi-coding-agent. As of this writing the latest release is v0.78.1, tagged June 4, 2026, with a fast release cadence through May (v0.75 through v0.78).

The differentiator: it builds its own capabilities

The defining feature is self-extension. If a capability does not exist, you ask Pi to build it, and it writes a TypeScript extension module exposing new tools and instructions, which it can then call. That keeps the base context tiny while letting the surface area grow per-project. The repo also splits cleanly into reusable pieces: a provider-agnostic LLM layer (@earendil-works/pi-ai), an agent runtime (@earendil-works/pi-agent-core), a terminal UI library (@earendil-works/pi-tui), and the coding-agent CLI itself.

Pi advertises four operational modes — interactive, print/JSON, RPC, and an SDK — plus tree-structured session history and 15+ provider integrations. Recent releases show the practical edges of an automation-oriented tool: v0.77.0 added Claude Opus 4.8 support, --exclude-tools for selective tool disablement, and device-code auth for headless logins; v0.78.0 added named startup sessions via --name and clickable file paths via OSC 8 hyperlinks; v0.78.1 widened provider coverage.

How it compares

Getting started

Install globally with npm (the --ignore-scripts flag is the documented form), or use the install script:

npm install -g --ignore-scripts @earendil-works/pi-coding-agent
# or
curl -fsSL https://pi.dev/install.sh | sh

Then run pi in a repo and, when you hit a gap, ask it to build the missing tool rather than reaching for a plugin marketplace.

Practitioner note

The minimal-prompt approach is most attractive if you care about token budgets and reproducibility: a small base context means fewer hidden instructions steering the model, and per-project extensions are inspectable TypeScript you can diff and commit. The trade-off is that you are trusting the agent to author code it will then execute — the --ignore-scripts install flag and the documented containerization path are signals the maintainers expect you to sandbox it. Treat generated extensions like any other dependency: review them before they run with Bash access.

Under-considered angle

The interesting long-term question is whether “the agent writes its own tools” produces durable, shareable capabilities or a sprawl of near-duplicate one-off extensions across projects. A harness that lets each repo grow its own toolset trades the curation problem of a plugin ecosystem for a fragmentation problem — five projects may each reinvent a slightly different “run tests and summarize failures” tool. The teams that win with this model will likely be the ones who treat agent-authored extensions as first-class source code: versioned, reviewed, and promoted into shared internal libraries rather than regenerated from scratch each time.