Pi: the minimal coding agent that runs in your terminal and does not try to be Claude Code

Pi is a 100% open-source minimal CLI agent that does not try to be Claude Code. No MCP setup, no sub-agents, no permission pop-ups, no skills system, no checkpoints, no plan-mode-vs-act-mode toggle. It runs commands. That is the entire pitch, and after a week of using it as the primary agent for infra-as-code work on a personal homelab, it is the right tool for a specific kind of working engineer that the heavyweight agentic tools have started to under-serve.

This piece is the working read after seven days of running Pi against Ansible, Terraform, Docker Compose, and Kubernetes manifests on a homelab, cross-checked against the three best independent-creator videos that landed through the back half of May.

What Pi actually is

Christian Lempa’s “Pi: Open-Source AI Agent Terminal Set-Up” (May 19) is the cleanest single intro to Pi for the homelab-and-infra audience. His framing in the first sixty seconds captures the segmentation that explains why Pi has gained adoption among working homelab engineers:

“While most other tools and agents built by these huge platforms like Claude Code or OpenAI’s Codex, they just try to add more and more features, Pi is much more direct. There is no MCP setup. There are no sub-agents. There are no permission pop-ups. This is really just using plain CLI tools and commands. And this is absolutely incredible. It is also completely open. So it supports more than 15 different providers and you can use API keys. You can use OAuth with your existing subscriptions and you can even use local LLMs.”

The product Pi is competing against is not Claude Code or Codex CLI. It is competing against the engineer’s habit of typing commands directly. The Pi pitch is “the same agent loop you would run yourself if you were patient enough, with the engineer’s discipline of plain commands and no hidden state.” That is the right pitch for the homelab-and-infra audience because the heavyweight tools’ assumptions — that the agent should manage permissions, that the agent should checkpoint, that the agent should maintain a skills catalogue — are wrong assumptions for infrastructure work. Infrastructure work is destructive by nature. The engineer wants to see every command before it runs. The “hidden state” the bigger tools maintain on the engineer’s behalf is a footgun when the commands run against production.

What Pi gets right for infra-as-code

After a week of running Pi against a mixed Ansible / Terraform / Docker Compose / k8s manifests workload, the working observations:

Plain command flow. Pi presents each command before running it, runs it on confirmation, shows the output, and reasons about the next command. No tool-call abstraction, no MCP layer, no sub-agent dispatch. The agent loop is visible at every step. For infra work, this matches how a careful engineer actually wants to work.

Multi-provider model selection. Pi supports 15+ model providers including local LLMs via Ollama, LM Studio, or direct llama.cpp endpoints. The setup is a single config file. For homelab engineers who want to run the agent against a locally-hosted DeepSeek V4 Flash or Qwen 3.6 35B — and not send their infrastructure secrets to a closed-model API — Pi is the right tool. The cloud agents (Claude Code, Codex CLI) can also be pointed at local models via routing, but the friction is meaningfully higher.

No persistent state by default. Pi sessions are ephemeral. The agent does not remember a previous session unless you explicitly feed in the transcript. For infra work this is a feature — every session starts from a clean reasoning baseline rather than carrying assumptions from a previous session that the underlying infrastructure has since changed.

Direct support for terminal emulator integrations. Lempa specifically calls out Warp’s third-party CLI agent integration (Warp went open-source recently — a separate development worth knowing about) — but Pi also works cleanly in iTerm, kitty, Alacritty, and the macOS / Linux defaults. The agent surface is “any terminal.”

Where Pi is not the right tool

The trade-offs that come with the minimal design:

No MCP ecosystem. If your workflow depends on the Claude Code MCP server catalogue — Postgres, Playwright, GitHub, Figma — Pi is not the right tool. The minimal design means none of that ecosystem is available. You can compose the same workflows via shell commands but you do the composition yourself.

No sub-agents or parallel dispatch. Pi is one agent thread. If your workflow involves running multiple agents in parallel on independent slices of a problem, Pi does not have a native abstraction for this — you run multiple Pi instances in separate terminal panes, which works but is the manual version.

No checkpoints or revert. Pi does not maintain shadow folders or per-step checkpoints. If the agent makes a change you want to revert, you use git. That is the right pattern for infra-as-code (your Ansible / Terraform / k8s manifests should all be in version control anyway) but it does require git discipline.

