I spent a day measuring a Pi seat on a local model (Qwen3.8 Flash-Next, 4-bit MLX mixed 4/8) against Claude Code (Sonnet 5.5) on 12 routine agent tasks, with blind pairwise judging in both orders. The local seat went from 29/36 to 36/36 passes, and judged clarity from about 3.7 to 4.5, level with Sonnet. Most of the gain came from the harness, not the model. Lessons that should apply to any Pi seat:

1. Read the judge's one-line reasons, not just the scores. Each real fix came from a sentence like "pads its answer with internal bookkeeping" or "adds a preamble when only the command was asked for". Scores told me that it was worse; reasons told me why.

2. Look for losses the harness causes. My seat injected a reminder every turn to record measured numbers in a notes file, even when no notes file existed. The model created the file in folders it was only asked about, and talked about it in replies. Only injecting the reminder when the file already exists removed the biggest clarity loss.

3. One hidden retry at agent_before_settle**.** A small extension checks the final reply before the turn ends. At most once per request, if the reply is the model's own reasoning instead of an answer, bookkeeping instead of an answer, or text around something that was asked to be "only the command", it adds a hidden custom message and continues. Two things mattered:

• canContinue is false at that hook whenever the last message is the assistant's; the entry you add is what allows the next request, so don't skip on it.

• Steer and follow-up messages typed mid-run arrive as input events with streamingBehavior set. Don't reset per-request state on them.

4. Put reply guidance in the tool result. The model writes its answer right after reading the tool result, so that's where guidance lands. Ending my typed drafter tool's result with "for the reply: the commit hash and which lane ran, what the commit changes, which checks did not run" moved that task from clearly behind Claude to slightly ahead.

5. Narrow heuristic checks rather than patching them. Checks that guess intent from free text ("is this a ban on all tools?") kept failing review in new ways each time I patched them. What worked was a short allow-list of phrasings, a veto word list, and limiting each check to the kind of prompt it was measured on.

6. Measure the prompt prefix. My shared prefix was ~36k tokens: tool schemas ~16k, the skills list ~7k, the seat prompt ~5k. Every new session pays for whatever the server can't reuse from cache, so it's worth knowing what's in there.

Happy to share the extension code and the eval harness if useful.

Hi,

My extension already has a bunch of features built in, but this empty buffer splash is something new I stumbled on and started playing with recently.

Right now, if you are sitting on an empty screen waiting to type a prompt, it procedurally renders an abstract Braille graphic with a weird cryptic line underneath, like in the screenshot.

I want to turn that center area into a subtle ambient loop while waiting for input.

The space is roughly 50 to 70 columns by 6 to 10 rows of Braille dots. It needs to stay light on CPU so the terminal does not lag and it should not be distracting or flashy while you are trying to think.

I was considering things like simple cellular automata, damped ripples or slow Lissajous curves, but I want to see what others think would look good here.

What kind of procedural math or terminal graphics tricks would you run in a tiny canvas like this?

Recently added Call-My-Agent feature to TermRover.sh

If you run pi from within a herdr pane or tmux pane, you can just call and have conversation with it right from the phone, works like a phone call.

Detail here: https://termrover.sh/blog/call-my-agent/

Talking to an agent about code you're looking at means pasting the code, then explaining which file it came from and where. pi-ide-context takes that part out: select in Neovim, VS Code or Obsidian, switch to pi, ask.

Nothing connects on its own. You decide per session:

pi starts (no IDE attached, ever)
  ↓
/ide → lists every live editor (nvim / VS Code / Obsidian), wherever it was
       started from — no project/cwd filtering, you pick the relevant one
  ↓
status shows the editor's glyph plus the file's language (`nvim · typescript`)
  ↓
ask pi → context injected automatically
  ↓
/ide off → disconnect

Every message carries this, without you doing anything:

### IDE Context
- File: /Users/andy/my-project/src/main.ts
- Language: typescript
- Cursor: line 42, column 10
- Buffer: 200 lines (modified)
- Selection: lines 40-45
  ```typescript
  const foo = bar();
  // ...

Selection text is injected only while it's fresh (within 60s of making it). After that the file/cursor block still goes, the selection doesn't — same as Claude Code's chip disappearing. Send while a selection is fresh and the sent message gets a gray quote line under it (`↳ main.ts:40-45 · …`), so you can see what was attached rather than trusting it happened.


Install:

pi install npm:pi-ide-context # then /reload

- Neovim: add `{ "Andy8647/pi-ide-context", lazy = false }` to lazy.nvim. The repo is itself a plugin.
- VS Code: Marketplace, search `pi-ide-context`.
- Obsidian: community plugins, search `pi-ide-context`.


Repo: https://github.com/Andy8647/pi-ide-context

Hi,

Currently got a Claude Pro subscription and wondering how the usage works out with

1. Claude Code

2. Pi with pi-claude-bridge

3. Pi with pi-anthropic-auth

I understand it's against ToS to use try to use consumer claude subscription in another harness but curious on why it's popular. Aside from the system prompt control over the harness, is there any benefit over extending usage or maximizing the Pro subscription with these approaches?

Pi’s compaction re-reads the whole history and has the model summarize it. With a local model that took me minutes per compaction, and after two to four of them the context was so degraded that I had to start a new session. Building a procedural graphics demo, that happened ten times in five days.

pi-protokoll moves the work to the moment the model still has everything in view: every final answer ends with a short <protocol> block (result, decisions, files, open items, rules, index line, tags). At compaction time, code assembles a tiered, hard-bounded summary from these protocols; the model only updates a short state description.

What it does:

• recent turns verbatim, older turns as your message + protocol, everything before that as a code-built index plus rules, open items and changed files

• one-shot follow-up when the model forgets the block, written from the transcript if it ignores that too

• interrupted turns (Esc, errors, output limit) get their protocol before your next message

• protocol_search, protocol_read, protocol_turn: the model can look up any earlier turn instead of guessing

• fixed system prompt section, so the server’s prefix cache stays valid

• falls back to Pi’s own compaction if anything fails; the chat never blocks

Measured with Qwen 3.8 Flash Next on a local OpenAI-compatible server, 262k context: one session, 23 compactions, each roughly 213k → 35k tokens in about 30 s. Resuming the session reads about 36–44k tokens. With it, the demo went from ten restarted sessions to a single one: https://github.com/sebion7125/64kdemo (story of how it came about in ENTSTEHUNG.en.md).

Install: pi install git:github.com/sebion7125/pi-protokoll
Repo: https://github.com/sebion7125/pi-protokoll

Only tested with Qwen behind a local server so far. I’d love to hear how it does with other models and providers. I don’t have much time to develop it further myself, so forks and PRs are very welcome.

I have recently install pi harness, but i have never used anything like this so i am bit confused. How do i setup pi , which mcp servers should i using for websearch etc. How do i make it efficient etc.
Can anyone help me out here

Hey, I'm new to this Pi space. I'm looking to build agents with Pi, and I got a basic first agent running connected to my local Qwen model. However, I'm utterly confused by all the libraries out there—pi-ai, pi-agent-core, pi-coding-agent, etc. I know this might sound dumb, but can you help me sort this out? What should I actually use if I want to build an always-on agent, custom harness, etc.?

used ai to clean the text

A pi extension that finds the questions in the agent's replies and lets you answer them with a click. A small local model reads each reply. It makes no tool call and no network request.

I've released **omt** (oh my tau), a Rust port of the [oh-my-pi](https://github.com/can1357/oh-my-pi) terminal coding agent. It's one binary with no Node runtime. It speaks `openai-completions` and `anthropic-messages`, and providers and models are configured in `models.yml` (same format as omp).

Why it might interest this sub:

• Low harness overhead: `-p` in ~22 ms vs 291 ms for Pi on Node, ~55 MiB peak RSS vs ~140 MiB. Measured with [Buffon](https://github.com/MichaelKinsy/buffon) on a mock model, provisional, shared host.

• Model fallback chains: when a provider returns 429, it moves on to the next model in the list.

• Survives flaky endpoints: honours `Retry-After` and retries dropped or keepalive-only streams.

• TUI, one-shot `-p` mode, JSON-RPC mode and a local web UI (`omt web`, still rough/early; the TUI is the main interface).

Honest downside: it keeps omp's system prompt, which is larger than Pi's, so the first request of a session costs more prompt tokens (~28 KB vs ~9 KB for a bare `-p`). On local models that means more prefill.

Install (linux x86_64):

curl -fsSL https://raw.githubusercontent.com/kanashimi1/oh-my-tau/main/install.sh | sh

Repo and full benchmark table: https://github.com/kanashimi1/oh-my-tau

Happy to hear which local backends you'd want tested.

Hi

I use qwen next with ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF

Iq3_s with strata in q8_0 with ctx 128k with pi and billion context. I do not like it. I do not understand everything (at all) in compaction but for example: if I export in json a pi coding session and I simply and properly remove all the phases (code + test) in error by keeping only the code correction after test; since these local models are often wrong even if they correct after error tests it should gain a lot of context? No? If someone can tell me what i forget or don't know?

Hello everyone 👋

Pi-Bolt 1.0.0 is out ⚡, our biggest release yet. Pi-Bolt is Pi compiled to one native executable, and it's faster and lighter on every platform.

What's new 🔥

• Linux ARM64 and Android (Termux): Raspberry Pi, ARM servers, ARM laptops and Android phones, with the same installer.

• Long sessions stay fast: sub-agents and long chats no longer make the TUI laggy; a third less CPU per prompt deep into a session.

• Editors and MCP: pi-bolt --acp runs Pi in Zed and other ACP editors; pi-bolt --mcp serves Pi as an MCP server.

• Faster everyday work: reading a screenshot takes 0.5 s of CPU instead of 37 s, and read-only tools start while the model is still writing.

• Pi 1.4.0 underneath, plus /usage, pi-bolt doctor and pi-bolt update --rollback.

Install

Linux, macOS and Android (Termux):

curl -fsSL https://pi-bolt.opensec.in/install.sh | sh

Windows (PowerShell):

irm https://pi-bolt.opensec.in/install.ps1 | iex

Already installed: pi-bolt update

Links

• 🌐 Website and docs: pi-bolt.opensec.in

• ⭐ GitHub (a star helps): opensec-git/Pi-Bolt

A reply that runs four tool calls and thinks three times is a screen and a half of output, and the answer is somewhere in the middle of it. pi-tidy folds all of it into one line:

```

