If you’ve been using AI coding tools long enough, you’ve probably noticed that they all start to feel the same. Cursor, Claude Code, Codex, Amp — they’re converging on a set of common features: plan modes, permission popups, sub-agents, MCP integration, to-do tracking. More surface area, more abstraction, more decisions made for you.

Pi bets against this trajectory.

Originally created by Mario Zechner and now developed at Earendil Inc. (Zechner joined as a major stakeholder in April 2026, bringing Pi with him), Pi describes itself as “a minimal terminal coding harness.” That’s a design commitment, not marketing copy. Pi deliberately omits features that other tools consider table stakes, and replaces them with primitives you can build on. Whether that trade-off works for you depends heavily on what you actually need.

This post covers what Pi is, how it works, where it shines, and where its minimalism creates real friction. It is aimed at engineers who are already using coding agents and are evaluating whether Pi is worth switching to or adopting alongside existing tools.

Table Of Contents

• What Pi Is (and Isn’t)
• The Core Philosophy: Primitives Over Features
• What Pi Actually Does Well
  • Context Engineering
  • Session Management
  • Multi-Provider Mid-Session Switching
  • Extensibility via TypeScript
  • Benchmark Performance
• Where Pi Creates Friction
  • YOLO by Default
  • No Feature Parity Without Extension Work
  • Terminal-Only, No IDE Integration
  • Documentation and Community Size
• Who Should Try Pi
• Trade-offs Summary
• Getting Started

What Pi Is (and Isn’t)

Pi is a terminal-based agent harness available as an npm package (@earendil-works/pi-coding-agent). It supports 15+ LLM providers — Anthropic, OpenAI, Google, Azure Bedrock, Groq, Cerebras, Ollama, OpenRouter, and more — and lets you switch models mid-session with /model or Ctrl+L.

Install it with:

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

Then run pi in any project directory. Authenticate with /login for subscription-based providers, or set an environment variable like ANTHROPIC_API_KEY.

Pi is not an IDE extension, a GUI product, or a managed cloud service. It’s a CLI tool that writes to your terminal’s scrollback buffer. That framing matters because everything else about Pi follows from it.

The Core Philosophy: Primitives Over Features

Pi’s most striking characteristic is what it refuses to build. The “What we didn’t build” section on its homepage reads like a checklist of features every other coding agent advertises:

• No MCP support
• No sub-agents
• No permission popups
• No plan mode
• No built-in to-dos
• No background bash

In each case, Pi’s position is the same: these are problems you can solve with simpler primitives — files, bash, tmux, extensions — without baking them into the core.

This isn’t laziness. It’s a specific engineering stance. Pi’s creator has written extensively about why MCP (Model Context Protocol) servers, for example, are often worse than alternatives: popular MCP servers like Playwright MCP dump 13,700+ tokens of tool descriptions into your context window at session start, whether you need those tools or not. Pi’s preferred alternative is CLI tools with README files the agent reads on demand; you pay the token cost only when the tool is actually needed.

Whether you agree with these trade-offs depends on what you value. If you want batteries included, Pi will frustrate you. If you want full control over what enters your model’s context, Pi might be the most interesting tool in this space.

What Pi Actually Does Well

Context Engineering

The biggest practical differentiator is context control. Pi ships with a system prompt that comes in under 1,000 tokens total — system prompt and tool definitions combined. For comparison, Claude Code’s system prompt runs into the tens of thousands of tokens.

Pi uses AGENTS.md files (loaded hierarchically from ~/.pi/agent/, parent directories, and the current directory) for project-specific instructions. You can also replace the system prompt entirely with a SYSTEM.md file per-project. Nothing gets injected behind your back. Version 0.77 also added --exclude-tools (-xt) to disable specific built-in or extension tools per session, making it possible to trim the default toolset down even further.

Skills — Pi’s term for on-demand capability packages — are loaded only when invoked, not pre-loaded into every session. This means you can have a rich library of capabilities without paying context overhead on sessions that don’t need them.

For engineers who’ve spent time tuning prompts and wondering what exactly their coding agent is doing with the first 20,000 tokens of context window, Pi’s approach is a relief. The minimal system prompt source is visible and readable.

Session Management

Pi stores sessions as trees, not linear logs. Use /tree to navigate to any prior message, branch from there, and continue. All branches live in a single file. You can export sessions to HTML with /export, or upload to GitHub Gist and get a shareable URL with /share. An example shared session shows what this looks like in practice. Sessions can be named at startup with --name for easier identification in session history.

That’s a meaningful improvement over flat session logs, especially when you’re debugging and want to explore multiple approaches from the same point.

Multi-Provider Mid-Session Switching

Pi’s pi-ai library handles cross-provider context serialization, including converting Anthropic thinking traces to <thinking> blocks when switching to OpenAI, and vice versa. You can switch between Claude, GPT, Gemini, and self-hosted Ollama models within a single session. Token costs and context are tracked across the switch.

