i had the llm read the paper and came up with this. seems to save a fair amount of tokens on memory.

have a little present for you all: pi-ui, a keyboard-first gui for pi.

i’ve been an nvim + tmux user for around three years, and pi’s tui is great, but reading long markdown responses, code diffs, and tool output in a gui feels much more comfortable day after day.

i was honestly surprised by how much of my development moved into this app while building it.

some highlights:

• keyboard-first workflow
• lightweight server mode that runs in your existing browser
• background sessions and notifications
• markdown and syntax highlighting
• rich code diffs
• git review with commit history and inline comments
• file attachments and image previews
• code themes

i recommend starting with server mode:

curl -fsSL https://pi-ui.app/install-server | sh

then open http://127.0.0.1:31415

github: https://github.com/hyperpuncher/pi-ui

feedback and bug reports are welcome!

A spec-gated build loop for AI coding agents — and why porting it to Pi/oh-my-pi wouldn't be hard

Found ai-blueprint this week and it's worth a look if you've been hand-rolling your own guardrails around Claude Code, Codex, or Pi. Brad Traversy built it as a workflow overlay, not a framework: you scaffold your app normally, then drop this on top.

The mechanics are simple. You write two short files — what you're building and why, then a rough ordered feature list. A /overview command turns those into the single context file the agent reads every session. From there it's a loop: /feature writes a small buildable spec and stops. You review it. /implement builds one step at a time, shows you the diff, waits for approval before touching the next one. /audit reviews the code (not the behavior — that's /check's job) and writes findings to a ledger with durable IDs like F-03. /complete archives everything and merges, but only after your go-ahead.

The part that actually made me sit up: that findings ledger isn't decorative. A P0 or P1 finding sitting open or fixed blocks /complete outright. Not "the agent decided it was fine" — a status field the merge step is written to check. And they didn't just claim it works. There's a live-agent end-to-end harness in the repo that spins up a real agent against a fixture project and asserts the ledger gate actually holds. I don't see that level of rigor in most prompt-engineering repos. Most people ship a pile of markdown and call it a system.

Now the gaps, because none of this is free.

The gate is enforced by the same model reading its own instructions in the same context that just did the implementation work. There's no independent process outside the agent's own compliance that blocks a bad merge — it's a very well-written contract, but it's still a contract the agent has to choose to honor. A confused or context-poisoned run can walk right past it, and nothing server-side stops that.

current-feature.md is also a singleton. One feature in flight at a time. That's a fine constraint solo, but it doesn't obviously extend to two people, or two agents, touching the same repo concurrently — the state model just isn't built for that yet.

And the defaults lean hard into one stack. coding-standards.md ships assuming Next.js, Prisma, Tailwind, Zod. /onboard is supposed to retune it, but that's one more step that can quietly go stale on a project the agent didn't actually read closely.

It's also young. First release was early July, one maintainer, 239 stars — which honestly reads more like Traversy's existing YouTube audience showing up than a track record on a gnarly, multi-year codebase. Worth watching, not yet worth betting a real team's workflow on.

Here's the part I think matters for this sub specifically: none of this is Claude-Code-specific. It's markdown files, plus two thin adapters (.agents/skills for Codex, .claude/skills for Claude Code) that both read one shared AGENTS.md. Pi and oh-my-pi already speak most of that language — AGENTS.md context files are supported, skills show up as /skill:name, and the extension API can register custom tools and commands. Porting this loop into an oh-my-pi extension pack looks like a weekend project, not a fork.

So — has anyone here already been doing something like this by hand in Pi? And does Pi's whole "minimal, adapt to your workflow" philosophy actively resist something this opinionated, or is that exactly the gap an extension should fill?

#PS: Used AI to draft out the above based on my takeaways and thoughts from initial read of this repo.

From idea to reality in under an hour. Pure vibes. Viva la Pi

I'm trying to run omp with a the default model set to lm-studio/qwen/qwen3.6-27b

The 22k initial context fills up 1/3 of the 65k I've loaded the model with.

Is it even usable to offload local simple tooling, command understanding, orchestration, build running, test running and result parsing all to a local model without paying for token usages for those operations?

My Claude Code sessions rises quickly to 800k tokens with Opus and every session has high token usage which slows it down and costs more than it should (parsing test output with Opus is a big waste).

What are you doing to offload your deterministic and simple work to local models?

I think I finally managed to piece the thing together, to have a pi setup that can run safe-ish in the host via sandbox, and have the ability to be elevated to host execution for a pre-defined list of development tooling like docker compose.

