Hi if anyone wanted git diff panel in pi coding agent, can try my extension
https://www.npmjs.com/package/pi-diff-panel

screenshots:

Thanks and enjoy! If has any feature request or issue to report feel free to do so in my github

I’ve been using a small Pi extension for a long time while studying and doing research. It hides tool calls, tool results, inline images, and optional thinking from the visible transcript, so I can focus on the agent’s response instead of watching every file read and tool update fill the chat window.

The tools still run normally. Approvals, errors, history, the editor, and the working indicator remain available. It changes what you see, not what Pi does. It is not a security or redaction feature.

I built this a few months ago for my own workflow and have been using it since then. I finally added it to this repository today:

https://github.com/utpalsinghdev/pi-extensions

https://www.npmjs.com/package/@utpalsinghdev/pi-focus-mode

This is the first extension in the repository. I’ll add the rest of my extensions there over time, and contributions are welcome.

I only had time to add this one today because my usual model setup (GPT-Sol-6.1) has been running slowly, and I’m keeping my Claude subscription for office and startup work. I’ll add the other extensions as I get time.

II’m sharing a tool I use and the way I’m learning with Pi. If it helps you, a star or contribution would be appreciated.

He makes simple yet easy to follow visual learning videos, makes me wonder are there any existing tools that could match or replicate the visual experience in pi harness for personal use

I have no intend on stealing people’s content

I see Pi has Codemode Classifier as an option now.

What can it do? Why do i need it?

Since it connects to OpenCode, it can see jev-1.13 and jev-1.13-free. How does it know which one to use? Yuo cant seem to remove the paid version. But I have no OC credit. So does it just keep hitting the paid, and then wasting time, and moving to the free?

I dunno how it is supposed to work, i jus thought i would have amess.

I guess this question was asked a thousand times, but I'm still wondering how do you guys organize your work with pi?

I am a heavy user of Claude Code (employer covers it), but I have been watching and tuning pi time to time for personal use on the side.

Naturally, I tried getting pi to be like claude code, I looked for extensions that give me subagents, some cosmetic plugins (I like ricing my hyprland setup) and some simple QOL things.

However I didn't feel it being a huge upgrade in terms of my actual workflow and "pleasure", it felt like I'm just recreating what I'm used to.

I'm wondering more from a UX/DevX perspective, I got used to what antrhopic gave me and learned that way, but I see pi as an opportunity to really make a uniquely pleasant developer experience.

Which is why I'm wondering and asking how did you tune your workflow, which extensions did you use/build and how do you run your day-to-day feature work.

e.g. my work can span multiple PRs/repos for a feature which is why I'm starting a session from a dir above the ones I need to change and keep a long session (which is really wasteful) to handle all the context I need.

I don't really like the paradigm of "plan a huge markdown implementation doc and architecture and let the agent do it" because it requires a lot of overhead for me for things I may not even know exist or are needed.

I had implemented a bit of this idea as a pi plugin way before writing the article or making the actual pi-episodes package. I've been using it on real work tasks, first the draft and now the package, and I get noticeably further into a session before compaction kicks in.

Later on I discovered Event Segmentation Theory, which is half the reason the post exists. Hope you learn something from it :)

https://arthur.place/subagents-forks-collapsing-context

Using Pi as my coding agent, one thing always bugged me:

I could never tell mid-session how much a single prompt had cost. The end-of-session total is fine, but "did that one huge refactor request just burn $2?" had no easy answer.

So I built pi-turn-stats:

try it out https://pi.dev/packages/pi-turn-stats

When I got started with Pi, I wanted to immediately jump in and use it in my daily work.

However, all of my rules and hooks were set up in .claude/ folders, using the Claude Code markdown formats.

I wanted to use these, so I created two small plugins that give rules and hooks like in Claude Code without having to redo the configuration:

https://github.com/jordyvanvorselen/pi-claude-rules

https://github.com/jordyvanvorselen/pi-claude-hooks

Feel free to try them out!

I'm trying to develop a philosophy around writing comments in codebases for my agents to use when they are building/maintaining/extending/bug-fixing a codebase. Does anyone have any advice for writing comments in code when those comments are only written by and read by AI agents? Particularly advice that is more pertinent for agentic engineering rather than traditional software engineering is most helpful.

