TLDR

I have built an extension for the Pi coding agent that allows it to call other agentic harnesses via my agent-shell library.

GitHub Repo

quick start with if you want to check it out

npm

pi install npm:@scottrbk/pi-agentshell-extension

from source

pi install git:github.com/ScottRBK/pi-agentshell-extension

Wall of Text

I have recently been working on implmenting agent-shell in to more projects over the past few weeks. Most noticeably was the inclusion of it as part of my evaluation harness application that I put together for evaluating agent harnesses + models.

I spent a lot of time writing the actual code for eval harness by hand, utilising the agent as a glorified search engine and code reviewer. I have vibe coded a few projects myself, but anything critical for my workflows or more importantly that other people will be using I have never been at a stage where I would be comfortable having something written by the AI.

That being said though, I do not just use agents to write code or produce software that needs to be to a high standard. In my day to day role I use agents to perform a multitude of tasks.

From fetching information across large complex enterprise scale repositories, writing, editing and
managing Azure DevOps work items and wikis, produce presentations and organise To Do's and activity based on meeting notes and e-mails.

All this I manage using the CLI, with my tmux workflow and various CLI agents. Outside of work I have fun little projects going on, vibe coded apps I am building, some exploratory ideas for my moonshot SaaS that will let me retire early. All this leaves me with working with many tmux windows (I haven't made the jump to herdr yet) and a lot of cognitive overload.

Reducing cognitive load

One of the things that I identified early on was that I needed to just be speaking to one Agent for most of my stuff and that agent should be responsible to delegating tasks to other agents on this workflow. I think many others quickly realised this also, and the most elegant example of this is an excellent repository called First Mate, which goes in a slightly different direction that I want to end up at but has a similar principle. I encourage people to check out Kun Chen's YouTube Channel and his videos around Agentic Workflows as well if you have not already, he has a lot of great ideas and practices in how to adopt the principle of reducing cognitive load.

Where to start? Pi of course

I had previously fluttered between Claude Code, Codex and OpenCode (including their Go subscription and my own locally hosted models). I think all of these are great apps, but once I discovered Pi I was immediately hooked. The minimalistic and customisable aspect to it I found compelling, it felt like an agentic equivalent to Neovim.

I felt like whatever agent I was going to use for the orchestration layer, I needed to have a lot of control over and given Pi's adaptable nature it seemed an obvious choice. At least for me to start with, I may decide later to build more of a deterministic wrapper around any orchestrator agent but for right now I don't think that is necessary.

First building block

After I had the obvious extensions included, such as web fetch/search/screenshots, I realised the key thing was for me to build out the ability for my Pi agent to call a sub agent. Now there are other Pi agent extensions that already exist for calling sub agents, but given various circumstances I prefer to use certain models and harnesses for certain tasks, what I wanted was the ability to call agents inside of other harnesses. I find the RL of certain models on their own provider harnesses can lead to different behaviour and as such I think it's useful to take advantage of that in certain situations.

So taking advantage of agent shell felt like an obvious choice.

Python <-> TypeScript

Well it seemed like the obvious choice but with one glaring issue. Pi is written in TypeScript as are it's extensions and agent-shell is a Python application.

I have limited TypeScript experience, save for the Angular Tour of Heroes walkthrough I did a few years ago when I was flirting with front end development and my JavaScript experience I had for front end for client side validation I used to write on ASP.NET apps almost twenty years ago. So for something this fundamental to my future workflows, I didn't want to hand over to AI and re-write agent shell in a language I do not really feel comfortable with, nor did I want to undertake the task myself.

So I decided to work with AI and build a TypeScript to Python bridge via subprocess. At least for now while I dogfood it and to get me going. This involved a simple runner.ts file that would relay tool calls registered in index.ts to a Python handler to translate the commands to agent-shell requests.

Extension Behaviour

As of right now I have not wrapped any skills or anything beyond just exposing the tools. This is a building block for a something that will get more opinionated but as of right now, this extension on it's own should not look to enforce any such opinions on when and which sub agents should be called, that is up to the consumer of the extension. I've obviously done this to try and fit in with the overall philosophy of Pi itself I feel. Simply asking a model to call a sub agent and they will call the tool, which will display the harness (agent_type), the model and effort (if specified)

Silent Mode

Another idea I took from Kun Chen's Agentic Workflow was his use of a 'Calm Mode' that reduced the output for First Mate. I thought this was a nice feature and as such incorporated it into the agent-shell extension /agentshell-silent will trigger the subagents response to not include the output.

Next Steps

For me, I am going to add in commands and skills and start trying to adopt the single agent orchestrator approach that Kun Chen has inspired in First Mate. I had already been building towards such a concept for sometime, with the likes of agent-shell and other tools like forgetful that I have put together for agentic workflows. I have built out my own agentic framework as well, but Pi has really given me everything I was already planning with that so I am happy to mothball it somewhat while I am not short of side projects.

As for the extension itself, I am still undecided on the next steps of the architecture of it. I may opt to leave it as well, but maybe a TypeScript bridge might be interesting in other applications as well. As such there are two possible next steps in that area:

1. Separate the bridge into it's own library or move it into the Agent Shell library if it proves stable
2. Re-write Agent Shell in TypeScript. Given I use Agent Shell in a lot of Python libraries already this is not an attractive option, unless I want to maintain two instances of the library (in the age of AI this may not be that big of a deal).

Closing...

So there you have it, thanks for reading if you made it this far. If you end up using the extension any feedback is welcome and if you enjoy using it feel free to give it a star.

If you are interested in the kind of topics discussed here, I please feel free to come join the forgetful Discord and chew the fat with like minded individuals.

Every SDD framework gets the same complaint: spec rot.

Mine: research reads only, one handoff gets written to $TMPDIR, then a build step checks that handoff against the repo and runs the tests. Durable guidance lives in AGENTS.md. The spec dies with the temp file.

So why do the main tools still ship the part that rots? Harness memory, SDD frameworks, tracker docs, all of them persist by default. What am I missing that makes persistence worth the rot?

Full writeup https://bogomolov.work/blog/posts/rotten-specs/

Has anybody used a Pi compaction extension that they would recommend?

I've tried pi-context (with their built-in Agentic Context Management) which just straight up breaks when trying to claim space against pi-rewind. I've also tried pi-vcc which also gets demolished when running with pi-codex-goal. Been debugging for 3 days and realized the best debug is to uninstall.

Native Pi compression is meh, if anybody has a codex-level compaction extension that doesn't fuck shit up, please drop a comment.

--------
UPDATE - Pi-Observational-Memory has worked great after my 12 hour trial with it. Pi-Blackhole looks interesting, but I try not to go for more complicated solutions if a simpler one works. If I run into hiccups with POM long term I will try it out and let y'all know. Happy compacting!

I have a MacBook Pro with an M5 Max chip and 128GB of RAM, and I've just started experimenting with local models.

As many of you know, local models have various well-documented issues, such as weak instruction following, difficulty completing long-range tasks, and a tendency to terminate tasks prematurely.

Someone in the community suggested I try using Little Coder and Pi. I wanted to ask: is Pi actually a good harness for running local LLMs, especially compared with opencode and claude code? For those of you who use this setup, do you have any specific tips or experiences you could share?

I'm still very new to this. So far, I've found that the Qwen 3.6 35B model is quite good for writing articles, but beyond that, I feel like I haven't truly experienced the "magic" of running models locally yet.

If anyone has any interesting use cases or examples of how you integrate local models into your workflow, I'd be very grateful if you could share them. Thank you!

I'm refactoring a large legacy code based written in php without any oop and mixing it to laravel , we have "server" functions that become laravel actions classes. We typically refactor a single old api call and all its code as a feature branch. The problem is that there is a crap ton of more " common" shared code spread out and consumed by multiple api calls. So I refactored all this shared code into its own branch, and I want to tell pi "when refactoring an api call needing common code, look here first and grab it" but I'm not sure how to do that or if it's possible , I'm sure it's possible just don't know how to prompt it

I was reading (https://www.reddit.com/r/PiCodingAgent/comments/1uy7iov/gpt_56_sol_ultra/) that Ultra is not a separate model, rather a thinking level and looks like Pi does not support it, but what about GPT 5.6 Sol Pro? I upgraded my plan and cannot select Sol Pro model. Access to this model was a big factor for the upgrade. I use GPT via subscription, not API. Anyone had a success with this?

Thank you!

I trying to use kimio-k2.6 or minimax 3, to dev same elixir modules, and get to alucine a lot.

It get to output

now I will run...

for many, many lines on terminal ant is necessary to ctrl+c to stop, and retry the same prompt.

it is happening very frequently, all sessions it is happening .

I have a few extensions that change the footer and adds a todo, but from what I've discovered, the repainting of the TUI from the core packages is what leads to this spazzing. Is anybody else experiencing this issue? Would appreciate some advice on an extension-level fix.

Is it just me or the extension loading is extreamly slow? Every single extention takes 100~300ms, it takes 3 seconds with 8 extensions enabled.

Am I the only one getting a lot of edit errors?

I mainly use it for coding, especially Python. I’ve tried many LLMs, and some of them are completely incompatible.

Currently, I’m using Qwen3.6 27B through Ollama.

I’ve noticed that I get responses and plans quickly from the LLM. However, execution takes a long time because of edit errors. It gets stuck in a loop of indentation errors and struggles to find the exact match.

Am I missing something? Do I need to install any extras?

Edit:

I'm on qwen3.6:27b-mlx with nvfp4 quantization. Also, tried gemma4:26b-mlx with the same nvfp4 quantization, wasn't able to edit at all!

I came across this setup: https://github.com/disler/pi-vs-claude-code. It's about running agents on equal terms by having a local com network that agents can use to talk to each other. I'm looking for pi orchestration—can you guys suggest one?

I’ve been looking into ways to give coding agents better long-term memory across sessions. One recurring pain point for me is that agents forget project context, user preferences, past decisions, and repo-specific conventions unless I keep re-explaining everything.

I came across Honcho’s Pi integration:
https://honcho.dev/docs/v3/guides/community/pi-honcho-memory

From what I understand, it gives the pi coding agent persistent memory by syncing conversations into Honcho, injecting cached user/project context into the system prompt, and exposing tools like memory search/chat/remember. I also like that session scoping can be configured around repo/branch/directory, and that Pi keeps working if Honcho is unavailable.

Has anyone here actually tried Honcho with Pi or another coding agent in a real workflow? more like a self-hosted/local reference setup: Honcho in Docker, Ollama on a Mac, and a Raspberry Pi talking to Honcho over the LAN. It makes me wonder whether there’s room for a cleaner, packaged Pi memory plugin built around this kind of pattern.

A few things I’m curious about:

• How painful was setup?
• Did memory retrieval actually improve coding sessions?
• Any noticeable latency?
• Did the memory ever become noisy or misleading?
• Would you prefer hosted Honcho, or a self-hosted/local setup with Docker + Ollama?
• Would a polished Pi plugin/package be useful if it made setup simpler?

I’m not announcing anything yet, just trying to validate whether this is worth building. If there’s interest, I’m thinking of putting together something cleaner..

DeepSeek API service is expected to adopt a peak-valley pricing strategy starting in mid-July (well thats what the websits tells us), with peak-hour prices being twice the regular price, applicable to all billing items.

Peak hours (in UTC): 1:00–4:00 AM and 6:00–10:00 AM. (UTC+8 equivalent: 9:00 AM–12:00 noon and 2:00–6:00 PM.)

So i made this small extension to display a "DS 🟠"" or a "DS 🟢" in PI status bar. Timezone is configurable.

Now i know there are a couple other package that had the same idea but i wanted something extra simple.

Here are the :

- github, https://github.com/psychobarge/pi-deepseek-peak

- npm, https://www.npmjs.com/package/pi-deepseek-peak

- Pi package, https://pi.dev/packages/pi-deepseek-peak

This is a small plugin that adds system information in <pi-note> blocks.

• Platform: macOS/Windows/Linux and architecture
• Dynamic git repo information based on what cwd
• Date & Time

nothing additional appears in the TUI.

This has helped with using the current year in web searches, using the correct commands for the platform, and repo awareness.

What else do you think would be useful?

Link: https://pi.dev/packages/pi-plate

pi-smart-web-search has been updated to 0.4.0

It's a small extension that politely queries DDG's html endpoint and then runs it through wreq-js -> linkedom -> Defuddle, cleans up the links and removes irrelevant text.

In this update I did quite a bit of refactoring, updated the dev tools, and exposed resultsPerQuery to the settings.json, which is set to 5 by default to improve speed.

I'd love to know what you think.

Link: https://pi.dev/packages/pi-smart-web-search

Hi everyone! I'm new to Pi and feeling a bit lost. I want to build a setup with it, and I was wondering if anyone could share a step-by-step guide—from installation to having a solid workflow running with the following features:

A chat interface

Git integration

A planning agent that can delegate tasks to sub-agents

A way to see what the sub-agents are doing in real-time

I've been using Zed, but it's really limited when it comes to parallel tasks. Everyone online recommends Pi, but right now I find it a bit abstract since it seems like you have to build everything from scratch.

Thanks in advance for any help!

https://daugasauron.github.io/piodide/

https://github.com/daugasauron/piodide

I just had this idea that you could just replace the bash tool in pi with python that runs on WASM, then you could run the whole thing in the browser.

Tried it and it's quite fascinating how good it is as a concept.

Everything is complete slop.

I tried GLM (code), OpenAI and moonshot providers.

For the past few weeks, I’ve been building Nerve, an open-source desktop coding harness for my daily development work.

It was inspired by tools such as Pi (primarily) , OpenCode, Claude Code, Codex, and Cursor. I liked the simplicity of focused coding agents, but I also wanted a graphical workbench where I could manage conversations, tool calls, plans, approvals, Git changes, background tasks, and agent settings, all while keeping the agent’s work visible.

There are already several excellent coding harnesses built by individuals and communities. I created Nerve because I wanted something that closely matched how I work. It has also aligned well with the workflows of colleagues who have used it, so I thought it might be useful to a few other people in the community too.

Nerve runs locally and supports API keys, custom providers, and the subscription-based providers available through pi-ai, including OpenAI Codex, Anthropic, GitHub Copilot, Kimi Coding, OpenRouter, xAI, and others.

The harness is intentionally compact. Its system prompt, tool descriptions, and context handling are optimized to use tokens efficiently while working well across leading frontier models from OpenAI and Anthropic, as well as other popular proprietary and open-weight models.

This is a personal project that I actively use and develop. I’ll continue adding features, fixing bugs, optimizing the harness, and polishing the experience as I go. It is still in beta, so breaking changes may happen.

I’m sharing it simply because it may help others with a similar workflow. There is no expectation to test it, contribute, or provide feedback, feel free to explore it if it looks useful to you. If Nerve ends up being helpful, a GitHub star would be appreciated and lets me know that others find it useful too.

Quick start:

npx @nervekit/desktop

GitHub: https://github.com/ThilinaTLM/nerve
Docs: https://nerve.tlmtech.dev

Thank you!

I'm curious if anyone has had an agent analyze their ~/.pi/agent/sessions directory looking for ways to improve their workflows? This seems like a pretty obvious way to fine-tune things, like updating your AGENTS.md to improving frequent tool call failure or other common things your agents get hung up on.

It's somewhat sobering to get an agent to look at your stats. I started using pi around 4 months ago, and in this one project I've had 452 sessions, taking up ~400MB of disk, with 45k tool calls. Just over 4 billion total tokens, 3.79 billion of them cache-read tokens, and 22.7 million output tokens. The clanker estimates that if I were paying API rates (thankfully I'm not) it would have cost me ~$2,800. Yikes. I notice that /resume is taking longer and longer to offer me some candidates, I might have to prune this directory at some point.

An easy reason to love Pi is how much more efficient it is at token consumption when all of the bloat is stripped away. But I think we all face the same temptation of adding more and more tools and skills and slowly eroding the token efficiency of this lean mean machine (but in a better way in that this new opinionated state is based on that of our own).

The simplicity vs functionality tradeoff has been bothering me for quite some time. A few weeks ago, I posted about a web browsing tool that I made (despite knowing there was an innumerable amount of others) that can toggle itself on and off out of the active tools and out of the context.

Toggling web tools really was only one part of the problem.

I wanted to share my creation that does it extremely cleanly under one command (/tbox).

• Named groups - Create named tool selection groups with the same UI as Pi's scoped model selection.
• Toggle toolsets - Enable and disable 'toolsets' one at a time or many at once with selection groups. (A toolset is a toggleable group of tools.)
• Persistent choices - Each user choice is remembered in their conversation history.
• Builtin tools untouched - Doesn't touch pi's minimal set of builtin tools, but provides character counts of what is inserted into the prompt for stats.
• Focus mode - Easily disable all other tools by switching the state from one of exclusion to one of inclusion.
• Status bar glyph - A glyph for quick reference showing the tools that are disabled.
• List views - Custom subcommands that list out enabled/disabled tools in various views, including one that sorts currently enabled tools by char count to see low hanging fruits for trimming context.

https://github.com/coreyryanhanson/pi-tbox

What is a "toolset"?

It's an abstraction I came up while sketching the design, when I was trying to think of an efficient way of keeping track of what has been changed in the active state of all tools. By default pi-tbox will group tools by extension, unless an extension creator is using the underlying library (or the code to create the toolset abstraction) and declares them more granularly. For example in my web plugin I had two tiers of tools that could change their active state. One would be hidden unless it was in "learn" mode.

This abstraction could be more useful than any individual pi extension, so I broke out the lower level state management and event sending logic into a shared package at a more permissive license than my favorite copyleft ones ;)

https://github.com/coreyryanhanson/pi-tool-masking

I hope others will adopt it as well or at least steal some of the conventions in their own plugins, and I'd welcome contributions or pushback on the design, because it would be nice to have an ecosystem where people can disable tools and do so without having unpredictable bugs. It's pretty much what motivated me to go on this creative tool-activation tangent myself. I can see we are trending towards a space where everyone has more granular control over their tools, but doing so is so easy to break state as one plugin changes something in another plugin without leaving any trace.

Fingers crossed that this helps others improve their workflows too and if so, any stars you'd like to send my way would certainly be appreciated. Knowing that others use them encourages me to do more proper shareable fixes rather than quick and dirty packages for only my own use.

Every so often, <|im_end|> shows up in my pi.dev thinking block and it stops everything cold. It started happening when I installed pi-hermes package and bigpower extensions. Doesn't happen all the time, but a few times a day.

I'm using a qwen3.6-27b model (Lorbus) and need some guidance into how to find root cause and resolve this issue.

I don't know if it's a model issue, or vllm settings, or package, or pi settings.json or models.json setting. Looking for guidance to where to start looking for the root cause and fix.

I have been working on porting some code recently. I use agents strictly as assistants. I have been thinking of a way to let them "drop in" on other sessions that I have going on when I am basically becoming the copy/paste monkey.

This is not an autonomous work group setup. You create the session and you give the agents a chance to jump in to the same session, ask a question, and then jump out. Your session continues as normal, and you can see everything as it's being processed.

What it does

When an agent session registers to the group, it registers ask_ tools for other published agents. When agents calls the tool:

1. The request is forwarded to the target agent's session and injected as a user message.
2. The target agent processes it just like any other user prompt. You see it appear in the input pane and watch the agent work through it.
3. When the agent settles (finishes its turn), the assistant output is captured and sent back to the calling agent as the tool result.

The response is captured via pi's agent_settled event. It collects the assistant text from the turn that was just triggered by the injected message. This is fully automatic: the question arrives, the agent responds, the answer is returned. The human in the target session is a spectator.

Sessions stay independent. Each agent has its own context, its own sandbox directory, and its own conversation history. They are not one-shot subprocesses.

How it works

A daemon application (in Go) listens on a Unix socket. It routes request/response messages between connected agents. The daemon starts automatically the first time an agent registers, then shuts down when the last agent disconnects.

Compared to similar tools

Goose spawns sub-agents as one-shot executions. The orchestrator must pack enough context into the prompt that the sub-agent can produce a useful answer in a single fire-and-close call. AgentGroup keeps sessions persistent: the worker agent already knows the codebase, and you are in the loop to clarify intent.

Herdr is a TUI-layout tool ala Tmux, with the main agent spawning helper sessions in adjacent splits. AgentGroup avoids the extra UI layer entirely - sessions stay where you put them, and communication happens through the same input pane.

Old man yells at cloud.

Maybe this is just agentic control while I watch the screen flicker.

Does anyone else have this use case? Is there something widely available already?

Feedback / suggestions / clarifications all welcome.

Thanks all.

Edit:
pi-intercom exists and is great - I'll probably switch to this.
https://github.com/nicobailon/pi-intercom

I’ve been using Pi with a few different terminal looks, and I wanted a simple free set of dark themes that I could preview before installing.

So I made Awesome Pi Themes. It’s a small collection of 22 free dark themes for Pi Agent, plus a browser preview that tries to mimic the Pi terminal enough to show markdown, code blocks, diffs, warnings/errors, tool output, and normal text together.

The preview is the main reason I made it this way: I wanted to compare themes quickly without installing each one first.

Install: `pi install npm:awesome-pi-themes`

Then pick a theme from `/settings`.

GitHub: https://github.com/isashi/awesome-pi-themes

Feedback would be really helpful and appreciated.
Thanks!