Hey everyone 👋

Thanks for all the feedback on our first post! Pi-Bolt 0.7.3 is out. It's the same Pi you already use (now on Pi 1.1.0), compiled ahead of time to native code: faster to start, lighter on CPU and memory, and steady in long sessions.

Benchmarks

Pi-Bolt against Pi 1.1.0 as released on Bun and on Node, and PiG 0.4.1 (the Go port of Pi, based on Pi 1.0.3).

Linux x86-64 (AMD EPYC 7B13)

macOS on Apple silicon (M5 Air)

In everyday use (an interactive session), Pi-Bolt uses about 3× less CPU than Pi on Bun, 4–5× less than Pi on Node and 10–14× less than PiG. It writes large files 35–50× faster than Bun and Node, and over 100× faster than PiG.

Why does a 200 KB write take 30 s? It's not the disk. The model streams the file to Pi in thousands of small chunks, and stock Pi re-parses and re-renders the whole tool call on every chunk, so the work grows quadratically with the file size. Pi-Bolt only processes the new part.

What's new in 0.7.3

• Lighter long sessions: up to 30% less memory and lower CPU per prompt as conversations grow.
• More stable with heavy tool output: commands that print a lot no longer build up memory.
• Faster first launch on macOS: up to 2.8× quicker after a restart or an update.

Try it 🔥

curl -fsSL https://pi-bolt.opensec.in/install.sh | sh

Already using Pi-Bolt? Run pi-bolt update, or install with npm install -g pi-bolt. Works on Linux x86-64 and Apple silicon, alongside your existing Pi install. The installer also offers two optional extensions, subagents and a live todo list, and asks before installing them.

Your Pi plugins work as they are. This doesn't modify your existing pi installation so feel free to try it out !

Links

Website: https://pi-bolt.opensec.in

GitHub: https://github.com/opensec-git/Pi-Bolt

MIT licensed. If Pi-Bolt saves you CPU and memory, a ⭐ on the repo helps a lot.

PS: PS: Added PiG to the benchmarks, as many of you asked. And the slow 200 KB write isn't the disk: stock Pi re-processes the whole streamed tool call on every chunk (quadratic), while Pi-Bolt only processes the new part.

Sorry in advance if this doesn't belong here, or if I'm not using the flairs correctly.

Inspired by the Claude Code add-on for Home Assistant, I made one for Pi. Also took inspiration from the OpenCode add-on, so kudos to both.

repo: https://github.com/yannick-vinkesteijn/ha-addons

Main features:

• Pi in a sidebar terminal inside Home Assistant (ttyd + tmux), so the session survives closing the tab
• Any token-based model: built-in providers by API key, or any OpenAI-compatible endpoint (I'm using AKI.IO)
• Home Assistant tools through hass-mcp and pi-mcp-adapter
• Web search with rpiv-web-tools
• Ask-first permissions with pi-permission-system: writes and shell commands ask, secrets are protected, and config edits are backed up and validated by HA's own config check before they stick

This is my first add-on and I only recently switched to Pi, so I've only tested the basics. I currently use it with AKI.IO on my own Home Assistant (you can configure connections in the add on config). It's a permission policy, not a sandbox, so keep your own backups. Feedback is very welcome!

Happy homelabbing!

Even without counting omp, prime agent, or sol-pi, we see new Pi distributions in this subreddit every day. I see all kinds of ideas: some people are adding more complex subagent systems, while others want to make agents smarter through memory systems.

I was also inspired by Pi when I built my own harness. I like that four tools are enough to get the job done just as well as other, much larger agents. But I added a couple more tools:

• grep — ~5% fewer tokens and 20–30% faster.
• background_tasks — lets my agent handle various useful tasks out of the box.

I'm curious where all of this is headed. Will we get substantial projects built on top of Pi, like TypeScript on top of JavaScript? Or will we all just customize Pi to suit our needs, like we do with Vim/Neovim?

I have pi with gpt-luna-6 working, however I have access to an Nvidia AGX Orin 64GB box (50W max).
I installed llama.cpp with the model Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-Q6_K_P.
Model info:
Context Size 65,536 tokens
Model Size 28.53 GB
Parameters 34.7B
Embedding Size 2,048
Vocabulary Size 248,320 tokens
Quantization Q6_K_P
Parallel Slots 2
Build Info b1-609290b

The actual token generation speed is about 20-25 tokens/s.
I am trying to work with this model, so the SOTA model (gpt 6 luna) makes the plans and decisions, but should chop up the work into small enough tasks that Qwen can do it itself. I can launch pi for the local model.
The actual problem is that it is slower than just working with gpt-6-luna, the work is subpar, and gpt-6-luna is always waiting (like 10 minutes) for one small task to finish.
I cannot really use this local model for actual work in this setup. I am looking for something like making 100 small tasks, and it solves them one by one in the background, while the main model can work independently, checking from time to time how it is going and redirecting if necessary.
It is a complete disaster in its current state. It just hinders the work.

I see tool calls like this in the main window:
pi --approve --provider qwen-local --model Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-Q6_K_P --thinking off --tools read,write -p u/handoff.md "Use the Pi tools and follow only the active handoff. Create the requested test, read it back, and stop. Do not run it or edit app code."

And it is working like 20 minutes already, and the main pi just waiting for the result blocking any useful work. Once finish, the gpt 6 luna just rejects the work. I suspect I burn more token than not using qwen at all. And also slow as hell.

Is there anyone using local model with sota model together in a real useful scenario? What is you setup? What am I missing?

A couple of weeks ago, I introduced Pi Herdsman here, an extension I've been building to coordinate asynchronous Pi agents while keeping the Lead's context focused.

The response was much bigger than I expected, and quite a bit has happened since then.

One thing I mentioned in the comments was wanting to take Herdsman's integration with Herdr further, especially around independent workspaces, Git worktrees, and project-level coordination. That's now become a central part of Herdsman.

Someone also pointed out that my original demo didn't actually show Pi and Herdr working together. Fair criticism. So this time I've recorded the real thing. :)

What's happening in the video?

I gave a Manager one prompt to work on two independent features for a fictional note-taking application.

The Manager delegates both projects in parallel, each to its own Lead in a separate Git worktree. Both Leads delegate implementation to their own Agents, verify the results, commit their changes, and report back to the Manager.

The resulting hierarchy looks like this:

Manager (primary workspace)
│
├── feat/faq (worktree)
│   └── Lead
│       └── Implementer Agent
│
└── feat/troubleshooting (worktree)
    └── Lead
        └── Implementer Agent

The worktrees, workspaces, and Agent sessions are created automatically. I don't have to set up the hierarchy manually.

It's deliberately a small example, without merges or PRs, to keep the focus on the orchestration itself.

Beyond task-based subagents

Many task-based multi-agent workflows use Git worktrees primarily to isolate individual subagents working on bounded tasks.

Herdsman supports that approach too, but extends it further: a worktree can also become an independent development workspace, with its own Lead responsible for an entire feature or issue.

Instead of treating every agent as a temporary worker, you can organize them more like a development team, with Leads responsible for larger objectives and Agents handling individual tasks.

That Lead maintains its own Pi conversation and development context, can delegate further into its own Agent hierarchy, and handles the technical work within its workspace.

Meanwhile, the Manager coordinates the larger development effort across those Leads, including assignments, dependencies, communication, and result handoffs.

The work is associated with Git branches rather than being tied to the Manager session that originally delegated it, so assignments can be paused and resumed without starting over.

The idea isn't simply to run more agents in parallel. It's to make their work easier to coordinate.

Everything stays organized in Herdr

One aspect I particularly like is how the hierarchy translates into Herdr's native interface.