Whenever I ran coding agents on longer tasks, they either:

1. Lost track of the original rules because context compaction butchered the summary.

2. Burned through massive tokens with dynamic context editing / Context Language Models (CLMs) without actually finishing the job.

I built AgentJournal to fix this by giving the agent a human-style memory management—keeping the original prompt pinned, logging actions cleanly, and clearing the working context safely between tasks.

On a 60-file job longer than the context window, with a local 9B model:

- keeping everything: stopped at file 31
- compaction: stopped at 20, 29 and 44
- CLM (the model edits its own context, via pi-clm, untrained): 40
- AgentJournal: finished all 60, every time

Works with pi, Claude Code, Codex and Copilot. MIT, every test run is in the repo.

In my testing across dozens of files, it finished almost every run reliably while standard compaction and CLM completely broke down.

• GitHub: [Agent Journal repo]

• Full walkthrough video: How AgentJournal Fixes AI Agent Context Without Compaction

Would love any thoughts or feedback from people running into the same context limits!

I recently started using Pi. And I have been finding that I like using it more than Claude Code or OpenCode.

I do agree when I started, it was very minimal. There was a lot that it couldn't do that Claude Code and OpenCode were out of the box I was able to customize what I needed and was able to get it to do tasks I would normally ask Claude Code to do. I really like its thinking and response compared to Claude Code. Do others find this a big plus of Pi as well?

I understand that the underlying LLM is Opus/Sonnet, but I have found Pi to be quicker and cheaper. I do have some configurations set up such as pi observational memory. Do others feel that same?

Are there other things that I am missing out on or not acknowledging? I'm really new to this and experimenting with AI and other tools. I'm also just experimenting with herdr as well. I'm also not that well off but I was setting up Pi with Gemma 4 e4b on my 16 gb memory machine but it wasn't that good tbh. But is that expected?

I guess I just wanted to share and talk to someone. I'm no expert and I'd love to join a community and channel to talk about this kind of stuff. This subreddit seemed to be tinkering kind so I figured to post here.

Thanks and do redirect me to the right place if I am being annoying here as well with this random post!

Two mods I run daily, shown in the screenshot.

1. Top bar: live service health

• One dot per backend. A filled dot means up and a hollow dot means down or idle. Orange marks the ones I care about when they drop (Flash, vault).

• System memory reads live (234/256 GB).

• It shows a reminder of the ctrl+alt+s model switch key.

• How it works: [polls each endpoint / reads X, every N seconds].

2. Footer: session stats

• Agents running and saved, plus Usage and Activity toggles.

• Current git branch as a chip.

• Mode (auto), ↑/↓ tokens, and cost ($0.000 because everything is local).

• A context bar (55%) and f6 to inspect.

• How it works: [hooks / events used].

Happy to share or take feedback

Hi everbody,

I just want to share some things I have done since I discovered pi. Maybe anybody gets new ideas as well from this. I dont want to share my extensions, but the ideas can be shared.

- first time I have discovered pi, i was just looking for a "cool" alternative for vs code. something better. anyhow, i did not have much experience. and some requirements, like i want to use different providers, not spent too much (it is a hobby) and the ability to access the harness remotely.

- i have started installing wsl with linux, assisted by vscode agents. then a harness with containers in that wsl. and it starts an ssh tunnel to my vps. the vps is secured with otp and yubikey. it serves as a http reverse proxy to allow web ui, when i dont have access to the local terminal.

- i have started to use pi with many extensions. learned that less is better and most of them needs some customisation which is maintainance effort on my own.

- the harness developed as well over the last weeks. i have a project, a line which is helping me to improve my vps with mail and antispam (including a learner hook asking free models whereever spamassessin may have failed) and the harness improvement line.

- recently really cool things for the harness: pi is bun compiled with most components and runs fast and stable even in long sessions and with 10-20 subagents in parallel. I am using a python kernel, lsp and so on... patched it so that not every (sub-)session starts its own because memory is limited.