This isn’t flawless. Signed provider-specific blobs in message streams make cross-provider handoffs inherently lossy. But Pi handles it better than most tools that treat switching as a session-ending event.

Extensibility via TypeScript

Pi’s extension system is the most underrated part of the project. Extensions are TypeScript modules with access to tools, commands, keyboard shortcuts, events, and Pi’s custom TUI components. Built-in behaviors you might expect as defaults — sub-agents, plan mode, permission gates, sandboxing, MCP integration, custom editors — are all achievable as extensions and available as examples in the repository.

The 50+ extension examples include implementations of sub-agent spawning, path protection, SSH remote execution, and custom context compaction strategies. Extensions bundle into Pi packages installable from npm or git:

pi install npm:@foo/pi-tools
pi install git:github.com/badlogic/pi-doom

Benchmark Performance

Pi ran on Terminal-Bench 2.0 with Claude Opus 4.5 across five trials per task. Results placed it competitively against agents with significantly more complex tooling and system prompts, including Codex, Cursor, and Windsurf. These benchmarks are narrow and don’t represent real-world workloads, but they do suggest that a minimal system prompt and toolset doesn’t meaningfully impair the model’s ability to complete tasks.

The Terminal-Bench team’s own minimal agent, Terminus 2 (a raw tmux session with no specialized tools), also ranks competitively. Both data points support Pi’s thesis that frontier models don’t need elaborate scaffolding to perform well on coding tasks.

Where Pi Creates Friction

YOLO by Default

Pi runs with full filesystem access and can execute any command without permission checks. No confirmation prompts. No Haiku pre-screening of bash commands. No sandboxing. The author’s position is that permission systems in coding agents are “mostly security theater,” and there’s a reasonable argument for that, but the default is full trust, full access.

For personal workstations working on your own codebases, this is probably fine. For shared environments, CI pipelines, or situations where you’re working with sensitive data, you’ll need to build your own permission extension or run Pi in a container.

If you need safety rails out of the box, Pi is not the right tool today.

No Feature Parity Without Extension Work

The features Pi omits (MCP, plan mode, sub-agents, background process management) are useful in many workflows. Pi’s answer is “build it yourself via extensions,” which is a valid engineering answer but requires real investment. If you need Playwright automation or a 26-tool browser DevTools integration on day one, you’re either adapting Pi’s CLI-wrapper approach or giving up the feature.

The extensions ecosystem is growing, but it’s nowhere near the size of Claude Code’s built-in toolset. For teams adopting a tool without time to customize it, this is a real constraint.

Terminal-Only, No IDE Integration

Pi has no VS Code extension, no JetBrains plugin, no sidebar integration. It lives entirely in the terminal. For developers who work primarily in a terminal this is no loss, but for teams where the editor is the primary workflow surface, Pi doesn’t slot in naturally.

Documentation and Community Size

Pi is an MIT-licensed project from a single company (Earendil Inc.) with a Discord community and GitHub issue tracker. It’s newer and smaller than Claude Code or Cursor. Documentation is solid for core features but thinner for edge cases. If you hit an unusual problem, you’re more likely to need to read source code than find a StackOverflow answer.

Who Should Try Pi

Pi rewards engineers who:

• Value context control — you’ve already thought about what enters your model’s context window and want to manage it deliberately
• Work primarily in the terminal — the TUI is capable, but there’s no GUI escape hatch
• Are willing to build extensions — Pi’s power scales with your willingness to customize it
• Use multiple LLM providers — the multi-provider support is genuinely strong and mid-session switching is smooth
• Want to understand their agent — Pi’s small, readable codebase and minimal system prompt make it the most inspectable option in the space

Pi is probably not the right fit if you need a managed, low-configuration experience, work in an IDE-first workflow, or rely on MCP servers without wanting to invest in adapting them to Pi’s CLI-tool model.

Trade-offs Summary

Getting Started

# Install
curl -fsSL https://pi.dev/install.sh | sh

# Run in your project
cd your-project
pi

# Set your API key first (or use /login for subscription providers)
export ANTHROPIC_API_KEY=sk-...

The quickstart docs cover first-run setup, provider authentication, and basic usage. Mario Zechner’s original blog post goes deep on the architectural decisions behind pi-ai, pi-tui, and the core agent, and is worth reading if you want to understand the project’s design from first principles.

Final Thought

Pi is a deliberate counterargument to the direction most coding agents are heading. It trades features for control, and complexity for inspectability. That’s a reasonable bet if your pain with existing agents is that they make too many decisions for you — hiding context, injecting unknown tokens, running sub-agents you can’t observe.

If your pain is that you want a capable, well-maintained, fully-featured product that just works, Pi will require more from you than you might want to give.

The honest answer is that neither approach is universally correct. Your context determines which one fits.