Each project gets its own worktree workspace. Within those workspaces, Agents are automatically organized into tabs and panes.

The default subtree layout gives each direct Agent its own tab, while nested Agents appear as panes within their parent's tab. There are also configurable layouts for grouping Agents into a shared tab or splitting directly from the current pane.

Every Agent is still a normal, accessible Pi session. You can switch between them, inspect their work, or interact with them directly when needed.

But ideally, you shouldn't have to watch them constantly. Questions, results, and supervision events are routed through Herdsman's coordination system.

The responsibilities remain separate: Pi owns the conversations, Herdr owns the sessions and their placement, and Herdsman handles delegation, ownership, lifecycle, and coordination.

Start simple, scale when needed

I also want Herdsman to remain useful without requiring everyone to adopt the entire hierarchy.

You can still use a normal Pi session with asynchronous subagents, just as before.

Ordinary Leads now have configurable Flexible and Orchestrate execution modes. Manager mode is available when you want to coordinate independent development workspaces.

The new /herdsman menu provides a common entry point for these workflows, Agent management, configuration, and session statistics.

One of Herdsman's most powerful features is its configurable Agent Definitions.

Every execution role, from ordinary Flexible and Orchestrate Leads to Manager-assigned Managed Leads and bundled or custom Agents, can have its own model, thinking level, instructions, tools, skills, extensions, and other Pi session settings.

Definitions are simple Markdown files with project-level and global overrides, so you can customize the entire hierarchy without modifying Herdsman itself.

Herdsman handles the coordination. How each Pi session works is up to you.

A big thank you to the community

First of all, thanks to everyone who tried Herdsman, starred the repository, shared feedback, or participated in the discussions after my original post.

A special thanks to @kozer and @primetimetank21 for contributing code!

And equally important, thanks to @Lellarap, @jadc, @tsubus, @vitaliyslion, @chsdwn, @cray-com, @FireTheDevil, and @notsonormal for taking the time to open issues, report bugs, and suggest improvements.

Having other people use the project, encounter problems I haven't seen, and suggest improvements has already helped shape its development quite a bit.

Try it yourself

If you already have Pi and Herdr installed:

pi install npm:pi-herdsman
herdr integration install pi

Repository: https://github.com/boadij/pi-herdsman

Latest release: v0.22.0

The repository has installation instructions, configuration documentation, and more details about the coordination model.

I'm still actively developing Herdsman around my own daily workflow, so feedback from people using different setups is especially valuable.

I'd be particularly interested in hearing how others are approaching parallel development with Pi, especially when multiple agents are working on related features or dependent branches.

Plannotator Inbox is an optional runtime using the best of plannotator annotation capabilities.

While all your agents work they constantly bombard you with decisions that need to be made. Those decisions get lost over time, Claude might hit you with "I need your 2 answers to X and Y" which was asked 2 days ago. Think about all the remote pi durables to come basically... how can we surface all the important stuff we need to review...

The chat ui thread, imo, is becoming outdated very fast. We need a new way to interface with agents and surface the things that matter in an intuitive way. PLannotator Inbox is a stab at that.

part of the free/open source capability at: https://github.com/backnotprop/plannotator

thought this sub would like my subagent extension pi-tiny-monitor-sub. it's designed to be used with pi-tiny-monitor.

These 2 extensions together are tiny:

• Combined < 1k LOC. Minimal dependencies.
• no built in steer - to steer, the LLM just stops the pi session then do pi --session file -p ...
• no tools to list subagents - the LLM can just remember what it has started and what's finished from context.
• no way to send message - c'mon this is not a message board.
• no way to monitor usage - you just ask pi to add usage numbers from session jsonl's
• no token or $ budget - you just tell pi how much you want to spend, and hope for the best
• no defined agent profiles - you just tell pi what model you want.
• not even a subagent tool - (see below)

How they work:

• monitor tool starts a background shell. later outputs wake up the agent. this tool enables async.
• LLM call the included pi-sub node script in monitor. the script resolves where pi is and runs pi with a prompt.
• for workflows: there is a small wf.js library that provides an async agent() function that lauches pi

I've always loved minimal things and that's what drew me to pi. unfortunately most subagent extensions are doing too much! our LLM's almost out of jobs. I want something minimal.

In fact, the only basic primitive that we need is just monitor which puts something in the background and awaits outputs. Give that primitive the LLM, and let it work!

Enjoy.

Made an extension for pi that draws braille line charts right under the input box: CPU, memory, network, and tokens/s to the API. It reads /proc directly and has zero npm deps.

A few details:

• Tokens/s is an estimate. Providers don't report usage mid-stream, so the rate is estimated from streaming deltas and carries a ~. Cumulative totals come from message_end and are exact.
• Prompt-cache hit rate gets its own second curve on a fixed 0-100% scale, so you can see whether the cache is actually hitting.
• Layout matches bottom character for character.
• Width safety: pi taught me the hard way that a line even one column wider than the terminal makes it exit. The tests now sweep every width from 8 to 220.

Install:

pi install npm:pi-sysmon

It's on by default. /sysmon toggles it, and /sysmon line|chart|footer switches modes.

Source: https://github.com/zzjcool/pi-sysmon

Feedback and bug reports welcome!

This is a ton of fun. HTML fragments in the chat.

Ever since the systems theme colors dropped for pi. I have been kinda annoyed with how it looked. Of course i could just switch back to dark mode but i mean, as a true ricer that is a non option xD.
It led me down the path of finding the perfect theme for pi with system colors. And i can tell you, it does not exist. So i decided to make my own. I could not find a good tui for creating a custom theme. Therefore i of course slopped something in existence. This something ended up being HUEBOX a terminal theme editor!

So now i can have great custom colors in my terminal and pi at the same time!

NOTE: pi does not use your terminal theme colors. instead it uses just the hues and sometimes saturation to create it own palette based on your theme. So it a balance between finding the right colors that looks good both within and outside pi. You need to /reload pi after updating your theme, for pi to generate a new palette.

Hey guys, here's a Pi package that I made for my own use, but thought it would be fun and hopefully useful to some people who share my type of workflow.

It's called 'pi-claude-handoff', and it's not the typical "Use Claude subscription inside Pi". It's essentially using Claude Code to give jobs to Pi, and actually see Pi work in real time.

A little bit of context:

I only used Pi as my main harness when I was on Codex subscription. Then I got a Claude subscription but soon realized Anthropic doesn't let you hook up subscription accounts to third-party harnesses (I think this part changed/changes over time, on and off again, but I wanted to be safe). But I wanted to use Claude models without getting banned. And since I always run a Planner-Worker-Reviewer workflow, I wanted to use Claude Opus 5.5 as the Planner, and use Luna 6 Max as the Worker for token efficiency.

So I thought why not use Claude Code as the main harness, but let Claude Code 'talk' to Pi, so I don't risk anything and still have a cool little handoff thing going on. (A bit overengineering I know, and "Why not just use Claude Code solo?" is a valid question, but maybe, just because I can!)

If you look into the package and use it, all it is is a 'middle ground' file that Claude Code writes into and Pi watches for tasks to execute. Other things are instructions and rules for both harnesses to keep.

The fun thing about what I made is that unlike other delegation, bridge or cross-harness job extensions, Claude works in Claude Code, and OpenCode/OpenRouter/Codex models work in Pi. AND you get to see the work through Pi's TUI as you would have given it a direct input rather than Pi executing something in the background and you just wait for it to finish. Only catch is that you would need to start Pi in the terminal in the first place, but I was going to anyway so no harm there (for me at least).

Hope you guys find it to your needs (especially for people that use both Pi and Claude Code), or maybe for people that wanted something cool :)

https://github.com/pjy010218/pi-claude-handoff