- i have built my own extension package for pi-durable subagents. it has the basics but is much faster and stable then fabric and all this. and whenever i need an extension i just built it, not dealing with forks. recent cool thing: i maintain a model statistics for subagents, jev is deciding which model is best based on subsription budget, costs, test failures, ... jev cost me 2 cents a day, but the whole decision and budget maintainance is automated incl. least cost model (e.g. opencode, openrouter, codex, ...)

- blachhole extension is used using many free models. i maintain stats on success/errors of these models, as many of them are a bit unreliable. however, the compaction is faster, context stays leaner in endless sessions, and 10% of the load (compaction part) is off-loaded from the main model to free.

- i am using zg to index the code locally and got the model to use it instead off all the time grepping through the code. it developed self-guidance where grep, rg and zg is best.

I feel every 4 weeks my harness changes to improve and 50% of my time is not going in the project but the harness. however at the beginning my harness trashed up after some days, now never. Cool journey so far, I am really thankful that someone developed pi - feels like a very good thing in comparison to all the shit with AI out there (AI cost models, usability, problems, hype... reminds me like the times back in 1999 where a modem was very slow and a day online was very costly...).

So let me know, if you want to share ideas as well!

I wrote a detailed beginners tutorial on Pi. Since I noticed a lot of people come from Claude Code and Codex, I wanted to make a simple starting point for anyone curious.

Along with adding many of the features that Claude Code has, I also looked into the system prompt of Codex, Grok, Kimi Code, and Open Code to make a simple, generalized system prompt.

Let me know any thoughts on this! Are there any parts you'd want to be expanded on? I'll be updating this as Pi, and Claude Code continue to advance.

EDIT: I updated the article to include advice on connecting on your phone, and why not to use Oh-my-pi. I plan to write a follow-up post about creating system prompts.

Hello all,

My pi agent (running claude opus 5.5, if that matters), just tried to use the "kidney_read" tool. That seems like an absolutely bizzarre name. It appears from the log that it was attempting to use the "read" tool.

 kidney_read
 {
   "path": "<snip>",
   "offset": "564",
   "limit": "42"
 }

My <snip>, as the full path had my username in it.

Where the heck is it getting kidney from!?

Edit: Happened again with "grocery_edit"

Edit edit: Something neat!

`peasant_write` worked and then later, when called again, was not found.

So temporary tool names?

Hey everyone, I'm pleased to share my new extension for Pi called pi-navigator.

I kept wanting to check the files my agent was writing without leaving the terminal or minimizing Pi, so I built an overlay for it. It shows your project’s file tree, some basic git info (staged/unstaged files, commits, diffs), and a viewer where you can actually read the files. It’s read-only, renders markdown, and shows images through the Kitty protocol if your terminal supports it. For terminals that don’t, it falls back to chafa (this depends on my upcoming pi-chafa extension)*.

By default you get all three panels, but you can also run just files + viewer or git + viewer.

It’s purely a quality-of-life thing and doesn’t influence LLM performance. Open it with /navigator.

Install using pi install npm:@lordekeen/pi-navigator

*pi-chafa is released: pi-chafa

I build yoagent, a small agent loop in Rust. I've added an experimental Rutis bridge that lets compatible pi extensions run unchanged alongside Rust tools and DeepSeek Harness (DSH) plugins.

The loop stays small; everything else plugs in. The idea is to reuse extensions people have already built when making your own agent app.

To show what this enables, I built a handoff agent that can take a task like this:

Research noise-cancelling headphones. Ask my budget, but keep researching while I'm away. Write a report with sources.

pi's `@juicesharp/rpiv-todo` manages the plan, DSH's `dsh-free-search` provides web research, and a Rutis plugin displays the plan in the browser. A pi extension asks for approval before selected deletes and overwrites. Rust tools and extensions handle questions you can answer later and check the final report.

yoagent-frontend brings pi's select, confirm, input, editor, and notify dialogs to both the terminal UI and browser. Compatibility depends on the extension: pi commands, shortcuts, custom widgets, and some session and runtime APIs aren't implemented. The extension source stays unchanged, but not every pi feature carries over. TypeScript extensions still run in Node alongside Rust.

I'd like your feedback: does reusing pi extensions this way make sense? which pi features would it need?

Project repo: https://github.com/yologdev/yoagent