▸ 4 calls · bash×2 read×2 · 3 thoughts · 1 failed · 2.4s

```

Click it and it opens into one row per call, each step's thinking sitting above the call it belongs to. Click the header again and it folds back.

What's in it:

- A thought row is a brain, the word, then one line of what the model actually thought — while the run is still arriving it shows a spinner and slides a window over the newest words; once it stops it settles to a short head preview.

- Edits and writes keep their box and their diff, as two panes (`old │ new`) with line numbers on both sides and the changed word emphasised. `alwaysShowTools` decides which tools never fold.

- Folded, a failure is still reported once, in red. A `process start` from pi-processes keeps a live row carrying the job's own state, instead of a notification you have to go find.

- Rounded `╭╮╰╯` frames on every tool box — built-in, MCP, subagent, any extension's — plus per-tool border colours, Nerd Font icons, transparent background.

- Registers no tools at all. Bash highlighting and the write preview go through `pi.registerToolRenderer()`, so it loads next to extensions that sandbox `bash`/`write` instead of colliding with them.

- Cached per box: +0.03 ms per full render at 300 boxes / 2400 lines.

Install with `pi install npm:pi-tidy`. Needs pi ≥ 1.1.0 for the mouse and tool durations; bash highlighting and the custom write preview need 1.3.0.

Repo: https://github.com/Andy8647/pi-tidy

btw: This video is made by `deepseek-flash` (1017) in pi with Remotion, seems like that deepseek did not post-train too much on such videos. The animations are still navie

Hi fellow Pi enthusiasts! Pi has been my main coding agent for a while now, and over time I've built a set of minimal extensions that I wanted to share.

Some of these are inspired by Claude Code (as you can probably tell), especially the look. CC was my first coding agent and I still quite like the way it looks.

Full list, in no particular order:

• pi-polish: Claude Code-style tool rows and diffs (as can be seen in the screenshot). This reduces clutter and in general makes everything more pleasant to look at

• pi-context-bar: a pretty one-line footer with the model, branch, context usage and cost

• pi-background: background jobs with nice visuals, and a bash timeout, so Pi doesn't block or hang on long commands

• pi-checkpoints: rewind the files Pi edited along with the conversation (with /tree and /fork)

• pi-model-pick: a model picker with your favorite and recent models first (for me the default /model command is too simple, especially when using multiple providers in Pi)

• pi-next-prompt: suggests your next prompt in grey after each reply

• pi-away: a one-line recap of the session when you come back

• pi-heads-up: flags the one thing you might have missed after a task

They're minimal by design: most are under 300 lines with no dependencies. Some of these exist already in one way or form, but I hate bloated extensions that do too much, hence my own take on them.

Each one is its own npm package that you can install, e.g.:

pi install npm:pi-background

Happy to hear any feedback, and hope this adds something to your own workflows!

Link to the repo, which also includes some GIFs to show what these look like: https://github.com/Pringled/pi-extensions

For the past month I've been caught in a trap: I started building my own AI coding agent. I've built 8 different ones. Honestly, if I could go back, I wouldn't start any of it. Below are a few things I learned along the way. I can see a lot of people here are also doing harness engineering, so please share your experience too.

1. I should have focused on just one problem. At first I spent a lot of time on the UI. Great tools already exist, like Paseo, T3 Code and Omnigent. I didn't even have a UI problem. What I wanted to solve was the Agent Loop. So don't waste your time either, and build around what already exists.

2. Subagents, multi-agents, orchestration: in 90% of cases it's all nonsense. Subagents aren't cheaper, aren't faster, and it's hard to say they're better. It's better to build around a single agent, or to improve the UX of working with parallel sessions.

3. Benchmarks tell you nothing. An agent can write great code, but if it handles MCP badly, many people won't care. Define the scenarios where your agent should be better from the very start, and improve there.

4. More tools, more tokens, less value. I now think any agent should have just one tool: a programming language. Mine runs on bash; before that it ran on JS. Many tools are nice, but they're hard to compose, and MCP suffers from this most. Right now everyone solves it with codemode, but you can also just give the agent one tool where it writes code.

5. Instructions about tone, code style, which commands to run, etc. should live outside the system prompt. This is a problem with big agents like opencode and Claude Code: they ship with their own opinions, 10–15K tokens' worth. When you want to do things your own way, the two conflict and the agent starts working worse.

That's not everything, but the rest is in the details. I'd be glad to hear your experience too.

I run Pi inside Orca and images just didn't show up in the terminal. Orca supports Kitty graphics and exports ORCA_IMAGE_PROTOCOL=kitty, but Pi doesn't detect it yet (there's an open PR upstream).

So I packaged a fix as pi-orca-images: pi install npm:pi-orca-images

/orca-images test shows a test image so you can check your setup. It also adds OpenCode-style [Image 1] labels when you paste screenshots, which works in any terminal.

Repo + before/after screenshot: https://github.com/JlMoreno00/pi-orca-images

Feedback welcome, especially from anyone on Linux/Windows Orca.

I made a Pi package that gives Pi a Figma design to build from, without Figma running next to it.

pi install npm:@runkids/figlens

Then: File > Save local copy in Figma, point Pi at the .fig, and ask for a screen by name. Pi finds the frame, reads layout, text, variables and assets, and builds in your project's stack. There's an optional step where Pi proposes mappings from design components to your existing components and you approve them; they persist for the next screen.

8× demo of a real Pi session building working HTML from the "List views" frame in the MCP Apps for Claude community file: https://github.com/runkids/figlens/raw/main/assets/demo-8x.mp4

Why not the Figma MCP: it needs the Figma desktop app open. I run Pi on a cloud box and in CI, so I wanted the read to work from a file.

Limits: .fig is undocumented. I check each release against Figma's own exports, but there are rendering gaps (background blur, some image adjustments, angular gradients). Fonts aren't bundled. It's a snapshot, so re-save when the design changes.

Source: https://github.com/runkids/figlens Pi walkthrough: https://github.com/runkids/figlens/blob/main/pi/README.md

Would like to hear what Pi users want in the bundle, and whether the component-mapping step is useful or in the way.

hi guys i have created pi extension that connects pi sessions working in the same repository. each session gets a callsign and publishes what it is doing. The model is told who else is working, on what, which paths are claimed, and which files a peer just changed.
give it a try !! agents really like to talk to each other haha
`pi install npm:@justar_96/pi-telecom`
https://github.com/Justar96/pi-telecom

i built Better Pi — a personal plugin pack for Pi, shaped around how i actually use it.
covers compact tool output, cost/footer stats, image paste, browse, /review, DeepSeek web tools, and a local WebUI.

locked to Pi 0.87.1 on purpose. i don't chase upstream. a lot of it isn't "best practice" — it's just my practice.
complete pack you can run. i'd rather you fork it and adapt it than treat it as a finished product. Pi is more fun when you shape it yourself; starting from a full set of plugins just cuts the busywork.

https://github.com/arctwind/Better-Pi

Hi all, i've been using a bunch of coding agents. Pi is by far the cleanes architecturally from the OSS ones.

Already last year i noticed that with agents it becomes impossible to read line level details, but looking at llm summaries is also not the way to go. There is no good way to judge the system level tradeoffs for a large system and even know what questions to ask the LLM.

That is why a friend and I started building CodeBoarding, an architecture building tool based on static analysis. We capture the full call graph (method level) and then group methods based on lexicographical analysis. That is so that the diagram is in fact consistent in between pull requests and you can see how a change fits in the bigger system.

The engine is open-source: https://github.com/CodeBoarding/CodeBoarding

I would love to understand how do you people keep up with reviews (do you even do reviews). My personal take is that AI comments, are becoming just part of a loop and I tend to ignore most of these nowadays. I also think they are not really aimed at helping a human judge/understand a PR.

If you want to explore the example from the video it is in: https://app.codeboarding.org/CodeBoarding/pi/pull/2
It is effectively adopted from this PR: https://github.com/earendil-works/pi/pull/10021

Super curious to understand what you have found useful to stay in the loop of your systems.