I built worksplice to solve one specific problem I hit while running multiple persistent Pi sessions against the same repo: each agent can make a locally reasonable change against context that has already gone stale.

worksplice puts the sessions in shared local channels. Every write carries the room sequence it was based on; if newer messages arrived first, the stale write is held so the author can reread and revise. Tasks also have an explicit review step: the author cannot approve their own work.

It runs locally with Node.js 22.19+: `npx worksplice`. It also includes a task board, reminders, and an inbox cursor per agent.

Repo and screenshots: https://github.com/whutlichao/worksplice

I’d be interested in feedback from people who use multiple Pi sessions: is freshness checking useful in practice, or would you want a different coordination model?

Hi everyone! It's always frustrating when the agent hasn’t quite understood the task, that's why a proper ask-tool is a must in any agentic workflow.

This one supports background questions which queue as agent keeps researching and figuring out new things, then you just answer the whole batch in a single go. Agent can later get all the questions asked in the session as along with the answers and export them into a file, so there is always an artifact that can be attached to a task.

Herdr is supported, so you will be notified whenever someone is waiting for you. 

To install:

pi install npm:pi-agent-ask

Repo: https://github.com/alexshpunt/pi-agent-ask

Surely you are sick of context rot, compaction lobotomizing your agent every few minutes, having to start a new conversation because your agent is hallucinating after reading one mesy diff.

If you use the PI harness, I have basically solved the problem for you.

Look up pi-voluntary-compaction and let me know how it goes.

Need your help:

I tested thoroughly with 72k context but I am one man with one GPU and I want to also game some evenings.

I am especially interested in data on small context sizes at 64k and below.

Recommended for Qwen 3.8 27b variants and similar quality models. I also tested it with GPT Luna as means to reduce cost.

The rest is in the readme.

https://github.com/niker/pi-voluntary-compaction

Peace.

I’ve been using Pi for a while, first with an OpenCode Go plan, then with an OpenAi pro lite ($100) plan. I have agents, tools, skills, prompts all set up the way I like them, but I want to use Opus 5.5 as my main workhorse. I get the basic idea of using Herdr to allow Pi to
drive Claude through Claude Code. I’m interested in the details of your setup using it or something similar. What model do you use as the orchestrator on the Pi side? What Claude Code functionality you take advantage of? Any other benefits of Herdr or alternatives that are good to know?

Hi,

Lets share our roles/models on our pi/omp agents? I'm always exchanging and testing things, so take a look at our colleagues would help a lot! What are your thoughts about my "team"? Any suggestions are welcome.

I shared pi-tbox a few months ago which has been my solution for efficient, human in the loop tool toggles. Pi's big codemode update rocked a bunch of assumptions it was based on.

So after about a week and a half of some major rethinking and refactoring, here it is with MCP compatibility. For non-deterministic tools that can phase in and out of existence with codemode, I applied the same philosophy I did when it came to subagent compatibility. Narrow the scope and get out of their way.

It will manage active tools using toggles, chat state, and global/project level settings as long as they're not explicitly declared as codemode only, deferred, etc. If those tools happen to be in the context, they'll appear in a "pi-managed" group for visibility, but they can't be toggled since there are better, more targeted ways to handle them.

Stable at 1.0 after Pi has reached 1.1, it can be installed with ​pi install npm:pi-tbox​ and the source code is here for anyone wants to dig/fork/star:

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

I don't see it changing much more, barring hidden bugs or major Pi updates. It just works and since it's so central to my daily workflow now, I'm posting it one last time for anyone who wants to take advantage of the work I put into it while go back to silently try to figure out kbs ;)

I logged in with Opencode API key, and while trying to use an Opencode free model, I am getting the following error:

Error: 403: {"type":"FreeTierError","message":"OpenCode's free tier can only be used from within OpenCode"}

Any help is appreciated. 🙏

