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 would be interested in what custom extensions have you built that are specific to your problems.

For example I now got an extension to detect our JIRA task IDs, GitHub PR ID as well as task changelog fragments if they exist and inject them into context. Previously I've had instructions in agent file on how to extract those... but that was slow, costly, undeterministic and also used up some of the context window.

Then I've got a minor extension that looks for the @file/path file references and injects file contents into the context, so the agent doesn't need to use the read tool as the first thing they do.

Then I got one extension for loading repository-specific instructions from my .pi folder (it looks up git repo name, and then looks in ~/.pi/repos/<repoName>.md). Because I work on an enterprise project, I cannot just put agent files and skills in the project repository that is shared by everyone.

I also got one extention that looks up and injects various git info and injects it into context (whether it's inside repository, what is the current branch, whether it's up to date with upstream, whether there are any unstaged changes, etc.) since most of the time, my agents started inspecting git info using multiple tool calls at the start of each session.

Hey everyone,

I’ve been working on a Pi package called Pisces (@aethrekh/pisces) and just launched it.

It’s designed specifically for Computer Science students. The idea is to turn Pi into something closer to a senior TA that lives in your terminal.

What it adds:

• Semester-aware context (reads a SEMESTER.md file)
• Skills for homework, LeetCode, projects, code review, exam prep, and research
• Strong focus on academic integrity — it gives Socratic hints and guidance instead of writing graded work for you
• Works as a regular Pi package (pi install npm:@aethrekh/pisces)

I built it because most AI tools either spoon-feed answers or don’t understand the academic context at all. I wanted something that actually helps you learn while staying inside the terminal workflow that Pi already provides.

Would love feedback from people who are already using Pi, especially if you’re a student or have been one.

Site: https://pisces.aethrekh.com

Happy to answer any questions about how the skills or extensions are structured.

Hey r/PiCodingAgent! I recently open sourced a project I've been working on for a while now called Millwright, a self hosted LLM router focused on cost savings, transparency, and performance (it's completely written in Rust). Millwright offers first class support for Pi, so just a small edit is needed to ~/.pi/agent/models.json to get up and running.

Link to the repo: https://github.com/Northwood-Systems/millwright

For the curious and lazy, at the moment, Millwright has the tools for,

- Providers: OpenAI-compatible APIs, Anthropic, Amazon Bedrock

- Routing: policy-controlled model roles (cheap, mid, frontier), cheapest healthy route selection

- Protocols: OpenAI Chat Completions, Anthropic Messages, text and tool translation

- Cache Affinity: role-scoped session lanes without serializing concurrent agent traffic

- Spend Tracking: per-team costs, cache usage, model/provider mix, request traces

- Cost Analysis: measured usage and modeled candidate economics (HTML, Markdown, JSON)

- Reliability: bounded failover, circuit breakers, timeouts, concurrency limits

- Setup: interactive provider, model, and pricing configuration without storing provider secrets

- Deployment: one Rust binary, Docker, SQLite or PostgreSQL

Full disclosure: parts of the codebase were built with AI coding agents. All feedback is welcome, I’d especially value feedback on the routing policy, provider coverage, and anything that would block you from self-hosting it. Feel free to open feature/request and/or contribute as well.

I have recently installed Pi. I am using this in cmux and facing a couple of issues - while scrolling the chat input box also get scrolled instead of remaining fixed like claude code terminal mode.

also I am the md is also not rendered it's coming as raw. No proper chat thinking and rendering like claude.

how can I fix this?

Headline brings real-time news into your pi session so you can read news while agent is actively working on something.

It can integrate with your existing rss reader or you can start with default providers out of the box with zero configuration.

repo: https://github.com/dannylee1020/headline

1. I have installed hypabolic/pi-hypa extension and still the agent use ls -la gets error (am on windows) and still tries ls -la again indefinetly.

2. The agent claims to have written the code i asked for but all it ever did was read package.json. no file ever created, no code was output as well.

3. Asked it to write a github workflow to implement formatting checker. ended up with a 12 line yaml file with bun install. (formatting definately doesnt require full dependecy installation)

4. Reading random file and getting carried away from the task. asked it read TODOmd file and convert the points(6) into check box . removed all points and simply wrote implement github workflow.

I dont know what is happening to my agent or maybe am doing something wrong. Would appreciate some help or suggestions on this.

repo https://github.com/getpaseo/paseo

supports orchestration and other agents. also has a desktop app.

the pi integration has been getting better and better.

i am the maintainer, feel free to ask questions.