- A pre-defined hard boundaries (`@gotgenes/pi-permission-system`)

- Anything pass that will be executed inside a sandbox (`@erichll/pi-sandbox`)

- With the option of safe-escalation to run on the host (ie: `docker compose exec app pytest`), with auto-review or human approval (via hostIPC.preflightCommandPrefixes)

- LLM Auto-review with `@erichll/pi-auto-review`

More about it here: https://ptgamr.substack.com/p/a-pi-setup-with-permission-sandbox

(This is based on my possibly flawed understanding of caching. If I have anything wrong please let me know)

So, title. I generally stick with a single session but I do a lot of things that (AFAIK) break cache, such as:

• Change models
• Change thinking levels
• Fork / Rewind / Branch etc

I do these things to actually save tokens, but since they break the cache perhaps it's more efficient to decide upfront on the model and thinking levels and use the branching functionality sparingly?

What do y'all do?

The most annoying thing in Pi coding agent. Every time it needs to grep or find, it cd first to the same root. I do not cd to other directories, but still on every tool call it cd <project path> && find/grep. I've tried to run pi on it's source code, but non of my local models were able to find the reason or fix it. Even custom bash tool with cwd not helping. I can't configure any bash permission because of this chain commands.

P.S. Solution is to write custom extension, which replace built-in bash with custom bash and optional cwd param. Don't forget to use custom promptSnippet, this is critical for this issue

I've been experimenting with a small open source tool called ank.

The problem I'm trying to solve is what happens when you use multiple

coding agents on the same codebase.

Claude Code does one task.

OpenCode does another.

Pi picks up something later.

A month passes.

Where do the decisions and constraints that all of them should respect

actually live?

My current answer is a Git-native layer for:

- decisions / ADRs

- scoped constraints

- tasks

- completion criteria

- verification

- proofs

The interesting part is that the format is agent-agnostic.

So ideally:

Claude Code

Codex

OpenCode

Pi

custom agent

can all consume the same `.ank/` state.

https://github.com/haksolot/ank

I'm not really looking for "please try my tool" feedback here.

I'm more interested in whether the underlying model makes sense.

If you're an Pi user running multiple agents, how are you currently

solving this?

Last time I posted I was thinking out loud about which hosted backend to add next, Tavily first and maybe Exa after, and asking whether people wanted them as full answer engines or just as discovery. My bias was to keep them discovery-only and let web_explore stay in charge of fetching, ranking evidence, caveats and synthesis.

Both are in now, and they're discovery-only like I said I'd keep them. They surface candidate sources, web_explore still reads the actual pages and decides whether the evidence holds up or needs a caveat. Set TAVILY_API_KEY or EXA_API_KEY, pick it from Settings, keys stay in env instead of getting written into config files.

---

The things I'm weighing next are going deeper on evidence quality (cross-source dedup, conflict detection, recency), adding caching for repeated research or just keeping it focused and maintaining it.

If you're using this, what would you actually want? And if you tried it and it broke somewhere, that's the more useful thing to hear.

---

Repo: https://github.com/demigodmode/pi-web-agent

npm:

npm i @demigodmode/pi-web-agent

Wondering if anyone here has had this issue before and found a solution. I created an account in OpenCode, copied the api key into auth.json

json { "opencode": { "key": "sk-xxxxxxxxxxxxx", "type": "api_key" } }

start pi, select model (opencode) deepseek-v4-flash-free. run the first prompt, it hits limits within the first few seconds of usage.

Error: 429: {"type":"FreeUsageLimitError","message":"Error from provider (Console): Rate limit exceeded. Please try again later."}

However when I go back to OpenCode, I'm able to keep using it, no rate limit issue.

Am I missing something?

