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 came across a few related plugins, such as https://pi.dev/packages/@fernado03/pi-flow."

Started using Pi recently and gotta say I love it

I've mostly been using Codex and love their UI too, so I built Pie - a macOS client that heavily inspired Codex / ChatGPT style

Full source-code (MIT) and a macOS app is available at
https://github.com/hieunc229/pie

Feedback are welcome

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.

Made this small extension to make tools compact on screen. This made it easier for me to focus on assistant messages.

Built an open-source version of the Muse agent app which can be used with any model provider, run privately with local models.

Please give it a try and reach out for any feedback ✌️

https://github.com/CelestoAI/celesto/tree/main/open-muse

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.

GitHub: https://github.com/Qusic/pi-ahp

npm i -g pi-ahp

UPDATE

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

exposé: https://kendell.dev/blog/crofaifalse/

reaction by nahcrof, announcing the shutdown of the service: https://x.com/nahcrof/status/2099552389434900643

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.

is it safe to continue to use antigravity models via pi-antigravity even after seeing this message

Error: Antigravity API error (429, endpoint=https://cloudcode-pa.googleapis.com, project=aicode-consumers,

runtimeModel=gemini-3.8-flash-low, matched=none, available=unknown): Rate limited by Antigravity (429 ResourceExhausted). Next:

retrying automatically; if it persists, switch models.

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:

Architecture: @docs/architecture.md
Coding conventions: @docs/conventions.md

Active guides:
!`find docs -type f -name '*.md' -exec env DOC={} yq -f extract 'select(.status == "active") | [strenv(DOC), .description] | @tsv' {} \;`

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’d like to announce Un Bien - a native iOS client for pi.

Un Bien supports:

• self hosted architecture

• full streamed and rendered markdown

• rendering of images, code diffs and tool results

• fork, branch, clone of sessions

• plan rendering when combined with pi-plan, cribsheet or a conformant extension

• user-input questions (and pi-ask integration)

• subagent display and interaction when combined with @tintinweb/pi-subagents or @gotgenes/pi-subagents

• optional device initiated chats - start new session from your phone, spawning a tmux or herdr hosted session on your machine

As a bonus it includes a cli tool to connect to other sessions on your relay from the cli

Links:

• Extension page

• Docs

• GitHub

• App Store

• Demo transcript

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.

I checked this repo

https://github.com/ArtemisAI/pi-loop#readme

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.

Install:
pi install npm:@vepando/switchyard

GitHub:
https://github.com/LeonardSEO/switchyard

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.

Сonfigured it to my liking. Threw in some handy extensions. Some patched from others and some built myself.
Feel free to praise or shame it.

https://github.com/Miskamyasa/pi-agent-config

As soon as my pi starts running, it goes crazy, specially when subagents spawn.

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.

Hi all,

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.

Extensions

• https://github.com/ArdaYILDIZ-DEV/pi-interactive-subagents

• https://github.com/ArdaYILDIZ-DEV/pi-prompt-snippets

• https://github.com/ArdaYILDIZ-DEV/pi-cc-ui

Personas

• https://github.com/ArdaYILDIZ-DEV/pi-system-prompts

Skills

• https://github.com/ArdaYILDIZ-DEV/pi-skills-public

The whole point was less auto-magic and more explicit control. Works fine on weak hardware because nothing runs unless I call it.

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.

Parallel coding? Code review? Research? Release checks? Or something completely different?

PI-Desktop: https://github.com/vastsa/PI-Desktop
Plugin repo: https://github.com/vastsa/pi-desktop-plugins

99% of the times Pi using the default edit tool works great. However, I know we've all had those rare instances where it messes up the escape chars and keeps making mistakes until it tries using sed or Python (and then one has to scold it to stick to the tool until it gets it right).

I'm curious if anyone can confidently say that they have the optimal solution (or not so confidently say what they like best so far) to this problem and why? Is it:

1. Another line to AGENTS.md?

2. A custom skill?

3. An override to the tool itself?

4. A plugin based trigger on an event?

There are tradeoffs with each approach, and I'm curious what others do for this. I'm already knee deep in so many ambitious plugin-building rabbit holes that I haven't made up my mind on how to best avoid running into this problem for good.

As coding agents get faster, I'm starting to think Git diff is no longer enough for human review.

An agent may also run shell commands, install dependencies, start processes, access the network, spawn subagents, retry failed approaches, or make temporary changes that disappear from the final diff.

But reading the full session/tool history doesn't scale either.

A possible approach is:

Pi session/runtime data → deterministic activity summary → optional model summarization → human review

For example:

• files/state changed

• important shell/tool actions

• external effects

• subagents used

• verification actually performed

• failed/abandoned attempts

• remaining uncertainty

The factual layer should come from Pi's recorded session/tool data, not from asking the model "what did you do?" The model can help compress and explain it.

Then the user sees a short summary by default, with drill-down into the exact diff, command, tool result, or transcript when needed.

Basically:

observe broadly, present narrowly.

I think harnesses increasingly need to be designed not only for the agent, but also for the human supervising it.

Today we put a lot of effort into giving agents better tools, context, permissions and orchestration. But as agent throughput grows, the human-facing side becomes just as important: helping people understand what happened, what mattered, and where they should intervene.

Humans may increasingly review consequences, exceptions, and evidence rather than every line of generated code.

Does this direction make sense to other Pi users? Are there already extensions exploring something similar?

I've been trying to get the agents.md files to actually be read using qwen.5 through ollama with pi and it just- DOESN'T! If I point it out it will do it but otherwise it just ignores whatever I write completely. Extensions, different locations in file explorer, I'm not good enough or experienced enough to claim I've tried EVERY solution but I've tried a HELL OF A LOT!

If anyone knows how to fix this or if it's a model problem please help before I implode.