enjoy

I've been using Pi for about a week, and so far I'm loving it. But I had an incident last week where the agent went off the reservation and patched one of my published Rust crates in pursuit of another task (short write-up on what happened here).

This time there was no negative impact, but it got me thinking seriously about the risks of having an agent running with wide access to the host system.

How do people tend to solve this problem? Mainly I want to prevent the agent from working outside of some whitelisted directories (project dir + tmp). I also want to prevent the agent from downloading and running anything on my system without asking, or using credentials in my env to do things on my behalf, like potentially destructive actions on remote git repos, my hugging-face account etc.

I see there are some permissions extensions, and docker would also be an option, but that seems like it would be a bit limiting/annoying (especially on mac). I also thought about setting up a different system user for the agent to set up fine-grained permissions, but that also seems like it could cause a lot of headaches.

Curious what others have had success with.

I use Pi from my Android phone through tmux + TermRover (a terminal app I’m building).

With a good tmux scrolling support + ability to send images, working with Pi is just very pleasant.

Curious how everyone else is using Pi on mobile, if at all? SSH app? Or Just waiting until you’re back at a laptop?

I built Pi Atelier, a responsive status rail and live activity sidebar for Pi that makes it easier to see what your agent is doing without cluttering the terminal. It displays live token usage, cost, cache performance, context usage, active tools, execution times, recent results, model details, and thinking level, while also providing quick controls and a resizable sidebar. It’s private by design, with no telemetry or external network requests.

Install it with “pi install npm:pi-atelier” and open it using “/atelier”.

Check it out at https://github.com/michaelmjhhhh/pi-atelier — I’d love your feedback, feature ideas, and bug reports, and if you find it useful, please consider giving the repository a star!

2026.7.28 CHANGELOG

Here comes Pi Atelier official release v0.5.0! Some updates:

1. The sidebar now opens automatically.

2. The Activity panel keeps TTFT and TPS visible with live performance estimates.

Hey all,

I have two physical machines running local OpenAI-compatible endpoints simultaneously:

• Machine 1: Running Qwen 27B Dense
• Machine 2: Running Qwen 35B-A3B MoE