Smaller community. Pi is newer and the community is smaller than Claude Code’s or Cline’s. When you hit an edge case, Stack Overflow probably does not have your answer yet.

What the IndyDevDan videos add

IndyDevDan ran two Pi-focused videos through the May–June window that are worth knowing about even if you do not watch them. “Pi to Pi: Two-Way Agent Orchestration with the Pi Coding Agent” (May 18) covers the pattern of running two Pi instances and having them collaborate on a goal — one Pi planning, one Pi implementing, with markdown handoff between them. It is the manual sub-agent pattern, and it works.

“Pi Coding Agent Observability: HTML Specs with Gemini 3.5 Flash and GPT Image 2” (June 1) is the more advanced workflow video — Pi pointed at Gemini 3.5 Flash as the cheap-tier model, generating HTML specs for documentation, with GPT Image 2 generating diagrams alongside. The combined pattern is the “agent stack” approach where Pi is the orchestrator and the specific models are routed by task type. This is the workflow most working engineers will actually adopt if Pi sticks for them.

The interesting framing across both Dan videos is the same one Lempa lands on: Pi is the minimal-substrate tool that lets you compose your own workflow. It is the Unix-philosophy version of an agent. Each component does one thing well; you compose them yourself. For engineers who want a Claude-Code-style “everything in one place” experience, Pi is the wrong choice. For engineers who want to build their own agent stack from primitives they control, Pi is the right substrate.

What this means for working engineers right now

Three practical implications:

1. If your work is heavily infra-as-code (Ansible, Terraform, k8s, Docker), try Pi for a week. Run it against a local LLM or against an Anthropic / OpenAI key. Compare against your current Claude Code or Codex CLI workflow on the same kind of work. The Pi loop is meaningfully better for infra precisely because the lack of hidden state matches how you should work on infrastructure.

2. Pi is the right tool for “I do not want to leak my infrastructure to a closed-model API” workflows. The local-LLM support is first-class. Combined with Hermes Agent for the broader open-model agentic-engineering work, the open-stack story for serious homelab engineers is now genuinely complete in a way it was not three months ago.

3. Do not migrate from Claude Code or Codex CLI to Pi as a general replacement. Pi is for the specific slice of work where minimalism is the feature. For agentic coding on application code where you want the MCP ecosystem and sub-agents, the heavyweight tools remain the right choice.

Creator POV vs the dissent

The creator coverage of Pi has been small but consistent — Lempa for the homelab-and-infra audience, IndyDevDan for the agentic-engineering audience. Both are positive in the same specific way: Pi is the right tool for a specific kind of work, not a general replacement. That is the right framing.

The dissent worth surfacing is from engineers who tried Pi expecting it to be a Claude Code competitor and were disappointed by what is intentionally not there. The MCP-and-sub-agents crowd does not get what Pi is for. That is fine — Pi is not for them. The smaller cohort of engineers who do infra-as-code daily, want to run against local models, and find the heavyweight tools’ permission-pop-ups annoying — Pi is genuinely the tool that addresses their specific friction.

The r/homelab community signal is consistent. The most recent r/homelab posts in the launch window are mostly about adjacent concerns — remote access patterns, network setup, the standard self-host preoccupations — but the engineers who run agents at all are increasingly running them against local models. Pi slots into that workflow cleanly.

The honest summary

Pi is a minimal, opinionated agent that does one thing — run commands with the engineer in the loop — and does it well. It is not trying to be Claude Code, Codex CLI, or Antigravity. It is trying to be the agent the engineer would build themselves if they had a weekend to write the tooling. That is a meaningfully smaller market than the heavyweight tools target, but it is a meaningful market — the homelab + infra-as-code crowd has been under-served by the agentic-engineering boom, and Pi fits their constraints.

The strategic read for the rest of 2026 is that the agent-tooling market is fragmenting along workload lines rather than consolidating into one winner. Pi for infra. Hermes for open-model agentic coding. Claude Code for closed-model frontier work. Codex CLI for OpenAI-routed work. Cursor for IDE-bound coding. Each owns its slice. Engineers should know which slice they are in and use the right tool. That is the working pattern for the rest of the year.