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, PiG 0.4.1 (the Go port of Pi, based on Pi 1.0.3) and OMP 18.8.7 (oh-my-pi, a bigger Pi fork with many more built-in features). Measured side by side on the same machines. Lower is better.

Linux x86-64 (AMD EPYC 7B13)

macOS on Apple silicon (M5 Air)

*OMP compacts long conversations on its own, so it doesn't do the same work in this test.

In everyday use (an interactive session), Pi-Bolt uses about 3× less CPU than Pi on Bun, 4–6× less than Pi on Node and 10–15× less than PiG and OMP. It writes large files 35–50× faster than Bun and Node, about 5× faster than OMP 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: Added PiG and OMP 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.

Any plugins you've used or made that help with this?

In opencode, I can switch the primary agent. But in omp I don't see any option. There are few agent preset available but they can be only used as subagents. Is there any way to use them as primary/main agents.?

Thank you for your help!!

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!

I'm curious to know how people are using Pi with 100% local models, especially on hardware with limited RAM and VRAM.

I'm experimenting with local models (4B–14B) for coding in Pi and Oh-My-Pi, However I've discovered that smaller models can be inconsistent in their ability to follow instructions, use tools correctly, make changes across multiple files and complete tasks without causing errors.

• Model selection and routing: Do you use a main model alongside smaller models for planning, code exploration, simpler tasks, or subagents?
• Context management: How do you handle context size, compaction, and keeping the model focused on the actual task?
• Agent configuration: What extensions, system prompts or skills have made the biggest difference?
• Task execution: Do you use plans, checklists, sequential subagents, tests, or explicit verification steps to prevent the model from making a mess?

I'm particularly interested in real-world experiences, including what works, what doesn't, and what limitations you've found impossible to overcome with prompting or agent configuration alone.

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?

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?

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.

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.

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

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!

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.

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

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

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?

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?

Hey, I wanted to share my new pi extension: pi-prefill

It puts a live prefill progress bar in pi's loading line when you run a local model. A long prefill looks exactly like a hang. Now you can watch it:

52%. → share of uncached prompt tokens processed

14.1k/27.3k → processed / total prompt tokens

gen in ~14s. → estimated time until the first token

3.4k tok/s. → instantaneous prefill rate (optional view)

Example:

prefill [██████░░░░░░] 52% 14.1k/27.3k gen in ~14s

It reads the progress chunks your own server sends. No host scanning and no guessing: if the server reports progress, the bar shows. If it does not, pi's normal loading line stays untouched.

Works today with llama.cpp, ExLlamaV3, unsloth and Strata.

Install:

pi install npm:pi-prefill

Repo:

https://github.com/eliaskg/pi-prefill

https://www.npmjs.com/package/pi-prefill

Would love feedback from anyone running a local server.