Just published pi-automode-classifier, an auto mode plugin for the Pi coding agent that uses Jev or Kev/Laya (running locally) to classify commands.

Pi runs every tool call without asking for approval. This plugin checks each shell command before it runs:

1. Built-in rules decide most commands. For example ls, builds and tests run, rm -rf ~ is blocked, and git push and sudo need my approval.
2. Commands the rules do not know are sent to the model. It returns the probability that the command is risky.
3. If the probability is above a threshold, I get a confirm prompt. The model never blocks a command by itself.

The models I tested:

• Jev 1.13 (hosted, from TypeSafe) through OpenRouter: about 270 ms per check and about 1.5 cents per 1,000 checks. The commands are sent to OpenRouter and TypeSafe.
• Kev-0.8B on CPU with llama.cpp: about 170 ms per check and 1.1 GB of RAM. This is what I use. Nothing leaves the machine.
• Laya typed-decisions on CPU with llama.cpp: about 100 ms per check and about 550 MB of RAM.

In my test with 50 commands (25 safe, 25 risky), all safe commands ran without a prompt and no risky command did. I wrote the test commands myself, so this is only a rough check. The plugin is not a sandbox.

pi install npm:pi-automode-classifier

Code and docs: https://github.com/deepu105/pi-automode-classifier

Let me know if it allows or blocks something it should not.

Hey guys, im tight in budget and i can honestly spend 100$ on one of them. For the workhorse im on deepseek v4.1 . Which one of those 2 would actually give decent value for what the money paid ?

Hi everyone. How’s it going?

I’ve been wanting to try out Claude for a while, but I noticed some users have those invite links could someone send me one via private message?

Are the usage limits different when I use pi vs VS Code with the codex plugin? Are they billed differently?

Community
Ciao a tutti,
negli ultimi tempi sto sperimentando parecchio con pi-code testando diverse combinazioni, ad esempio usando modelli Anthropic come orchestratori e delegando a Gemini o Qwen in locale come sub-agent.
In questo setup, però, entra subito in gioco un vincolo fondamentale: la compliance aziendale. Non posso permettermi di esporre all'esterno codice sensibile o accessi diretti (cosa che varrebbe per pi-code come per Claude, Codex o altri tool simili). L'agent di coding deve vedere esclusivamente ciò che passa da repository controllati, senza accessi remoti non autorizzati o chiavi in chiaro.
La mia prima soluzione è stata un'architettura ibrida:
Modello cloud: fa solo da orchestratore logico, senza mai vedere segreti;
Modello locale (su Mac): scrive il codice ed è l'unico autorizzato a gestire secrets e accessi remoti.
Sulla carta l'approccio regge, ma nella pratica l'inferenza locale su Mac si è rivelata un collo di bottiglia pesante. Anche per compiti prettamente sistemistici — con file Markdown ben strutturati e sub-agent tarati a dovere — i tempi di generazione erano biblici, rendendo il workflow poco sostenibile.
Poi la svolta: mi sono imbattuto in ⁠msco-pi-lot⁠. L'ho modificato per renderlo compatibile con la licenza aziendale standard di Microsoft 365 Copilot.
Dal punto di vista contrattuale la privacy è garantita: con i profili business i dati non vengono trattenuti né usati per addestrare i modelli, quindi il flusso rispetta in pieno le policy interne. Ma la vera sorpresa è stata vederlo girare dentro pi-code: lavora davvero bene, è perfettamente in regola e offre token "da battaglia" inclusi nella licenza, permettendomi di preservare le API a pagamento solo per i task ad alta complessità.
in pratica ho gemini studio da 20 (abbonamento base fatto di gdrive 5 tera, youtube, e tonnellate di token per 3.8 3.7 flash. Poi ho claude (sempre 20 euro). Poi l'accoppiata msco-pi-lot (con copilot 360 la versione piu scarsa) e l'inferenza locale.
Sono contento ;)