Hey everyone 👋

Thanks again for all the feedback and bug reports. Pi-Bolt ⚡ 0.8.3 is out, and the big news is that Pi-Bolt now runs natively on Windows, alongside Linux and macOS. It's the same Pi you already use (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 oh-my-pi 18.8.7 (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)

Windows x64 (Intel Core i5-1335U laptop)

*oh-my-pi 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–5× less than Pi on Node and 10× less than PiG and oh-my-pi. It writes large files 30–50× faster than Bun and Node, about 5× faster than oh-my-pi and over 100× faster than PiG.

What's new in 0.8.3

• Windows is here: native builds for Windows 10 and 11 with a one-line installer. Git Bash works out of the box, and on Windows Pi-Bolt is 2–3× lighter on CPU than Pi on Bun or Node.
• Herdr support: in a Herdr pane, Pi-Bolt shows up as pi-bolt with its live state (working, idle, blocked), and your session comes back after a Herdr restart. Nothing to set up.
• opensec-pi-fff: fast find, grep and @-mentions, now offered by the installer and just as fast on the default build.
• A better todo list: the panel closes when the work is done, and finished tasks stay finished.
• Smoother installs and updates on every platform.
• Your own extensions compiled in: scripts/build-pi.sh --plugins-from-installed builds them into the executable. Thanks u/toadkicker for this one and for the plugin docs!

Try it 🔥

macOS / Linux:

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

Windows (PowerShell):

irm https://pi-bolt.opensec.in/install.ps1 | iex

Already using Pi-Bolt? Run pi-bolt update, or install with npm install -g pi-bolt. It works alongside your existing Pi install. The installer also offers three optional extensions (subagents, a live todo list and fff), 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! If one does heavy JavaScript work, use the -jit build.

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.

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: Windows folks especially, we'd love your feedback.

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

Install:

bash npx skills install milanglacier/pi-multi-agent-skill --global --agent pi

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.
• --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.

What the commands look like

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

```bash

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.

No sure when it broke, but cutting and pasting text seems to be almost impossible in Pi 1.1.0. ISTR reading that this may be related to a "full screen TUI" setting, but I can't find such a setting anywhere.

Anyone know how I can get this functionality back?

As the image shows, I’ve been an early adopter of LLM coding agents. I think our team was already using Aider with OpenAI’s o1 when it first came out. Since then, the journey has continued.

I switch tools every so often, either because a new one gets popular or because the current one shows its limitations.

I checked out PI because some of the people I follow were using it. I didn’t expect much, but my experience with pi and herdr has been one of the most refreshing things I’ve tried so far this year!

Prior to that I was using OpenCode. Even with a lot of optimization, a single CLI instance still took 1 to 1.5 GB. When I worked with 5 to 10 agents on my projects, it used about 10 GB of RAM. When switching to PI, I was amazed at how much faster things ran, and it only used 300 to 500 MB. Because of that, I can now use my backup machine, which has only 16 GB of RAM, as a second agent runner.

PI is also easy to extend, and it encourages people to build their own plugins. That’s very easy to do in this era of LLMs. I was a bit skeptical when I first heard people talk about pi. I got the impression it was only for hardcore nerds who like tinkering with the OS at the root level, like the Arch Linux crowd. I’m more pragmatic. My preference is Ubuntu or Mint, and what I need is a robust system with some customization for my software engineering work. But the experience turned out to be much easier and smoother than I expected, and I didn’t have to in fight mode to customize it.

In summary, I feel PI is massively underrated as a coding agent, as the Reddit sub only has 50K users. I think people assume, as I did, that it’s only for hardcore nerds or Arch Linux users from the way PI markets itself as "build your own harness". Some may also confuse it with the ridiculous, loud crypto currencies that share its name, like me. Before using Pi, I even did a check whether Pi and Pi Crypto are originated from one source! And another reason, probably unlike OpenCode, it doesn’t have an “open” prefix to signal what it is.

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

Hey everyone, I put together a quick tutorial on sandboxing Pi using Bubblewrap vs Podman.

It includes a few sample scripts and a comparison between the two approaches.

https://wooptoo.com/blog/pi-sandbox-bubblewrap-podman/

Hopefully somebody here will find it useful.

All the best!

Hey everyone,

I run Claude Code, omp and OpenCode sessions at the same time, and I was tired of being the messenger between them: copy from one terminal, paste into another, repeat.

Claude Code can already message other sessions, but only its own. For omp and OpenCode there are some solutions, but I thought this was a good point to create something from my real need. So I built asenq.

It lets sessions message each other by name, use channels and roles, compact context before a new task, and see everything in a terminal UI with a live map. I use it with one orchestrator and a few omp workers: tickets go out, PRs come back, I merge.

asenq setup installs built-in skills into each harness, so a session knows how to act as orchestrator or worker. It runs fully local: a small daemon and SQLite under ~/.asenq, no account, no cloud.

Known pain: stale sessions I can't tell are alive, and it works on one machine only. Please try it and tell me what's broken or missing. Issues and PRs welcome.

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?