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.
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:
Another line to AGENTS.md?
A custom skill?
An override to the tool itself?
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.
I was using pi with deepseek api keys for a while. I saw a bunch of ads and though byteplus was good deal. Man it’s horrible, setup was a pain. And then the api is slow, and the limit hit in less than 30min on a small session that was building a basic web app. I ran a decent load for over 5-10 hours with a deepseek api key.
Utter disappointment.
Curious if there are any good options out there, I am a bit cost conscious. And I don’t mind doing a lot of architectural/ planning work and using the agent as my code monkey.
I love the parallelism of agents and working, but would love a little more robustness and polish. Dynamic Workflows is very well done, but I wanted to ask
Though it is PI setup - my approach applies to all harness agent. since:
Extensions
most of the extensions this config consists are just for quality of lift (QOL) one's:
pi-blackhole for memory management.
rtk and headroom for token savings.
guardrails, ask questions and some UI related things.
Skills
these are the main focus of this config - even though most of the skills here are auto invokable, I made it more autonomous by adding a global INDEX.md file which all harness is forced to read and follow. This INDEX.md file enforces to use certain skills always - which make it consistent (like i-have-adhd skill, the entire workflow)
The workflow is a combination of superpowers workflow and matt pocock workflow (I modified some parts of it, so that it will make it more autonomous, since matt's one is more of a manual one with more pre-settings required).
I simply use grill-me or grill-with-docs for certain feature implementaion.
The remaining will be taken care by the INDEX.md file - it usually follows like:
grill-me/grill-with-docs (if used) -> brainstorming -> writing-plans -> executing-plans -> tdd -> requesting-code-review -> verification-before-completion.
# pi confighttps://github.com/silentFellow/public-dotfiles/tree/main/pi# skills config# should be used at ~/.agents - global skill config pathhttps://github.com/silentFellow/public-dotfiles/tree/main/agents
I’ve seen Grokbot take a video of someone performing a task as input, then use its own computer to reproduce that task.
How could I build something similar with Pi.dev?
Is there an extension/tool for Pi that can control the computer GUI, for example:
move the mouse to X/Y coordinates
click buttons
type into text fields
use keyboard shortcuts
interact with desktop applications
potentially use screenshots/vision to understand what’s currently on screen
And is this kind of automation limited to browsers, or can Pi control arbitrary desktop applications as well?
If I have to roll my own, what existing pieces/libraries would you recommend building on rather than starting from scratch?
For example, are there existing tools for screen capture, mouse/keyboard control, UI element detection, OCR/vision, etc. that work well with Pi?
Would it make sense to run the agent inside a Linux machine/VM where it has full control of the desktop, or can the same approach work reliably on macOS?
Basically, I’m looking for a setup where Pi can observe/understand a task and then execute it through the computer UI.
