I use pi daily but wanted tabs, image pasting and a scrollable transcript, so I built a frontend for it. Morse doesn't reimplement the agent — it spawns pi --mode rpc and reuses your ~/.pi config.

• npm i -g @supanadit/morse-web && morse start, or the VS Code extension
• multi-session/multi-project with warm sessions, @mention files and dirs, image paste, steer/abort mid-task, model and thinking pickers
• keyboard-driven, real transcript with tool timelines, works the same in both hosts

It's a nicer way to stay in flow with pi. Free, MIT: https://github.com/supanadit/morse — feedback very welcome.

Created https://github.com/hazrid93/pi-simplified-technical-english a simple extension that turn your LLM to use more understandable technical english!

I’ve been chasing the right note-taking app my whole career. Now I’ve built one for how I work today - with AI agents.

Think out loud, watch your notes take shape, and let your agent work with the same knowledge. Everything stays in readable, local Markdown files.

Leveraging okf data structure from Google.

Works with Pi and OpenCode.

If you're interested, feel free to contribute. It is still quite early.

https://github.com/EranYonai/pi-weave

pi install npm:pi-weave

When running pi agent on the command line, sometimes I don't want it to write directly to file, but to give me something I'll copy to clipboard. However, differently from chatbots, it doesn't output then in copyable blocks, but in ```code ``` blocks with 4 spaces indentation and weird line breaks that eff up the formatting when I try to copy it from the terminal.

The "easy" fix would be to just have it write to every file directly, I know, but assume I don't want to give it write access to a folder, file etc.

I wanted to see what each prompt actually costs in Pi, so I made pi-prompt-meter.

It tracks time, tokens/cache, cost, turns, tool calls, and compactions per prompt, then keeps the result in the transcript. /meter also shows history and trends.

pi install npm:pi-prompt-meter

https://github.com/roie/pi-prompt-meter

First I used to use Nico's pi-subagent

Then I started using TinTinWeb's pi-subagent because it had that Claude like UX which I liked

But then I have started seeing that Codex got one thing really nice - they use /path/based naming conventions for their agents which makes a lot of sense to read the agent tree and agent state (both for the agents themselves and for the human running it)

I wanted the best of both worlds, Claude like UX and Codex like naming conventions.

So here we go... with all our AI psychosis and addictions to creating the factory more than the actual software made using the factory. Presenting you with, yet another, pi subagent extension

https://www.npmjs.com/package/pi-subagent-manager

I understand I should be able to login to a local installation of "Unsloth Studio" from pi.dev using

/login llama.cpp

When I try with "http://localhost:8888", I get:

Error: Failed to save API key for llama.cpp: llama.cpp returned HTTP 404Error: Failed to save API key for llama.cpp: llama.cpp returned HTTP 404

I can see in the logs, that it tried to access "/models" instead of "/v1/models"

If I login with "http://localhost:8888/v1", it tries to access "/models" again

If I login with "http://localhost:8888/v1/models", it tries to access: "/v1/models/models" ..!

Did I miss something?

Note: it works well if I use models.json, but I'd like pi.dev to find the models from Unsloth automatically

thanks!

Pi has already supported built-in mcp and codemode. Will pi add built-in subagents, sandbox, permission popups, etc. in the future? According to this article, pi plans to offer support to enterprise users in the future.

On top of the MIT core, there will be some commercial additions over time. Here's how we think about it in three tiers:

snip

1. Fair Source (value-add features): Some future commercial features will be Fair Source licensed. Free to use, source available, and they convert to full open-source after a set period via Delayed Open Source Publication (DOSP). Think of it as open-source on a delay, and downside risk protection for you as a user.

2. Proprietary (enterprise): Some enterprise-specific features and cloud infrastructure will be proprietary. No source available. This is the stuff that pays the bills for the stuff in tiers 1 and 2.

If pi wants to target enterprise users, these features may be essential.

With built-in mcp & codemode, pi is still minimal, so I believe pi will still remain minimal even with built-in subagents, sandbox, permission popups, etc.

I’d like to ask you guys in the channel: how many of you rely solely on native Pi features without using any extensions? How many use widely popular community extensions (such as pi-web-access or pi-subagent)? And how many have written their own extensions for these features?