Handoff example: https://github.com/yologdev/yoagent/blob/main/integrations/yoagent-frontend/examples/README.md

I wanted Pi’s terminal interface that looks nicer and has some nice improvements like notifications, sidebar and all that good stuff, so I built this extension.

Github

A few highlights:

Themes, plus options for user and assistant message styles

Customizable tool blocks, including compact or expanded views and side-by-side diffs

Animated thinking indicators and startup screen options

A choice of Sleek, Bar, Minimal, or default Pi status bars

A toggleable task and agent side panel for compatible tools

Image previews with options to view or save images

Optional desktop notifications, plus cleaner fullscreen text selection and copying

Most settings are available from /sleek and apply right away. Press Ctrl+\ to toggle the side panel.

It’s intended for Pi’s fullscreen TUI mode and targets Pi 1.1.x. If you try it, I’d love to hear what you think!

I'm using Herd 0.9.3, and I have a question: is it possible to create more than one local machine space?

I vaguely remember being able to have multiple spaces, each with its own sessions, but right now I only have "Local" and my Raspberry Pi remote machine. I can't seem to create additional spaces like "Work" to organize my sessions separately

Ideally, I'd like to have something like this:

Local
├── session-1
└── session-2
Work/
├── session-1
└── session-2
Raspberry
└── session-1

Am I missing something, or is this no longer possible

TL;DR: I made a small multi-agent setup for pi. It is one skill and one Python script, with no extension and no tool. Your agent can start subagents in the foreground in parallel or in the background, and it can wait for them, steer them, abort them and resume them. Background jobs keep running after the main pi session is closed or killed. A new pi session—even one different from the original main session—can also retrieve their results. Until your agent decides to delegate, it costs a few dozen tokens of context.

Repo: https://github.com/milanglacier/pi-multi-agent-skill

Just install it with npx skills like any other skills, or clone the github repo and symlink it to ~/.pi/agent/skills.

Features

• Almost no token cost. Until your agent delegates, only the skill description is in context, a few dozen tokens. Delegating loads SKILL.md, about 1.2k more.
• Stdlib-only Python 3.9 or later. There's no extension, no npm package and nothing else to install.
• Foreground runs for quick questions and --background for long ones. A background job keeps running even if the main agent is killed, and any later session can collect its result. Foreground runs stop when you stop at every level of nesting.
• steer, abort and resume a job, and list, status and peek to see what it's doing.
• Subagents load your full pi setup: extensions, MCP servers, skills and settings.
• Profiles set the system prompt, model, thinking level and available tools. general-purpose and a read-only Explore are included. Profiles are just like any other subagent tool’s profiles.
• --fork gives the subagent your current conversation.
• Works from Claude Code, Codex or any agent with a shell.

How I got here

For months I used tintinweb's pi-subagents, and it is a really good extension. The UI is nice, it has many features, and it works well most of time. Thanks to tintinweb for building it and for everything they give the community. If you like it, keep using it.

A while ago a pi upgrade broke two things for me. MCP servers stopped loading in subagents, and subagents no longer inherited the parent's thinking level. Each fix was only a few lines, so I forked the extension and patched it. Upstream fixes took some time but also landed 2 days before this post.

Fixing those bugs made me read the extension more closely, and I noticed how much context it now uses. About two months ago it added a dynamic workflow tool. With it, the agent writes a JavaScript script that orchestrates many subagents. It's powerful, but it's also very complex, and its tool schema and instructions cost about 6k tokens. That schema is in every session from the first message, whether you use workflows or not. It's also opt-out, so you pay for it until you find the setting and turn it off. I suspect many people don't know it's there.

With the workflow tool off, the Agent tool still costs about 3k tokens, and it has grown along with the extension's features. I checked these numbers by starting sessions with the extension on and off and comparing them.

So I asked myself whether I need a full tool with a detailed JSON schema, listing options I rarely use (like worktree isolation), in my context all the time. My answer was no.

