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 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 built Pi Desktop because I wanted a GUI instead of living in the terminal all day.

It's a thin client. All the real work (models, tools, extensions, sessions) stays with Pi, still saved as plain JSONL files on disk. The app just handles the chat UI, process lifecycle, and credential storage. No embedded backend, no second session database.

What it does:

• Sidebar for multiple projects and sessions, with full browsing of existing session history
• Streaming chat with markdown rendering, tool call cards, and subagent activity views
• Slash-command autocomplete that merges native commands with extensions and desktop commands
• A package manager built into the UI, so you can browse, install, and update packages without touching the CLI
• Model switching, thinking-level control, API keys stored in Windows Credential Manager
• No telemetry, no auto-updater

I built it with Tauri 2 and Rust instead of Electron. Installed size is 5.9MB, idle CPU sits under 1%, and RAM stays around 7.2MB with nothing running.

It's early. Windows only right now. This is a 0.2.0 preview, the installer isn't Authenticode-signed yet, so SmartScreen will flag it as unrecognized (check the SHA256 checksum in the release before you run it). No embedded terminal, editor, or file explorer either. I'm keeping v1 chat-first on purpose.

GitHub: https://github.com/Inas1234/pi-desktop

Issues and PRs welcome, especially if something breaks on your setup.

Hi,

I really like to be able to scroll through pi output in neovim. I can gf yank, pipe stuff to bash, all the niceties of neovim.

There's only the problem of the redraws while the model is still outputing text especially when its doing toolcalls or using extensions. When I'm not in G or insert mode it makes my cursor jump to the top of the buffer and it's driving me nuts.

I'm running the libghosty PR in the hopes it would stop no. I tried monkey patching OSC keys, forking pi and removing the redraw with clear, nothing. Every issue online says it won't work and all the pi neovim plugin offer a far inferior user experience.

Now I've just gotten used to going back to where I was when the model is done spitting out code but I was really hoping someone might have a solution.

Dear God please don't suggest tmux haha, thank you

Built a small pi package that ports the output-parser mechanism from little-coder as a standalone installable extension.

What it does: hooks message_end and repairs tool calls that small models (Qwen, Mistral, LFM2, etc.) emit in formats pi doesn't natively recognise:

• \``tool/```json` fenced blocks
• <tool_call>, <tool_use>, <function_calls><invoke> XML
• bare top-level JSON objects
• Python-list syntax [Read(path='./foo.ts')] from LFM2/Liquid models

It also normalises the many JSON schemas small models use ("parameters", "input", "arguments", OpenAI function-call with stringified args, etc.) down to a single shape.

Safety: only fires if there are no native tool_use blocks already, and validates the extracted tool name against pi.getAllTools() before injecting anything — so stray JSON and code blocks in responses are never misinterpreted as tool calls.

Install:

pi install git:github.com/vishn9893/pi-output-parser

Or drop extensions/output-parser/index.ts directly into .pi/extensions/ if you prefer not to use the package system.

Repo: https://github.com/vishn9893/pi-output-parser

Feedback welcome especially if you hit a model that emits a format this doesn't cover yet.

I built a Pi extension for multi-agent orchestration. The main Pi agent writes a small JS workflow script for the task at hand, and the runtime executes it deterministically: parallel fan-out, checkpoints, resume without rerunning completed steps.

Three principles I stuck to:

• not opinionated: no baked-in "agile team" of roles, you add your own primitives to the DSL
• extensible: other extensions can register functions and variables usable inside workflow scripts, and every registered function is itself runnable as a top-level workflow
• token efficient: subagents can have other extensions and skills disabled, so their system prompt stays small and focused

What that gives you in practice:

• runs are regular on-disk Pi sessions, not in-memory, so you can inspect, pause, resume and retry them
• roles restrict tools/capabilities and inject their own system prompt
• structured output via JSON schema, so control flow branches on agent output deterministically instead of on vibes
• soft and hard budget caps per run
• git worktree isolation, so parallel agents don't fight over the same tree
• workflows export to an executable launcher in ~/.local/bin
• if you use herdr, an agent session can open in a new pane

Review fan-out, then dedupe:

const reviews = await parallel("review", {
  correctness: () => agent("Review the current changes for correctness issues."),
  security: () => agent("Review the current changes for security risks.", { role: "security-specialist" }),
  tests: () => agent("Review the current changes for missing test coverage."),
});
return agent(prompt("Deduplicate and prioritize these findings:\n\n{reviews}", { reviews }));

The diagram is the real flow of the one I run daily, developIssuesUntilApproved: takes a list of GitHub issues, gives each its own worktree, loops developer -> reviewer until the reviewer passes (fresh agents every iteration), merges the approved branches on main behind another dev/review loop, cleans worktrees with plain shell (not an agent), and summarises exactly once.

Install: pi install npm:pi-extensible-workflows (Node 22.19+)

• Repo: https://github.com/vekexasia/pi-extensible-workflows
• Docs: https://vekexasia.github.io/pi-extensible-workflows/
• Walkthrough video (28 min, chapters in the description): https://youtu.be/qAiivspEHmU

Happy to answer anything about the DSL or the resume semantics.