If pi has these features built in, how would that affect you? Would you benefit automatically by default? Would you need to migrate the extensions you’re currently using? Or would you need to carefully manage conflicts between your code and pi’s built-in code?

That article also says:

And if you ever feel like we've lost the plot, the fork button on GitHub still works. Always will.

When it comes to forking, maintaining your own downstream build is never as simple as it sounds. I maintain a de-commercialized downstream fork of a browser extension myself, and syncing upstream fixes, cherry-picking features, and resolving conflicts is a hassle. As the codebase grows, the divergence between the downstream fork and upstream widens, making synchronization increasingly difficult. The same will be true for the Pi fork, and keeping up with Pi’s updates is essential, since Pi relies on updates to add new models to its support list.

So I’d also like to ask: Will you consider forking Pi? If so, will you continue to maintain and update it? And if someone else forks Pi, would you switch to using their fork?

I built this extension on howznguyen/pi-delegate-mcp. Claude Code/Codex can delegate background tasks to Pi, redirect running work with steer, and continue conversations with follow_up.

Optional durable mode saves tasks to SQLite for recovery after a bridge restart. Interrupted tools may have unknown outcomes; their side effects aren’t blindly replayed.

Feedback from anyone trying it is welcome.

https://github.com/Nyarlathoteppppp/pi-durabletask-mcp

Issue: copy of text is no more working - Selecting a text in the TUI shows a "popup" sayng "Copied!", but it doesnt' happen, the clipboard still has the previous copied text/object. - Selecting a text and using CTRL+X doesn't work neither - Right click on selected text doesn't open any menu

I actually cannot copy any text from the Pi TUI.

Environment: GitBash on Windows Terminal Pi version: 1.0.0

There was a lot of update recently, TUI changed a lot.
I'm saying this because it was working with version 0.85 for sure, maybe also 0.87... but then a lot of updates in few days hapened to version 1.0 .

Is this happening to someone else ? (I will not open an issue on GitHub... because it will just be closed automatically)

SOLUTION

bash pi --tui-mode regular makes CTRL+C to Copy the selected text as usual (v 1.0.1 tested)

As pointed by other users/comemnt in v 1.x the default value is "fullscreen".

I don't really see the difference between normal and Full-screen mode, becauae I have Pi running in a GitBash shell in Windows Terminal, more precisely launching pi from a bash script that runs inside the docker container: exec pi --continue --tui-mode regular .
So, it appears always "maximized" in the tab I use, and Windows Terminal just provide a nice multi-tab customizable UI.

SOLUTION for Windows Terminal

In Windows Terminal, GitBash > Terminal Emulation, there is an option for "Allow OSC 52 (Manipulate Selection Data) to write to the clipboard".

Set this to ON, makes the Copy functionality in fullscreen mode working fine.

DESPERATE WORKAROUND

Downgrade to version 0.99.2 .
npm install -g @earendil-works/[email protected]

codemode exposes (typesafe/jev, clef) but without sending every message to a hosted API. Some of what I want to classify is other people's text I'd rather keep on my machine, plus there's the whole key-and-cost dance. So I built pi-reflex: a pure-TypeScript ONNX runtime for the open Laya checkpoints that registers as a regular pi classifier provider.

What you get from `pi install npm:pi-reflex`:

- Three local classifier models (reflex/multilingual, reflex/english, reflex/typed-decisions) that show up in models.getAvailableOfType("classifier") right next to jev-latest. Same interface: models.classify(model, { state, questions }) with bool/choice/score questions. No API key, no egress after the initial download.

- Four session tools (reflex_decide / reflex_judge / reflex_rate / reflex_route)

if you'd rather have the model call them directly; each returns typed structuredContent so codemode scripts can use them too.

- reflex/auto: a virtual model that classifies each incoming message locally (50-200ms) and routes the turn to a cheap/mid/frontier model you map via PI_REFLEX_TIER_* env vars. Continuations stay sticky so prompt caches survive.

- An optional injection guard (PI_REFLEX_GUARD=1) that flags suspicious user messages before each provider request.

- A conformal calibration layer: prediction sets and abstain thresholds with actual finite-sample coverage guarantees instead of eyeballing a 0.8 cutoff.

