Things I love about Pi

I have been using Pi for the past several months. Pi is a minimal, open-source coding agent harness.

It comes with only 4 tools out of the box: Read, Write, Edit, and Bash. That’s it. For everything else, you either extend Pi yourself or use extensions. It can feel a bit bare-bones when you start.

I, for example, missed having web search. I then asked Pi to help me build a web search tool, which I have been using ever since. It uses Tavily as its search API provider, and Tavily has a generous free tier.

I am also a bit wary of running other people’s extensions, so I always run all my agents inside a Docker sandbox (I should talk about it sometime, maybe).

Pi also allows you to use different providers. This is useful when you want to see what different models can do, especially open-weight models.

I have been using Pi with a Codex subscription and with NeuralWatt and OpenRouter for open-weight models. I also had a Z.AI subscription, which I ditched because Z.AI does not offer a Zero Data Retention policy.

There is a lot I love about Pi, but /tree tops the chart.

Pi models your session history as a tree, and that actually matches my mental model of talking to models. When I am working on something with an agent, I may explore several branches. I may also need to debug something unrelated to the current session, such as a server that fails to start because of a port conflict. These conversations are not really relevant, and keeping them in my current conversation would poison the context and distract the model.

/tree lets me return to an earlier point and start a new branch without losing the old one. I can return to any branch later. When I leave a branch, I can also ask Pi to summarize it and carry the conclusion into the branch I continue with. This is useful if you are exploring different ideas and just want to bring the conclusion back into the main thread.

For example, a session might look like this:

Me: We need to make the webhook handler idempotent. What are our options?

Pi: We could store event IDs in Redis or rely on a unique constraint
in Postgres. Redis is faster, while Postgres avoids adding another
dependency.

Me: Let's explore the Redis approach.

Pi: We would use SET event_id 1 NX EX 86400 before processing each
event...

[I open /tree, jump back to the original question, and ask Pi to
summarize the branch I am leaving.]

Branch summary: We explored Redis-based idempotency. It is simple and
fast, but introduces another dependency and needs a policy for key expiry.

Me: Now explore the Postgres approach.

Pi: Add a unique constraint on the provider's event ID and insert it
before processing. Given what we learned from the Redis branch, Postgres
is probably the better fit here: slightly slower, but fewer moving parts
and no expiry concerns.

Graphically, the conversation now looks like this:

“We need to make the webhook handler idempotent.”
                         │
                         ▼
              Pi suggests two options
                  Redis or Postgres
                         │
              ┌──────────┴──────────┐
              │                     │
              ▼                     │
       Explore Redis                │
              │                     │
       Discuss expiry,              │
       failure modes, and           │
       operational cost             │
              │                     │
              └────── /tree ────────┤
                    jump back       │
                                    ▼
                         Summarize Redis branch
                                    │
                                    ▼
                           Explore Postgres
                                    │
                                    ▼
                         Choose a unique constraint

Webhook idempotency
└── Redis or Postgres?
    ├── Explore Redis
    │   ├── Use SET NX with expiry
    │   ├── Discuss failure modes
    │   └── Consider operational cost
    │
    └── Redis branch summary       ← active context keeps only this
        └── Explore Postgres
            ├── Add unique constraint
            └── Choose Postgres

The full Redis discussion remains available in the tree, while the active branch carries forward only its useful conclusion.

Another useful command in Pi is /handoff. Think of this as a custom way to summarize the current conversation and carry that summary into a new session. I use it either when I am logically done with the current conversation and want to pass it on to a new one for implementation, or when I see that I am entering the “dumb zone”.

Suggested reading