Pi

Pi is an open-source terminal coding agent by Mario Zechner, the author of libGDX. Its premise is simple: frontier models already know how a coding agent should behave, so the harness does not need thousands of tokens of system prompt or a dozen tools. Pi ships with four default tools (read, write, edit, and bash) and a short system prompt.

Why it is our top pick

• Transparent context. The system prompt is minimal and nothing is injected behind your back, so what the model sees is essentially what you gave it. Problems are easy to debug.
• Primitives, not features. Sub-agents, plan mode, permission gates, and sandboxing, which other tools bake in, are extensions in Pi. Write your own, install someone else's package (pi install npm:... / pi install git:...), or ask Pi to write the extension and /reload.
• Sessions are trees. Rewind to any earlier message, branch from there, and share the whole session.
• No model lock-in. It supports many model providers, so switching models does not mean switching tools.
• Reads AGENTS.md and Skills. Your project instructions and on-demand skill packages work across tools.

Trade-offs to know

Pi deliberately leaves out plan mode, to-do lists, and background bash: write plans to files, keep to-dos in TODO.md, and run long processes in tmux. It also does not ask for permission before acting, so you draw the safety boundary yourself: run it in a container or install a permission extension. If you want a complete experience with no setup, an IDE is a better fit.

Getting started

npm install -g @mariozechner/pi-coding-agent
cd your-project
pi

Before the first run, put an AGENTS.md in the project root (see the souvenir below) telling it how to install, how to test, and what not to touch.

# AGENTS.md

## Project
- One sentence on what this project does and who it is for.
- Stack: <framework / language / package manager>

## Commands
- Install: `pnpm install`
- Dev server: `pnpm dev`
- All checks: `pnpm check` (must pass before committing)

## How to work
- Read the relevant files and tests before editing; keep changes within the task.
- Run the relevant tests after each step. If they fail, find the cause; never delete tests or weaken assertions.
- Write plans to `PLAN.md` and to-dos to `TODO.md`, and keep them updated.
- Run long-lived processes (dev server, test watchers) in tmux so they do not block the session.

## Boundaries
- Do not commit, push, or rewrite Git history unless I ask.
- Do not read or print secrets from `.env*`.
- Do not hand-edit files under `src/generated/`.