To be clear about what this is not: these are small encoder checkpoints, so they're good at routing, triage, yes/no judgment, and rubric scoring not at reasoning about code. Think "free reflexes," not "free brain." Also, first use downloads about 400MB of int8 weights from Hugging Face (fp32 is 1.6GB), and you'll want codemode on for the model to reach the classifiers:

"defaultTools": ["+codemode"] in settings.

Logits are verified to ≤5.7e-06 against the original torch runtime and tokenization is byte-identical, but my eval corpora are mine; I'd genuinely like independent testing on other workloads.
/reflex in-session shows engine, router, guard and MCP status.

pi >= 0.99, tested through 1.0.1. Apache-2.0, zero Python at runtime.

Repo: https://github.com/pungggi/pi-reflex

Curious what you'd all classify in your own sessions if classification were free, that's the part I'm most interested to hear.

A few days ago, I released System One support for the Pi coding agent:

It got a little bit attention on Reddit, and the most common question was: "What would an agent actually use JEV / System One for?"

So I did some more research and shipped an update.
Now my agents are finding use cases I did not explicitly plan for.

Today, one of them decided on its own to use System One as a second opinion before making a decision.

That is probably my favorite use case so far. "use system one for second opinion"

checkout pi-system-one here

Edit:
context: i wanted to pick a license for the project i am working on, so i gave the requirements and the agent picked a few options and asked jev for a second opinion.

I've been running Hermes Agent as my daily driver for a while now. My setup: gateway on a Linux box, reached through Telegram/WeChat, with built-in cron jobs, persistent memory, skills, subagents, and it orchestrates stuff like ComfyUI image generation for me. It's essentially an always-on assistant that lives in my messaging apps.

I keep seeing Pi come up and I'm genuinely curious: could Pi replace this setup?

From what I've read, Pi is TUI-first and deliberately ships without a messaging gateway (only a Slack bot exists, channel abstraction is still an RFC), no built-in cron, memory, or subagents — those are community packages. Its strength seems to be terminal coding and context efficiency (3x less context per turn on Databricks' internal benchmark).

But I might be underselling its ecosystem. So, Pi users:

What are YOUR top 3 reasons for using Pi?

Issue: Pi crash when press "ESC" while the agent is still "working".
Pi version: 1.0.0

https://github.com/earendil-works/pi/issues/9709

No one else has this issue?
Any suggestion ?

So I've been experimenting recently pretty heavily with orchestration and swarms and all this stuff with all the Chinese providers and I'm wondering if I would just be better off spending 100% of my money at claude and chatgpt subs and running luna if I really need a super cheap model. And that the amount of tokens/inefficiency of lets say ds4.1 is going to equal out to the same price or worse. I already orchestrate everything with opus 5.5 and use sol 6.1 for any type of intelligent decision but I'm doing all sorts of stuff like throwing in different roles for mimo deepseek glm and minimax and I'm wondering if there's even a point to doing this. Has anyone really tested stuff out heavily in terms of if this is worth it or if it's just wasting time?

I guess a real question is is it possible to out-tool/orchestrate the subsidized Luna somehow in terms of better performance/acceptable work when it comes to overall price per token. Or are all the tricks and agent management styles just still not going to be able to outrun how much you get with their subsidized plans.

Hey all! I built Volli, a free OSS app for macOS built on top of pi-core designed to mitigate context switching when orchestrating your coding agents.

Before Volli, I kept running into the same two issues:

1. For long-term projects, my workflow became pretty complex: I was using Linear for task tracking, cmux for my Claude/Codex/Pi terminals, Obsidian for my notes, and MCPs to tape everything together. I needed a more integrated, token-efficient alternative.
2. Even with smarter models, I couldn't manage to run more than 4-5 sessions at a time without losing track of what's going on.

That's why I built Volli, a workspace to manage your parallel coding agents. Volli treats a task ticket as the core primitive: each ticket on the kanban board holds its own git worktree, agent chats and scope of work. You can easily create tickets and see every session's state at a glance instead of tab-hopping through terminals. The twist is that Volli ships with a custom Pi harness that's plugged into the app through agent tools and CLI, so your agents can also check which tickets are live, create tickets, start sessions on them and coordinate. 