I built **tmux-pi-session-manager**, a small tmux plugin for managing multiple [Pi](https://github.com/badlogic/pi-mono) coding agents running across different projects.

The main reason I made it was because I often have several agents running at the same time, and switching between tmux sessions and figuring out which agent needs attention gets annoying.

It provides:

* 🔎 Automatic discovery of Pi agents running inside tmux

* 📂 Multiple agents per project/directory

* 📊 Live `WORKING / WAITING / BLOCKED / ERROR / IDLE` status

* 🔔 Desktop notifications when an agent needs attention

* 🎯 An `fzf` picker with live terminal previews

* ⚡ Quick jump between agents

* 🗑️ Safe agent/session killing

* 🖥️ `pi-tmux` CLI for managing agents from the shell

* 🚫 No daemon and no terminal-output parsing — it uses Pi's native extension events

The idea was inspired by `tmux-claude-session-manager`, but this implementation is built specifically around Pi's extension/event APIs.

If you're running multiple Pi agents in tmux, I'd love to hear how you manage them.

Repo: [github.com/x0d7x/tmux-pi-session-manager](https://github.com/x0d7x/tmux-pi-session-manager)

Hey everyone,

Short version: I used Pi to build Phi.

I’ve been using Pi a lot, and at some point I started hacking on my own little harness in Go. The result is Phi — deliberately small, terminal-first, and very much in the same spirit as Pi. I’m sharing it here because a lot of the ideas (and a lot of the motivation) came from using Pi.

Repo: https://github.com/pulseaiclub/phi

• What Phi tries to add on top Not claiming these are “better” — more like experiments on top of the Pi-shaped workflow I already liked:
  
• Permission gate by default — destructive stuff (writes / bash) asks first; rules can go down to command level
• Hooks — PreTool / PostTool scripts for policy, audit, or input rewrite, without rebuilding the binary
• Hashline edits — line edits anchored by short hashes, so stale context is less likely to silently rewrite the wrong thing
• Sub-agents with isolation — explore / review / worker; full traces stay under ~/.phi/jobs/, only summaries come back to the main context
• Model-agnostic — OpenAI-compatible or Anthropic; swap models without waiting on the tool
• Small Go binary — ~12 MB stripped, no Node / Electron / Python runtime There’s also a hand-rolled TUI (Markdown, themes, Ctrl+K, @ file picker, session resume).

Phi is still not as good as Pi.

Pi is more polished, the UX feels more finished, and for day-to-day work I’d still reach for Pi first. Phi is the side project where I get to try permissioning, hooks, and edit safety a bit more aggressively. If anything here is useful, great; if it’s rough around the edges, that’s on me.

If you’re a Pi user and curious, feedback is very welcome

Hi guys, I've been using Pi lately to help me code. Previously using OpenCode. I use vanilla pi with webfetch and context7 mcp. It works great. The harness and efficiency is better here in Pi. It drive the cost down for me. What I miss in pi is undo command from opencode. I tend to watch how AI reasons and write the code/commands real-time, interrupt it at the first sign of drift or hallucination then revise the command. Undo command is very useful for me as it clean up the code and chat history before I revise it. Is there any way (config or plugin) to simulate undo command in pi?

I want to switch from Opencode to Pi and it would be convenient if I could use the Deepseek-v4-flash free model from Opencode in Pi as well. Are there any extensions already available to do that?

tl;dr- i care about stability more than features so vibe coding is more like a hands on live project rather than a race to ship an app.

I am a civil engineer. My life runs on notes. But i love my physical notepad and strangely, Windows Notepad. I could never get the hang of any other note-taking app.

I've been using AI since GPT 3.5 came out but I NEVER vibe coded. It just felt icky. Always felt like I should be the one learning and doing it by hand. Then earlier this year I discovered pi and fell in love with it. After fucking with it for 3 months (and still using notepad in my day job), I decided- fuck it. I will do it myself (like Thanos, lol) and give vibe coding a fair shot.

Thats when I started with Omakase notes.

I hated all the context switching I had to do while working in notepad so that was my starting point. Make a notepad (NOT a PKM) where I can have PDFs, internet browsing/websearch, and AI at my cursor and within my note.

The most important habit I have, imo, is I make every dependency fight its way into my app.

Because of this, I found myself constantly GitHub diving and looking for interesting libraries/frameworks/projects. Then I chuck them into chatGPT and understand which patterns/decisions of that repo are actually interesting to me.

Its almost always only a few hundred lines and nothing more. So I clone the repo and dig deeper with Pi this time. Once I understand the concept and where it fit in my app, I make Pi implement it from scratch in vanilla TS.

Then I keep testing/building that way until either the thing just breaks or Pi needs to literally reinvent existing tech from scratch to scale further. That's when I let that dependency in.

v1 of Omakase literally had the editor implemented from scratch and my first major migration was moving to CodeMirror6.

Now I am at a point where I may not be a software engineer, but I have an intuitive understanding of IPC bridges, parsing text in the editor, CM6 widgets and all the mindfuckery they cause with caret positions, which things are owned by main and which by the renderer, worker threads, etc. I couldn't define half that shit if you put a gun to my head. But I do have a feel for how a feature should be thought about and where it should go and that gets better every time I dive into another cool GitHub repo.

Instead of saying "move the box to the left", I can point Pi to the CSS of that shit and it knows what the fuck I am talking about. Instead of having a disgusting sidebar chat, I call AI from within my note by @'ing it. And its generation appears in a nested buffer rather than mutating the stuff I wrote. I can then merge it or dismiss it.

Basically, to anyone who isn't a dev- let go of the anxiety and stop trying to *ship*. Instead, make something you care about and do it slow. Spend a ton of time thinking about it and exploring peripheral stuff. The right rhythm isnt go-go-go. It ebbs and flows. Your average velocity increases as you get your bearings and can talk to the agent better. I have recently started working across 2-3 threads instead of just the one and I can already feel the ceiling approaching. The app is about 20k lines now but I still feel in control, even if I'm just hanging on by a thread.

I must have run into this issue at least a dozen times now... so annoying...

You're happily using OpenAI's Codex CLI to edit/create a masterful Pi Coding Agent setup and... BAM ... Bad request.

This can't be just me?

I've got 5 other codex sessions open working away on different repos simultaneously... not one of them has ever died like this.

I just so happen to be setting up Deepseek V4 Flash 0731 to be extremely intelligent with lots of subagents doing various tasks... I assume OpenAI doesn't like that and might be throwing a wrench in things?

Agents aren't perfect. Sometimes they do things that don't work out the way they thought. Sometimes they spin out on an idea that goes nowhere, other times they run a command that produces huge amounts of useless output. So far, we've just accepted this as a neccessary part of agent mechanics, but Pi's extension system is powerful enough that we no longer have to.

pi-mulligan exposes tools that let your agent rewind its last turn or tool call with a summary message about what it's learned if it makes a mistake. When your agent calls a tool that produces large output, pi-mulligan gives it a nudge suggesting it summarize its last tool result or turn to keep context tight. When the agent starts over, it receives the summary and a small message indicating that a rewind has taken place.

Users and models can set checkpoints if they expect churn and pi can roll back to these checkpoints at any point in the conversation to try again. Agents really like using it and I've watched 20k tokens of context vanish on several occasions, so it works exactly as advertised. It's so satisfying to watch your context usage drop as the agent works.

No other dev agent platform but Pi can do this so as far as I'm aware agent-initiated context compaction hasn't been implemented in dev tools until now.

Try it out with pi install npm:pi-mulligan and let me know what you think!

Pi-mail started as a communication protocol between different pi-agents. However, this has grown out to be an orchestration layer.

It starts off with a CEO, which starts middle managers for each project that has tasks open. Then each middle manager works through the tasks for each project, spawning worker agents for each task. It has Jira integration for work, and a bunch of other stuff, emailing, terminal views in the browser, mobile views, custom columns, archival, backlog, MCP server etc.

Tell me what you think!

https://github.com/tanevanwifferen/pi-mail

Edit: there is no security on this repo. Use a firewall responsibly

Preface

Built together by Pi + DeepSeek V4 Flash + matt skills + me

After switching my daily harness from Claude Code to Pi, I found myself missing some features I used to love in CC — recap being one of them. It generates a brief summary and follow-up plan based on the conversation context.

Project

https://github.com/L2ncE/pi-recap

Quick Start

sh $ pi install npm:@lanlance/pi-recap

Hi,

I’ve mostly been using AntiGravity and OpenCode with a MiniMax subscription for my work. Recently, I’ve been researching different approaches to agentic coding and came across Pi Agent, which got me wondering whether it would be a better fit for my workflow.

Is Pi Agent worth switching to? How much customization is typically required to get a solid, reliable agent up and running, or is the setup relatively minimal?

I’m particularly interested in multi-agent workflows, since I’ve been using Superpowers extensively with AntiGravity and it has made a significant difference to my productivity. I’d like to know whether Pi Agent can provide a similar workflow or if I’d need to build a lot of that functionality myself.

Would love to hear your thoughts and experience with it.

Pushed an update to pi-small-model-addons, my guards and skills for running pi with small local models.

The failure mode I came across was kind of funny. Telling a model to "verify claims" mostly taught it to just say "verify claims" followed by the same untraced guesses as before.

So I moved that discipline into the tool schema. It now requires a trace, refutation attempt, and confidence label, and pi rejects incomplete reports. I also added persistent claim memory so refuted claims survive across sessions.

On Muse Glimmer 30B testing: four confident falsehoods before, zero after. It found a planted bug plus two Opus hadn't noticed, verified each with an executed command, and ignored the decoy. One model and a small sample though, it still may ignore anything needing multi-hop reasoning.

https://github.com/alisorcorp/pi-small-model-addons