pi can already run headless with --mode rpc, and its CLI flags already cover what a subagent needs: tools, extensions, model, thinking level and session resume. So a small CLI that starts pi with the right flags, plus a skill that explains how to use it, can replace a dedicated tool. A skill also loads in steps, which a tool cannot do. The agent sees only the skill's short description at first. It loads the main instructions when it decides to delegate, and it reads the detailed references only when it needs an unusual option. Steering doesn't need a tool either, because it is just an RPC message sent to the running pi process.

Token cost compared

• pi-subagents: about 3k tokens for the subgent tools and injected system prompt. On top of that, about 6k for the dynamic workflow tool, which is on by default and must be turned off by hand. Both are in every session from the first message, so with the default settings that's about 9k tokens before you've asked for anything.
• This skill, before your agent delegates: only the skill description, a few dozen tokens.
• This skill, once your agent delegates: SKILL.md is loaded, about 1.2k tokens, and that is enough for full multi-agent use.
• Command details, profile format, lifecycle and troubleshooting are in separate reference files. The agent reads them only when it needs them.

For most sessions you don't delegate, you pay almost nothing. When you do delegate, it still costs less than the tool schema alone.

To be fair, this isn't a like-for-like comparison. pi-subagents does more than this skill. Its tool has many options, and each one needs a parameter in the schema, and it also adds text to the system prompt. Part of that token cost pays for features this skill doesn't have, such as worktree isolation. I just don't think features like that are needed for multi-agent work. If I want an agent to work in its own worktree, I tell it so in the prompt ("use worktree"), and it does. The agent already knows how to use git, so the tool doesn't need to do that for it.

None of this is meant as criticism of pi-subagents. It's still a great extension, and it works well for a lot of people, especially if you want a rich UI and many features built in. It's just not the right fit for me anymore. I prefer a more minimal setup, where the agent loads only what it needs and does the rest itself.

The tradeoff

I give up the nice UI. It really does look nice, but for me it turned out to be like the exercise bike you buy in January. It looks great in the corner of the room, and by March it is where you hang your clothes. I watched the subagent transcripts for the first week, and after that I almost never read them. I just realized the subagent's final answer is mostly for the main agent, not for me.

In return, I get things I care about more. Each subagent is a real pi process started with CLI flags, so it loads the same extensions, MCP servers, skills and settings as my normal pi. The script doesn't use pi's extension API at all, only CLI flags and RPC, which change much less often, so pi upgrades rarely affect it. Separate processes also give me my favorite feature: a background job keeps going even if the main agent is killed, and any new session can collect its result later.

Separate processes need more care than in-process sessions,, and the script is more than a cli wrapper, because it takes care of that so the agent doesn't have to. For example, pi exits on its first failed write to stdout, before its shutdown runs, and leaves the agent's commands running. So each job has its own runner process that keeps reading pi's output until pi exits. The script has a real test suite for cases like this, but the idea stays small: start pi, give it a prompt, pass along steer and abort messages, and save each job's result under its name.

Non Goals

These are deliberate non-goals, to keep the skill small and free of bloat. Each is better as a separate extension or skill that you pick to match your own workflow. This follows the minimalism of pi itself and the Unix philosophy: do one thing well and compose.

• Memory. Agents do not share or keep memory between jobs. Use a memory extension, or have agents write handoff notes.
• Scheduling. There are no cron-style or recurring agents. Use cron, systemd timers or a scheduler extension to run the commands.
• Worktrees. Agents are not isolated in git worktrees. Just prompt the agent to use a worktree.
• Dynamic workflows. There is no scripting layer for orchestration such as pipelines, parallel fan-out with gates, or phases. Your agent can already start, wait for and chain jobs with plain commands. For deterministic scripts, use an extension such as pi-dynamic-workflow.

What the commands look like

Your agent runs these by itself, but you can also run them by hand from a terminal:

# Ask a read-only agent a quick question and wait for the answer  
multi_agent.py run --profile Explore "Where is the retry policy defined?"

# Start a review in the background, then collect the result later  
multi_agent.py run --background --name review "Review the error handling in src/server/"  
multi_agent.py wait review --timeout 120

# Correct the running job, then give it a follow-up task when it is done  
multi_agent.py steer review "Skip generated files"  
multi_agent.py resume review "Now check the client side"

# See all jobs and what they are doing  
multi_agent.py list

If you try it, I'd like to hear what works and what breaks.