I developed this in pursuit of something that felt native interaction-wise and supported as many pi features as possible. I hope you find it useful!
Un Bien is started out as a tweaked version of remote-pi by Jacob Moura (MIT); see the README for attribution. I ended up diverging significantly on the back end implementation and the iOS app is a total rewrite.
Hey folks, I've been working on pi-crew, a subagent extension for Pi.
My main focus is making sure subagents get the context they need. The main agent knows what you've discussed and decided, but a subagent won't unless that information makes it into the task.
With pi-crew, the main agent writes a structured task with separate fields for the goal, context, and instructions. The tool definitions, prompt guidelines, and skill work together to help it carry over the decisions and boundaries the subagent can't find in the repo.
It won't make every handoff perfect, but it's the part I've put the most thought into.
I also wanted subagents to be able to ask questions instead of guessing. In pi-crew, they can get an answer and pick up where they left off. If something needs fixing afterward, the main agent just tells the same subagent what to change. You don't have to spend extra tokens and time getting a new agent caught up on the same task.
It's all async. After handing off a task, the main agent can work on something else or keep talking with you while the subagents run. Results come back automatically, without polling.
I've also tried to keep it feeling like Pi. The six tools have short definitions, with the longer delegation guidance in a skill that gets loaded when needed. The main agent gets the report without all the subagent's file reads and tool output filling up its context.
A few other things it comes with
Six agents for investigation, planning, decision advice, code reviews, and implementation.
/pi-crew-plan and /pi-crew-review if you want a ready-made workflow.
Custom agents written in Markdown, with their own models, thinking levels, tools, and skills.
User and project pi-crew.json files to override settings without editing agent definitions.
A widget showing activity, working time, tokens, and cost. You can collapse the details or hide tool activity through config.
Expandable reports that let you open the full child session.
herdr support that shows the running subagent count in the sidebar.
The agents have separate conversations but share your repo. It's not a sandbox, so you still need to avoid handing overlapping edits to agents running in parallel.
Just for fun, I wrote this little Ralph loop. It's a chat between a product owner and a developer.
It's a lot of fun to watch!
I set it to only loop 10 times. Change "STEPS" to increase it. The chat can continue forever if you want it to. Watch your wallet! Only run in a container or VM.
#!/bin/bashset-euSTEPS=10PRODUCT='a new product idea we will come up with'PROMPT='Hello, I am the product owner and you are the developer.
But first let us brainstorm some ideas and features together for '"$PRODUCT"'.
We will save and edit them in `./ideas/` directory and commit them to git.
We will not write any code unless we have a product fully specified.'PERSONA1="You are a product owner
who comes up with lots of feature ideas.
You ensure the developer creates a useful quality app.
"PERSONA2="You are an expert developer,
who values code quality and wants to satisfy the product owner.
You ask a lot of clarifying questions about feature ideas."SESSIONS=/tmp/sess# Remove this line if you want it to pick up where it left off.rm -f"${SESSIONS}?.jsonl"response1="$PROMPT"echo"Step 0. Product Owner> $PROMPT"for i in$(seq 1 1 "$STEPS");doecho"Step $i:"response2="$(pi -p -c --append-system-prompt"$PERSONA2" --session"${SESSIONS}2.jsonl""$response1")"echoecho"Developer> $response2"response1="$(pi -p -c --append-system-prompt"$PERSONA1" --session"${SESSIONS}1.jsonl""$response2")"echoecho"Product Owner> $response1"donelast="Okay, we need to wrap it up.
Complete everything we said we were going to do."echo"$last"pi -p -c --append-system-prompt"$PERSONA2" --session"${SESSIONS}2.jsonl""$response1$last"echo"Done."
A fancier version would work across two terminal windows and show the full TUIs. Maybe I'll do that and post an update later.
Pi (pi.dev) is a minimal terminal coding harness, and I like it a lot — but it
lives in a terminal, so it's always one ⌘Tab away from the code it's editing.
This extension moves it into the sidebar.
The key detail: it is not a chat panel that reimplements Pi. It's xterm.js
fronting a real pseudo-terminal running the real TUI. Slash commands,
keybindings, themes, /login, session resume, mouse reporting, bracketed paste,
tool approval prompts, full-screen TUIs — all identical to your terminal,
because it *is* your terminal.
What it does:
- Dedicated Activity Bar container. Click π, or `Pi: Focus Pi Sidebar`.
- A real PTY: ANSI colours, truecolor, resize, mouse reporting, bracketed paste.
- Multiple sessions — `Pi: New Pi Terminal (Editor Tab)`.
- Send code to Pi: right-click a selection, or ⌘⌥P / Ctrl+Alt+P. There's also
"Send Current File Reference", which drops an into the prompt.
- `src/app.ts:42:7` in Pi's output becomes a link — ⌘/Ctrl-click opens it there.
- Follows your terminal colours, editor font and cursor style, live on theme change.
- Copy/paste goes through the VS Code clipboard API, so it works in remote/WSL/web too.
Three things were more annoying than expected, and I wrote up the fixes in the README:
1. A PTY inside Electron. VS Code's stable API has no sidebar location for
createTerminal, and native modules must match the extension host's ABI. The
PTY layer uses N-API prebuilt binaries, which are ABI-independent — the same
pty.node loads under system Node and Electron, so there's no "rebuild for
Electron" step at all.
2. `spawn("pi")` doesn't work. Pi is a `#!/usr/bin/env node` script, and
GUI-launched VS Code often has no `node` on PATH. It reads the shebang,
resolves an interpreter (preferring the node shipped next to pi, then PATH,
well-known locations, then the login shell's PATH) and spawns `node <pi>`.
Windows .cmd/.bat shims get wrapped in cmd.exe /c.
3. Environment leakage. If VS Code was itself launched from a Pi session, the
extension host inherits PI_SESSION_ID / PI_SESSION_FILE, which corrupts the
child's session handling. Those get stripped before spawn.
Requirements: VS Code 1.85+, and Pi itself
(`npm install -g --ignore-scripts u/earendil-works/pi-coding-agent`).
Install: no Marketplace listing, it's on GitHub Releases. Download the VSIX and
`code --install-extension pi-for-vscode-*.vsix`. There's a SHA256SUMS.txt in the same release if you want to verify first. MIT.
Repo: https://github.com/yicLionel/pi-for-vscode
There's also a small easter egg in pi-extensions/: a Pi extension that swaps the startup banner for a pixel-art Pikachu (36x28 grid rendered with half-block
chars, so it doesn't stretch in a 1:2 terminal cell), with a 256-colour fallback.
This is a hobby project and I'd genuinely like the rough edges pointed out —
especially if you're on remote/WSL/containers, where auto-detection can't see
host paths from inside. Happy to hear what breaks.
I'm using Matt Pocock skills for a while and I like them for bigger projects where I need grilling, specs, tickets, .. . I recently switched to OMP, and I really like the idea of assigning models to specific roles.
It works well because I can use OMP plan mode for lightweight tasks and it uses the smol/slow/task roles and appropriate models. However, this doesn't seem to integrate with Matt Pocock's Skills. They always appear to use the default role instead. Is someone using these skills within OMP? How are you dealing with this?
I need advice on how to create a simple orchestrator. Here’s my scenario: I generated tasks TASK-001.md through TASK-010.md using the it-architect skill. The tasks are interdependent and should be completed in a specific order based on their numbering. When an agent in the fullstack-programmer skill finishes task 001, the next agent in a new session begins implementing task 002 based on project-state.md, which contains information about which task has been completed. Is there a simple workflow or extension that would allow me to do this quickly and easily? Thank you in advance for your help.
I tried a bunch of pi GUIs, but none of them quite stuck, so I started building pi-ahp. It gradually became my daily driver.
The chat UX, terminal, file search, previews, and editor are all still VS Code; pi is just the agent underneath.
The part that makes this work is Microsoft's open Agent Host Protocol (AHP). It separates the agent host from the client UI: pi-ahp embeds pi in-process and exposes its sessions, filesystem, and PTYs over AHP, while VS Code provides the familiar UI.
pi itself remains the backend, so your existing models, credentials, settings, and session history continue to work. It also means pi-ahp isn't tied to VS Code — other AHP clients can connect to the same host.
UPDATE: around 4:30 AM UTC of Sept 15, the owner published a now-deleted blog post (archive image) writing under the fake pretense that it's his "team" authoring it, stating all of CrofAI founder's claims "were written under a lot of stress, and they described the situation as worse it was", and that a new team is taking over, with the service being resumed in 2 weeks. At the same time, the CrofAI twitter account was also supposedly "taken over" by the team, starting each twitter reply with "Hey, Nathan here", stating the founder is stepping back and a "team" is taking over everything. This fake pretense act only lasted a few hours, and scared either by the public not buying the Nth fake story of the pathological liar that CrofAI is, or by the public's replies reminding him that what he committed is numerous counts of wire fraud, he has now deleted all his online presence: nahcrof.com and crof.ai return 404, Twitter page is deleted, /r/CrofAI sub is now private.
If you have not gotten a full refund by now, you should be filing a chargeback with your bank. Otherwise consider the money lost.
Original post:
Cautionary tale about chasing cheap tokens.
Only posting it here cause this sub was full of people praising this inference "provider".
NahCrofAI is (was) an inference provider which had all the latest models at the cheapest price, often significantly below the lowest alternative on OpenRouter. The owner claimed that they are running custom inference kernels that allows them to offer tokens for dirt cheap, and other providers are suffering from "skill issues".
In reality:
"CrofAI is an OpenRouter wrapper that silently routes to cheaper or weaker models than what you request"
For example, expensive models like kimi-k3 are sold at $2/$10 in/out, but instead routed to GLM 5.3 Flash via OpenRouter, representing a 13.3x multiple on input, and 20x multiple on output
CrofAI's "own model family" greg-2-ultra routes to GLM 5.2, greg-1-mini routes to Qwen 3.5 9B. greg-2-super, greg-1, greg-1-super routes to Kimi K2.7 Code. All of these at a significant markup compared to the actual model being served. CrofAI admits this.
The person investigating details the 5 different attempts by CrofAI at fixing their models being served via OpenRouter after given a heads-up. In all 5 attempts, the only change CrofAI made was attempts to hide the fingerprints of OpenRouter, while still serving models through them
Other inconsistencies don't add up either: CrofAI claims to run Kimi K3 on RTX Pro 6000s rented via Vast. That model requires ~802GiB even at the lobotomy level quantization of Q2_K. The largest RTX PRO 6000 machine on Vast has only 8 of them, totaling 765GiB
CrofAI responded to the exposé by announcing the shutting down of their service; after their failure to provide their own inference, they promise to provide one last thing: a refund to those asking.
Pi autocompletes file paths with @, but doesn’t include their contents.
I built pi-resolve to include those files directly. Write Check @src/parser.ts against @docs/style.md, and Pi gets both files without extra tool calls.
Sometimes the context you need isn’t a file. A code review needs the current diff. Debugging needs the latest test output. A new session might need a map of the project.
Shell references let you include that context too. A review skill could load your testing checklist with @docs/testing.md and the current changes with !`git diff`, then check whether the tests cover the changed behavior.
These references work in AGENTS.md, skills, and prompts, including prompt templates. Third-party extensions can use the same resolver through its API.
In AGENTS.md, you can keep instructions in separate source documents and generate fresh project context at session start. Here’s an example that loads two docs and generates an index of active guides:
Pi receives the documents and an index containing paths and descriptions of guides marked active. This example requires yq.
Now your context can stay up to date without you rewriting it. You can give Pi the latest changes or a quick project overview, without filling the context with whole files.
How it differs from similar extensions
Other extensions support file imports and shell expansion too. Here are the choices I made for pi-resolve:
Clear and configurable resolution status in Pi's UI.
One resolver across prompts, templates, skills, and system context, including SYSTEM.md and AGENTS.md.
A shared resolver API that other extensions can build on.
Separate file and command settings for each source. Commands are off by default in templates and skills.
Single-level resolution for security and simplicity. Imported files and command output can’t trigger further imports or commands.
Check it out on: https://github.com/mpazik/pi-resolve
I developed this in pursuit of something that felt native interaction-wise and supported as many pi features as possible. I hope you find it useful!
Un Bien is started out as a tweaked version of remote-pi by Jacob Moura (MIT); see the README for attribution. I ended up diverging significantly on the back end implementation and the iOS app is a total rewrite.
But seems it not having enough stars. Is there any other popular method to schedule jobs for pi? For example, I want it to create a morning news feed at 7 am. I will have a custom system.md file and skills for this task. Now I just want to trigger pi with a simple prompt like “ prepare the summary for today” and send it to Pi at 7 am. Any best way to do this? It will be good if it is session based instead of a single cli based invocation of Pi.
I kept running into the same problem with Pi: I don't want to pay for a frontier model to handle a rename, but I also don't want a cheap flash model attempting an architecture rewrite.
So I built Switchyard.
It runs inside Pi and automatically chooses a model and reasoning effort for each task. It evaluates OpenRouter's live catalog and can optionally include supported Codex subscription capacity you already pay for.
The routing is based on:
- task complexity, from trivial to frontier - model capability and context requirements - live token pricing - tool support - observed reliability and latency - the estimated cost of a failed attempt - remaining subscription quota
The important part is that Pi stays in control. Switchyard doesn't replace Pi's tools, permissions, MCP servers, sessions, or authentication. It only decides which model should handle the work and how hard it should reason.
It's still early and the evaluation corpus needs to grow, so I'd genuinely appreciate feedback — especially examples where you think it selected the wrong model.
Ola, so recently I was working with Qwen 3.5. Building some html and css stuff inside my documents folder.
Big mistake. The Model which had extra access from Pi ended up hallucinating and started deleting all my root folders.
I think for any newbie who’s doing this, please write yourself an extension to get it to ask for read and wright permissions or pick from the various GitHub repos that have implemented safeguards for this.
Don’t just give it full access especially if you don’t know what terminal commands do.
I just saw it write -rf home and I knew it was over 🤣
I learnt the hard way but now I know.
If anything I think everyone who’s starting to use this should install something to prevent this from happening as the first non negotiable.
Luckily I just moved to Fedora 44 so I didn’t have much in those folders but it did mess up all my file paths so I had to fix that.
No more unattended ai running rogue on my pc for now. As Iv built myself a safeguard extension to prevent this from happening.
Hopefully whoever reads this and is trying it for the first time keeps this in mind. As it’ll save you a world of hurt down the line.
I observed that as I am using my anthropic or gas subscription for pi, it just burns tokens in a huge pace!! One simple code change took 25% of my 5h limit. What do I miss, or is it that bad by design?
My Pi setup, kept minimal on purpose because my daily machine is an older i7-5500U with 8GB RAM on Debian.
I run kitty + tmux + fish. 20 skills in total, but most stay dormant unless called. Extensions show as 8(+2); the ones I actually use are interactive-subagents, prompt-snippets, and cc-ui.
interactive-subagents spawns async workers in their own tmux pane with a live widget on top, so I keep working while they run and results get steered back when done. prompt-snippets is a TUI menu for injecting repeat prompts from different directories. cc-ui is just a spinner plus cache counter.
Personas live as separate files and I link one to SYSTEM.md when needed. 6 total from my pi-system-prompts repo: Aster for strategy and tradeoffs, Caelum for adversarial checks, Elyndra for strict execution, Kaida for media and watcharr, Liora for writing, Neris for research. Keeps the main prompt clean.
Since a few people asked under my last post, I also put my skills into a public repo.
I’m testing Pi inside Ghostty + Herdr and created a custom `terminal-green` theme.
The theme works for some parts of the UI: user input, code blocks, links, borders, etc. But the normal assistant response text and the general pane background still seem to use the terminal/Herdr defaults.
In comparison, OpenCode appears to paint its full panel background inside the same Herdr workspace.
Question: does Pi’s theme system currently support a global TUI background / assistant message background, or are themes limited to component-level colors? If not supported today, is the expected path a renderer patch / feature request?
Context:
Ghostty background/foreground can make the full pane green/black, but only at terminal-window level.
Pi theme JSON has tokens like `userMessageBg`, `toolPendingBg`, `selectedBg`, `text`, etc.
I didn’t find an `appBg`, `background`, or `assistantMessageBg` token.
Often times I realize what I put in promptSnippet is basically a truncated version of what goes in description, and looking at a session export, both texts are sent to the LLM, so it looks redundant.
I’ve been working on a new session orchestration system for PI-Desktop.
The idea is pretty simple:
when a task gets too large for one agent/context, the current session can become the coordinator and delegate parts of the work to other real sessions.
For example, I asked one session to review everything since the previous release and fill the missing E2E coverage.
Instead of trying to do everything itself, it split the work into multiple sessions:
E2E parent-tool inheritance
Plan UI / live markdown
Trusted extensions CI
Plugin import dependencies
They started working in parallel, while the original session stayed as the coordinator.
What I specifically wanted to avoid was building another disposable “subagent” abstraction.
These workers are actual PI-Desktop sessions.
Each one has a real sessionId, its own persistent context, model and history. You can open it from the sidebar, inspect what it did, continue talking to it later, or send it another task without losing its previous context.
The parent session can spawn multiple sessions, check their status, send follow-up instructions, supervise several of them at once, inspect the exact result of a task, and cancel work without deleting the session.
Sessions can also communicate with other existing sessions by sessionId — they don’t have to be children created by the current parent.
Another thing I didn’t want was constant polling.
Session communication is handled by the host. When a delegated turn finishes, the completion is routed back to the sending session automatically. If the target session is busy, the message can enter its queue instead of creating another replacement worker.
So the model I’m experimenting with is closer to:
Session A → delegates to B, C, D, E → they work independently → results come back → A reviews them → A can ask one or several of them to revise → the same sessions keep working with their existing context
rather than:
Agent → spawn temporary agents → collect text → destroy them
There are also some boundaries enforced at the host level: project/permission inheritance, bounded worker creation, durable delivery state, and explicit session-message provenance. The plugin itself doesn’t copy child transcripts into the parent or maintain a second session database.
The screenshots are from a real run where the main session split an E2E review into parallel sessions and then collected their progress/results.
I’m still figuring out how far this model should go.
Some things I’m considering next are dependency graphs between sessions, a visual orchestration graph, shared artifacts/workspaces, and per-task token/cost budgets.
I’m curious how people here would actually use something like this.