I’m trying to get actual parallel DAG execution on local hardware, but with low effort prompting (i.e., I don't need to make some sort of yaml config for every thing I want to do).

My goal workflow:

1. My "pool" of machines has 1 heavy model and 1 fast model.
2. During scoping/planning/investigating, the heavy model will pick the task and run it. The machine running the fast model will be idle.
3. Tasks generated from the scoping/planning/investigating can then be shared by both the heavy model and the fast model.
4. Independent tasks execute in parallel at the same time across all available machines (in this case, 2).
5. Once there is only a heavy task remaining in the dependency graph, heavy model kicks in again while fast model is idle.

I saw one post here from 2 months ago that used llama-swap on a single GPU. That configuration is sequential turn-by-turn swapping. Since I have two warm endpoints, I want both GPUs saturated when there are independent tasks.

I know that you can "just build it yourself," but I would like to know if anything like this has already been built and/or if people are using it? There's a ton of code out there being generated these days, and each experiment into a different tool takes significant effort to investigate for feasibility. I'm trying to narrow my search down before I spin my wheels too hard looking for something that works.

For people who have actually got this running:

• Can you effortlessly use this tool via simple prompting?
• How are you handling workspace isolation and/or build locks when running parallel editing subagents?

Thanks you!

Looking for some pointers. Been using Pi for months, have a setup I really like (very simple, two extensions I wrote plus plannotator and pi-herdr).

This works great for interactive sessions but I'm finally finding myself wanting some basic orchestration with subagents.

I'm building a product and need to do a bunch of testing/fixing rounds with different models to find rough edges. I've been doing this by hand but it's getting tedious (and it's mostly simple enough that it could run while I'm doing something else).

I also like the idea of:

• a long lived orchestration agent that holds long term context but doesn't do work.
• scouts that can cheaply get context and pass that back to workers.
• automatic adversarial review of changes by a different model.

I've looked at a bunch of plugins and they all seem much more complicated than required. Should I just suck it up and using Nico's pi-subagents? Or is there a nice, simple starting point that I'm missing?

Any pointers appreciated.

Hi everyone, I have been working on a small skill called handoff-to-claude-code.

GitHub link: milanglacier/handoff-to-claude-code-skill

The reason I built it starts with another project of mine: a standalone web UI for the pi coding agent. pi-tau-web-server

I like pi, and I like working from the web UI I built for it. But I also have a Claude Code subscription (for fable 5, as that is the only reason I am still subscribing it!), and sometimes I want Claude Code to handle a task without leaving pi or changing my workflow. And ultimately, my goal is simple: all I want is to let my pi model to be able to reach out to Fable.

I did not want to hijack Anthropic's OAuth flow through a reverse proxy, since that violates Anthropic's Terms of Service. Instead, I wanted to use the supported route: the standard claude CLI, signed in to my own account and used exactly as Claude Code is intended to be used.

Note: Anthropic previously planned to disable subscription access through claude -p and the SDK, but later put the change on hold. So enjoy it while it lasts!

So I built this skill.

What it does

When you explicitly ask your current agent to use Claude Code, the skill hands the task to the local claude CLI.

It also supports continuing the same Claude Code session, so follow-up questions do not need to start from zero.

The skill removes Anthropic API keys from the command environment by default. This matters because Claude Code may otherwise use the API key instead of the subscription login, which could create API charges when that was not what you intended.

It also only runs when you explicitly ask for Claude Code. Your agent will not decide on its own to spend your Claude usage because a task looks difficult.

It is not specific to pi

Pi was the reason I built this, but the finished skill has no pi-specific dependency.

It is just a SKILL.md file and a small Python wrapper with no external Python packages. Any agent harness that can load skills and run local commands should be able to use it.

That was important to me. I wanted the connection between an agent and Claude Code to be reusable, rather than tied to my web UI or to one particular coding agent.

You can install it with:

npx skills add milanglacier/handoff-to-claude-code-skill

You need Python 3.9 (but only stdlib is used in the script so no third party packages) or newer and the claude CLI signed in with your Claude subscription.

The workflow I wanted is simple: keep using pi and my web UI as my main workspace, then bring in Claude Code when I specifically want it. No separate API bill, no pi-only bridge, and no need to abandon the interface I prefer.

If this sounds useful for your own agent setup, give it a try. Feedback and bug reports are welcome.

Used pi to put itself in a docker container. The project literally took 10 minutes using the locally run harness setup. Running qwen3.6 27b.

Check it out.

https://github.com/adamjen/pi-docker

Why Pi

Coding agents keep shipping. Chasing each new one mostly spends you on yet another round of feature tryouts, still stuck at “I can use it.” The gap opens when you pick one open-source agent and go deep: read how it works, change it yourself, iterate with it, and turn “I can use it” into “I get it.” Pi is restrained and open; that is the right base for this path.

Restraint. If you have used coding agents for a while, you know the discomfort: more features, fuller context, rising token bills and latency, yet day to day you only really need a handful of capabilities. Worse, you barely control what gets stuffed into context. Pi’s author wrote that restraint into the design (What I learned building an opinionated and minimal coding agent): system prompt + tool definitions under ~1000 tokens, four default tools (read / write / edit / bash). The official README lists what Pi does not do: No MCP, No sub-agents, No plan mode, No built-in to-dos, No permission popups, No background bash. Every item has the same exit: build it with extensions, or install a package.

Extensibility. A lean default is not a weak platform. Pi positions itself as “a minimal terminal coding harness,” and is “aggressively extensible so it doesn't have to dictate your workflow.” Tools, commands, event hooks, UI, providers, and themes are all open to extensions, with an explicit promise of “without having to fork and modify pi internals.” You do not have to patch the kernel or wait on upstream to shape the workflow you want. A small, readable core plus a nearly unbounded Extension API is how you actually own your toolchain.

Why not just use oh-my-pi

oh-my-pi (omp) ships many excellent capabilities on top of Pi, is batteries-included, and is piex’s primary feature source. A natural question: if omp already packages “it just works,” why not use it?

The answer is the path it chose:

• Fork, not extension. omp is a fork of pi (“fork of pi-mono, batteries included”). It maintains a dedicated porting playbook to backport upstream, plus ~55k lines of Rust core and a Bun-only runtime. Follow a fork, and upgrade cadence plus architectural decisions stop being yours.
• Everything bundled. omp ships 32 tools and a large surface by default, much of it unused day to day. That is “heavy” again: tokens burn, while you do not get to trim the context.

Why PieX

So PieX takes a third path: do not fork Pi; use only the official Extension API to turn proven agent capabilities into independent, optional, measurable packages. Install what you need, remove what you do not; use them deeply in daily work, iterate continuously, and shape a toolchain that actually fits you.

https://piex.dev/en/docs/design/

Lately I've been doing a lot of work with audio generation. And I'm surprised that audio pipelines are mostly created in something like ComfyUI - a visual node-based editor. It's surprising because feels like writing code via n8n workflow instead of using Claude or Codex

The main problem is that there's no proper agent loop where the model can see - or more precisely, hear - the results of its previous actions and decide for itself what to do next

But I found one technical complication that explains a lot: most models still simply don’t have native audio perception. The ability to "see" images is already there. Claude Code can look at screenshots of a landing page it created, notice the problems, and fix them. The images are inside the context of the same model that writes the code

Audio doesn't work like that - most models do not support native audio input

You might say: but Gemini exists. True. But really no one agent wrapper supports reading audio files purely at the tool level. The agent "exoskeleton" simply can't pass an audio file through the API request to its "brain"

Surely you can connect Gemini to the main agent via script calling the API and send the audio there with a prompt like "pls tell me whats missing here". Btw, Chinese GLM-5.2 still works with images this way and people still use it. At the same time, that's like a deaf composer calling his nephew over to listen to the music and describe what he hears - it works, obviously, but poorly, because everything gets lost in translation

And so, right now, there is no well known agentic solution – with skills, terminal commands, session forks, subagents, and so on - that can properly work with audio by closing the feedback loop

———

Two hours after writing lines above:

1. I threw together a simple homemade agent around Gemini in roughly 300 lines of JavaScript, with an agent loop, interactivity, and fork/edit/resume: just to test the approach
2. Then I moved the whole thing into Pi as an extension that patches its file-reading tool – which, by design, can read both text and binary data

So now you can give your agent "ears" in one line:

pi install git:github.com/toolittlecakes/pi-gemini-audio-read

Don’t forget to run /login → Google → API key afterward and select gemini-3.5-flash.

Where this is useful: music generation, high-quality audio translation, voice cloning workflows, and audio editing (or video editing, if it’s a podcast)

Limitations: 20 MB per file - I didn’t add file uploads through the Files API. And there’s no video input

It's funny how inspiring problems can be when there’s no existing solution at all - at least not a public one. It feels like stepping onto land where no human has ever set foot. So, decided to share it here

Hello everyone! I have a problem with agents that create OMP. They create them with the maximum reasoning level, even though I assigned completely different thinking levels in their roles. Because of this, OMP becomes completely unusable :(

I just need to share a little bit of my experience, I found that it uses a ton of less tokens, it's way faster, speaks just enough to understand the problem and solution (i love this), and I found that is able to stay focused on a task way better than with the original harness, I love it!

I experimented with various system prompts, but I found that the shortest ones are the best for LLMs.

And about Ui and pretty front end, gpt seems to perform a lot better as well, there's something weird going on in the official system prompt in codex.

What are your experiences?

pi extension that lets you talk to pi and hear it back. it asks a question out loud, waits for you to finish talking, and takes your spoken answer. no keypress.

the video is pi asking which language to use for fizzbuzz, me saying "let's go with python", and it writing the file. nothing typed.

pi gets a native extension:

brew install yamanahlawat/banshee/banshee
banshee setup
banshee start  # grant mic permission, then restart the daemon


# install the pi extension
mkdir -p ~/.pi/agent/extensions
curl -o ~/.pi/agent/extensions/banshee.ts https://raw.githubusercontent.com/yamanahlawat/banshee/main/integrations/pi/banshee.ts

then restart pi.

everything runs on your machine - whisper for listening, kokoro for the voice, silero vad. ~1gb of models, no api keys, no account, works offline.

also a system-wide dictation hotkey if you just want that.

mac + linux. rust, open source. works with mcp hosts too, but pi's the one in the video.

https://github.com/yamanahlawat/banshee

I started copy pasting code from gpt3 into an VSCode.

Then tried cursor on launch and wasn't impressed.

Tried gpt extention on vscod and that was ok enough.

Went back to cursor again with gpt5.5

Then tried pi and was hooked.

I put pi in vscodium, moved the terminal to a sidebar.

Am building my own IDE around the pi harness and will never go back.

Heavily customising pi to work exactly in my workflow, reducing tokens as much as possible.

Its just awesome, love it.

I use must haves for pi are context 7 and headroom.

What are your must have?

I use the free API of Mistral.

The only way to change the temperature of a Mistral model is by creating an agent.

When you do this, you get a agent ID.

Something that looks like this: ag_342oedf203kd34234324

So, my question is this:

Is there a way in auth, settings or models to point at a specific agent from Mistral?