Pi Coding Agent Review: Minimal, Hackable AI Coding CLI

Pi Coding Agent is a minimal, open-source terminal coding harness that ships with four default tools and leaves most of the behaviour to extensions, skills and your own workflow. Most AI coding agents are becoming bigger products. They add planning modes, subagents, permission layers, IDE integrations, background workers and increasingly elaborate orchestration around the model. Pi takes almost the opposite approach: the default agent starts with four basic tools - read , write , edit and bash - while most of the interesting behaviour is deliberately left to extensions, skills, packages and your own workflow. This review is aligned with Pi v0.84.2, released on 14 August 2026. Mario Zechner created the project; it moved to Earendil Works in May 2026, which is why current packages use the @earendil-works scope rather than the older @mariozechner names. Pi has been changing quickly, so configuration and extension APIs deserve a version check before you standardise them across a team. The catch is equally important: Pi gives you considerably more control than many coding agents, and correspondingly more responsibility. It does not provide a built-in security sandbox or the kind of permission system developers may expect after using Claude Code or similar tools. Below I cover the quickstart, architecture, model support, extensions, session model, security implications and where I think Pi fits among modern AI coding tools. What is Pi Coding Agent? Pi is best understood as an agent harness rather than a finished, opinionated coding environment. That distinction matters: a coding model answers prompts, while an agent harness decides what context that model sees, which tools it can call, how tool results return to it, how sessions persist and what happens between turns. Pi makes almost all of those layers accessible, which is why it sits at the kit-building end of the AI developer tools field rather than among the batteries-included coding products. | Area | My rating | Why | |---|---|---| | Architecture | 9/10 | Small core with unusually clear extension points | | Model flexibility | 9/10 | Broad provider support and easy model switching | | Extensibility | 10/10 | TypeScript extensions can alter tools, events, context and UI | | Session handling | 9/10 | Tree-based sessions make experimentation unusually natural | | Initial usability | 8/10 | Easy to start, but advanced use expects technical confidence | | Safety defaults | 5/10 | No built-in sandbox or comprehensive permission boundary | | Team governance | 6/10 | Possible to build, but much is intentionally not built in | The strongest reason to use Pi is not that it has more features than competing coding agents - it does not. The reason is that Pi exposes more of the agent itself. That makes it particularly attractive to senior developers, platform engineers, AI tooling teams and anyone who has reached the point where the limitations of their coding agent are caused by the harness rather than the underlying model. Pi is less convincing for someone who wants to install an agent, approve a few safe defaults and never think about its architecture again: its minimalism is productive only if you value the control that minimalism creates. What Pi actually gives you The default model-facing tool set is intentionally small: read write edit bash Additional read-only tools including grep , find and ls are available, and recent Pi releases allow the initial built-in tool selection to be configured. The default looks sparse, and that is the point. Every additional tool increases the number of decisions the model has to make, expands the system prompt and creates another behavioural surface that may need debugging. Pi instead starts from a capable primitive set and lets you add specialised tools when your workflow actually needs them. The philosophy extends further than tools. Pi deliberately does not make built-in subagents or a mandatory plan mode central to the product; those behaviours can be implemented through extensions or installed packages instead. That makes Pi less convenient out of the box, but it gives developers more control over how those mechanisms are implemented. If you are used to Claude Code's built-in subagents, the Claude Code subagents guide is a useful reference for what you would be reimplementing. I find that approach slightly refreshing: Pi does not pretend there is one correct way to operate an AI coding agent. How to install Pi Coding Agent and start a session Install the current package from the @earendil-works scope. Older tutorials may still show @mariozechner packages from before the May 2026 move; those names are stale for new installs. The name also collides with oh-my-pi , a community fork of the Oh My Opencode harness. That project is unrelated to this coding agent; the Oh My Opencode review explains the fork if you landed on the wrong Pi. Install and authenticate - Install Pi globally with npm: npm install -g --ignore-scripts @earendil-works/pi-coding-agent --ignore-scripts disables dependency lifecycle scripts during install. Pi does not need those scripts for a normal npm install, and skipping them reduces a common supply-chain risk. - Verify the installation: pi --version - Enter a project and start it: cd /path/to/project pi Pi expects a bash-capable environment. On Windows, use WSL or Git Bash rather than cmd.exe . Pi supports interactive subscription authentication as well as API-key based providers. Inside Pi, the simplest route is: /login After authentication, select a model with: /model You can also supply provider credentials through environment variables. For example: export ANTHROPIC_API_KEY="your-api-key" pi Pi currently supports a broad collection of model providers, including OpenAI, Anthropic, Google, Azure OpenAI, Amazon Bedrock, NVIDIA NIM, DeepSeek, Mistral, Groq, Cerebras, Cloudflare, xAI, OpenRouter and several others. A llama.cpp router is also supported for locally served models: the llama.cpp quickstart covers serving GGUF models with an OpenAI-compatible API, and the LLM hosting guide maps the surrounding local, self-hosted and cloud runtimes if you want to compare that path with Ollama, vLLM or a hosted provider. Custom providers that speak a supported API can be added through ~/.pi/agent/models.json , and custom APIs or OAuth flows can be wired up with extensions. This multi-provider design is one of Pi's practical advantages. The model and the coding harness are separate variables: with Pi, you can change the model while keeping essentially the same tooling and session environment, which makes model comparisons considerably more meaningful than comparing completely different coding products. Start with a controlled first session I would not make your first Pi prompt "refactor my application". Start by asking it to inspect rather than modify: pi --tools read,grep,find,ls -p "Inspect this repository. Explain its architecture, identify the main entry points, and list the commands you would run before making a change. Do not modify files." When I ran that read-only prompt on an existing repository, the useful result was not a clever architecture essay. It was whether the model named real entry points and the commands I would actually run before asking for write access. That gives you a look at how the selected model navigates your tree without immediately granting it a write path through the normal tool set. For interactive work, I would also create a disposable Git branch first: git switch -c ai/pi-evaluation pi Pi can modify files in the working directory and can execute shell commands through bash , so Git remains one of the simplest practical rollback layers when evaluating it. If you want a test session that does not persist, pi --no-session runs in ephemeral mode. Project instructions belong in AGENTS.md . A useful starting file might look like this: # Project Instructions - Read the existing implementation before modifying files. - Keep changes narrowly scoped to the requested task. - Run npm test after code changes. - Run npm run lint before declaring the task complete. - Do not modify database migrations unless explicitly requested. - Do not access production infrastructure. - Explain any destructive command before running it. Pi also understands CLAUDE.md while walking project directories, and AGENTS.override.md can override the normal project instructions for a directory. Then give it a concrete task: Read the authentication module and its tests. Find one maintainability problem that can be fixed without changing public behaviour. Explain the proposed change first, then implement it and run the relevant tests. This is a better agent evaluation than asking it to generate a new toy application. Existing code forces the agent to discover constraints, preserve behaviour, choose relevant files and verify its work. Why Pi Coding Agent is an editable harness Pi's most important architectural idea is that the coding agent itself should remain editable. The extension system uses TypeScript modules that can register tools, subscribe to lifecycle events, intercept tool calls, inject or transform context, add commands and modify the terminal interface. Project-local extensions can also be reloaded with /reload , which makes experimenting with the harness surprisingly immediate. In simplified form, Pi looks like this: flowchart TD U[Developer] --> P[Pi Agent Harness] P --> M[Selected LLM Provider] M --> P P --> R[read] P --> W[write] P --> E[edit] P --> B[bash] X[TypeScript Extensions] --> P S[Skills] --> P C[Project Context] --> P PKG[Pi Packages] --> P R --> FS[Project Workspace] W --> FS E --> FS B --> OS[Shell and Toolchain] The diagram is simple because Pi is trying to keep the control plane simple. That gives you an unusual option: when the agent lacks a capability, you do not necessarily have to wait for the Pi maintainers to add it - you can add the behaviour yourself. An extension can create a new mode