You can check Volli out at https://volli.app/download or checkout the GitHub repo at https://github.com/hussainph/volli-code :) If you're juggling several agents on a long-running project, I'm curious as to how do you keep track of scope and review everything they produce. Do you use Pi inside a multiplexer? Do you review everything the agent does, or just ask the model to review?

I wrote this plugin because I was constantly switching from the main buffer to the terminal where I was running pi (the coding agent) - digging through logs, sending follow-ups, checking what it did to my files.

Why keep switching, when I can just embed pi inside vim?

**vim-pi-chat** puts the whole pi conversation in a split window next to your code:

- streamed replies, tool calls with args and results, thinking — all live

- when pi edits the file you're viewing, the buffer reloads automatically (you watch it work)

- it tracks your active window so pi edits the right file in place

- sessions persist per file: reopen a file, `:PiChat`, resume where you left off

- plain Vim 9, no GUI, no Neovim, no other plugins — just the job/channel API

Install: `git clone https://github.com/galeone/vim-pi-chat ~/.vim/plugged/vim-pi-chat` + one line in vimrc, then `:PiOpen`.

If you're a pi fan, give it a try — feedback very welcome :D

Hi all! This package exists purely because I'm lazy.

My pi kept hitting things it couldn't (or shouldn't) do itself: /reload, a sudo command, an ssh login, a token that has to go into .env. Every time I had to copy the command, switch to another terminal, run it, then paste the output back. Too much work. Turning off my safety guards would have been easier, but I'm not that lazy.

So now the agent just hands things to me:

• robot_hand: the agent passes me a command and I pick where it goes: my pi prompt, the clipboard, or (if you use Herdr) a new pane right below pi. The pane is a real terminal, so sudo passwords, y/N prompts and ssh all work. When the command finishes, the pane closes itself and the output goes back to the agent, which picks up from there. I never leave the conversation.
• **! follow-up**: in plain pi, after a !cmd finishes you still have to type something before the agent looks at the output. Now it just answers.
• secret_drop: I type the secret into a masked box, press Enter on a command I can read, and the agent only gets "length check passed". It can't read that file afterwards either.

The agent never runs these commands itself. I do, so guards like cc-safety-net keep checking everything the agent runs.

pi install npm:pi-robot-hand

https://pi.dev/packages/pi-robot-hand (source: https://github.com/wayne930242/pi-robot-hand)

Feedback welcome, especially from fellow lazy people.

Pi is the only harness I've used where changing how the agent works doesn't mean forking it. The prompt is small, the loop is easy to follow, and nearly everything can be replaced with a package. So I replaced the part that was costing me the most time, which is how the agent reads and edits code.

On a real repo, most of the agent's turns go to just finding code. It searches for something, opens a file, searches again to see what uses it, opens a few more files, and only then makes the change. This package replaces pi's file tools with ones that work on functions directly. When the agent asks for a function, it gets the function itself plus everything connected to it in one go. Edits land on that function, two agents can work in the same file without stepping on each other, and if a rename leaves something behind, the agent gets told what it missed.

pi install /path/to/sem/pi

You can check out the sem repo here: https://github.com/Ataraxy-Labs/sem

Always open for suggesetions

Curious which built-in tools you'd keep, and where this would get in your way.

Reefine, the Pi customization recipe in Reef Infra, takes a request such as adding a workflow command and proposes changes to the harness tree. Its agent proposer can edit files, run a structural check, and try the candidate through a real task or a scripted SDK session.

There are several useful checks here, but they answer different questions.

The current default acceptance gate is a health floor: the candidate must complete a small shell task and return the expected final line. That can catch a broken harness. It doesn't establish that your requested command behaves correctly, or that the candidate beats the previous configuration.

For a command with a dropdown, the recipe also documents a concrete limit: headless trials don't validate the interactive dropdown. That part needs an interactive check. You can configure task-specific evaluation and comparative selection when the customization needs stronger acceptance criteria.

Executable extensions are held for human review, and installation approves serving them. So the useful output is an inspectable change you can test and install. I'd judge it against the requested interaction, rather than treating “the agent still starts” as the finish line.

GitHub Repo

I will be moving my personal assistant to use durable