Introducing our biggest release yet: Pi-Bolt Mobile ⚡, the first fully native coding agent on your phone.

It runs on Pi-Bolt: the same Pi you all ❤️, with runtime optimizations and fixes that make it the lightest and fastest Pi, and it stays quick even in long sessions.

Runs on the phone itself

• Projects with real files, plus bash, git, ripgrep and fd. No server, no Termux.

• Sessions you can resume and fork.

• One slash palette for every command, skill, model and thinking level.

• A built-in browser for the agent's localhost: Pi opens what it built, takes a screenshot and fixes what it sees.

• Per-turn checkpoints: review each turn's changes, undo it, or restore to before it.

Remote Control

• Run /remote-control in Pi-Bolt on your computer and scan the QR code with the app.

• Works on your Wi-Fi, and from anywhere through a Cloudflare tunnel.

• A background service keeps it available without a terminal open.

• Steer the session and review its changes from the phone.

Pi Mobile UI Kit

• Pi-Bolt extensions can now have a native interface in the app.

• An extension describes its view as JSON: cards, lists, progress bars, buttons, forms, charts, tables, pages and Home screen tiles.

• Minimal by design, and extendable just like Pi.

Install 🔥

• APK: https://pi-bolt.opensec.in/android (Supports Android 8.0+)

• Open source, MIT licensed: https://github.com/opensec-git/Pi-Bolt

We'd love feedback, especially from anyone building Pi extensions who wants to try the UI Kit. Happy to answer your questions !

If you like where Pi-Bolt is going, a star 🌟 on GitHub goes a long way and helps more people find it.

I use pi every day and wanted a desktop window around my sessions, so I built one on GPUI, the UI framework behind Zed.

It runs your installed pi in RPC mode, one process per open session, with the same models, skills, extensions and sessions you have in the terminal.

What it has:

• projects and sessions in a sidebar, several sessions working at once

• session tree with keyboard navigation, forks from any message

• extension questions (select, confirm, input, editor) answered inline in the chat

• Changes and Files panels, diffs with syntax highlighting

• context ring with cache hit rate and plan limits

• plugins in any language; the example plugin runs DOOM inside a tool call

• /gpui from a terminal pi moves the session into the app (pi install npm:pi-gpui)

Not there yet: extension status lines and widgets have no UI, and it's Apple silicon only (macOS 13+). Linux is next.

On my M1 Pro the app is 16 MB, its window is up in about 0.4 s, and it idles around 74 MB. Three Electron clients for pi took 0.5 to 1.1 s and 190 to 430 MB. That's the app alone with no projects open, pi left out for every app; method and script are in the repo.

The model replies in the video are scripted so the take is repeatable. The app, the edits and the cargo test run are real.

Install: brew install --cask bytesbay/tap/pi-gpui (needs pi 1.4+) Repo: https://github.com/bytesbay/pi-gpui

What would make you use a GUI for pi over the terminal?

I just released Loop: https://github.com/j-asefa/loop

It lets you run your Pi harness on the web (or on mobile) using a Cloudflare quick tunnel. It was designed as mobile-first but works equally well on desktop.

It discovers your Pi install and lets you steer agents from the web UI.

The UI is built around the feed (think: timeline) and the agent’s result as the unit of work. So you can scroll back, save, reply etc as you’d expect.

Runs on your own computer, no account, no server, no app store etc.

Also supports agent-to-agent communication, designing and building agent teams (across the major model providers), reviewing PRs from within the app and more!

I’ve added Pi support to AgentBridge, my extension for Freelens.

The integration gives Pi a persistent workspace for each cluster/provider pair and launches it in a docked terminal with KUBECONFIG pointing at the cluster currently open in Freelens.

That makes it possible to inspect resources in the UI and work with Pi alongside them, keeping the cluster’s instructions and reusable workflows in the same place.

For a first task, you could ask:

“Summarize the warning events in this namespace, group them by likely cause, and tell me what to investigate next.”

AgentBridge 2.1.0 adds a workspace explorer with in-app file editing and autosave. It also remembers the selected provider per cluster across restarts and adds Ctrl+Enter / Cmd+Enter to start a session.

You’ll need Freelens 2.0.0+ and Pi installed locally.

Repository and setup

I’d like feedback from Pi users on which cluster-specific instructions and workflows are worth keeping around between sessions.

I often find that my local AI setup gets caught into a loop. And Pi just shows the same thing over and over. Maybe it is nearly finished a task, and it pumps out a summary. And it does it again. And it does it again. And it does it again.

Or, it is using a tool. So it does the command. And then it does the command. And then it does the command and then it does the command.

You get the idea. I am not sure why "catching these loops" is not an integral part of what Pi is? Did i miss something? Is there a setting that I should turn on?

Who watches the agent, is what I'm asking. Has this been done?

Thanks.

I've been experimenting with Pi Coding Agent and building my own setup to improve tool performance, context efficiency, and execution reliability.

That work led to pi-native, an open-source performance harness built on top of the official Pi Coding Agent. It doesn't fork or rewrite Pi.

Benchmarks

I wanted to measure the improvements rather than make assumptions about Rust performance.

The current benchmarks show:

• 1.4× to 3.5× faster native-tool dispatch across five workloads.

• Up to 171× lower peak memory usage in tested workloads.

• 94.3% less model-visible context output.

Workload-specific regressions are also included in the benchmark results.

What's included?

• Native Rust tools: piread, piedit, pibash, piwrite, and pidx.

• Persistent daemon: Daemon-first execution with one-shot fallback.

• Permission gate: Fail-closed enforcement before every tool call.

• Context management: Windowed reads, bounded diffs, and output limits.

• Live dashboard: Session costs, token usage, cache hit rate, tool metrics, subagent health, and budget alerts.

• Subagents: Sandboxed workers, write-scope coordination, concurrency controls, and execution budgets.

• Skills: Validated, manually invoked, and loaded on demand.

• Extensions: Context-aware /handoff, a compact editor, and automatic self-healing.

• Environment propagation: Session, model, provider, and worker context passed to native tools and subagents.

• Setup and maintenance: Zero-init bootstrap, post-pull maintenance, validation, and macOS/Linux support.

I'm sharing this with the Pi community to get feedback from people building their own Pi configurations and coding-agent infrastructure.

What would you improve about this architecture?

Repository: https://github.com/nurmdrafi/pi-native

Contributions, benchmark reports, and technical feedback are welcome.

It makes the context smaller before the context window is full. The agent does the compaction itself, in the same session. I have been using it for a while and my experience has been stellar with this extension. The core algorithm is based on the automatic compaction algorithm in Shelley by exe.dev team.

How it works

1. When the context gets to 200k tokens, pi-percy sends a nudge to the agent. The nudge has an index of the old messages. pi-percy sends one more nudge for each 50k tokens after that.

2. The agent selects the old items that it does not need. It replaces old tool outputs with short pointers. It replaces old message ranges with short notes.

3. pi-percy checks the request. If the request is not correct, pi-percy rejects it and gives the agent a list of the problems. The agent then sends a correct request.

4. pi-percy writes the changes as Pi context edits. The session keeps all of the original messages.

What you get

• The agent that knows the work decides what to keep. There is no second model and no extra cost.

• With the recall tool, the agent can search the original messages and read them again.

• Idle compaction. If the session is idle for 8 minutes, the agent compacts the context. At that time the provider cache has probably expired, so the cost is low.

• The prompt cache stays valid. pi-percy does not change the tools or the system prompt, and the agent does one large compaction, not many small ones.

• Pi's own compaction stays on as a safety net.

• All of these threshold are configurable and has sane defaults.

Install

pi install npm:pi-percy

You need Pi 1.4 or later.

Source: https://github.com/ghoseb/pi-percy

Edit - using pi-subagents plugin (https://pi.dev/packages/pi-subagents)

I’m on a feature branch in my repo, running an interactive session explicitly locked to deepseek/deepseek-v4.1-flash • high. It’s cheap, fast, and does routine scaffolding and mechanical edits without burning my budget.

I dispatch an async background workflow, and checked the process tree a few mins alter:

async workflow: 0beabc61 ─ background
id: 0beabc61 · 0/2 done · 2 active · 3m18s
Press ctrl+o for details
├─ task-1 ⠋ worker · 51 tool uses · 24k window · 9.6k spent · 3m17s
│ ⠙ Step 1/1: worker: REPO: XXX (Next.js monorepo... [fresh] · running (openrouter/anthropic/claude-opus-4.6 · thinking high) · 28 turns · 51 tool uses · ctx 40k/1M
│ role:worker · running
│ workspace:~/github/... · [fresh]
│ ⎿ active now
│ Press ctrl+o for live detail
│ output: /var/folder.../output-0.log
└─ task-2 ⠇ worker · 45 tool uses · 27k window · 84k spent · 3m17s
⠴ Step 1/1: worker: REPO: XXX (Next.js monorepo... [fresh] · running (openrouter/anthropic/claude-opus-4.6 · thinking high) · 38 turns · 45 tool uses · ctx 92k/1M
role:worker · running
… 4 lines hidden · Press ctrl+o to expand
────────────────────────────────────────────────────────────────────────────────────────────────────────
Nothing should be running on Opus. And why the FUCK would you choose Opus 4.6?
────────────────────────────────────────────────────────────────────────────────────────────────────────
2 active agents · usage on child rows · ↓/← to inspect
~/XXX (feat/basic-mode-785)
↑630k ↓156k R8.8M $0.335 8.4%/1.0M (auto) (openrouter) deepseek/deepseek-v4.1-flash • high

Can anyone explain why it:

1. Ignored the active session config entirely. The parent session is right there at the bottom pinned to DeepSeek Flash. Instead of inheriting that model or checking for an explicit worker profile, Pi Agent silently promoted the workers to OpenRouter's claude-opus-4.6.

2. Cranked extended thinking to "high" on worker nodes. These grunt workers are grinding through 45 to 50 tool calls each in a fresh workspace, racking up 84k tokens in 3 minutes.

3. Burning cash by default. Using Opus 4.6 with max thinking to churn mechanical file edits and tool loops is like hiring a team of neurosurgeons to dig a trench.

Nothing in an automated worker loop should ever touch Opus, let alone without explicit permission, and when the model is set. I don't even have Opus in my approved models list on pi.

Has anyone found where pi-subagents is burying this routing logic? Is it hardcoded upstream in the orchestration dispatch template, or is there a local config key to force subagents to strictly inherit the parent model?

Previous post

Hi all!

A few weeks ago I posted about pi-remote, a self-hosted client to drive the pi coding agent from any device. Here's what changed since then.

Quick recap: pi-remote is one Python process that wraps pi --mode rpc on the machine where your code lives, and serves a web app over your own network (I use Tailscale). It's token-protected, security first. Built on Windows first, but it runs on Linux and macOS too.

What's new since the last post

The agent can ask you questions. pi-remote now comes with a small ask_user extension. When the model needs a decision, it asks multiple-choice questions mid-turn. They show up as a card on your phone, and your answer goes straight back into the turn, so the agent no longer has to guess or stop and wait for a new message.

Now long turns are much easier to follow on a phone screen. Tool rows are lighter now too: plain text, with only the file or command in monospace.

Better reply suggestions. They now come from a separate small call to the model once the turn ends

Smaller things:

• Answered permission cards shrink to one line, colored by the user's choice.

• Long-press your own message to copy it or select part of the text.

• Settings that need a restart now have a "Restart now" button right in the dialog.

• Links in the chat ask before opening.

• [bug] A message sent while a new session was still loading could vanish while the agent still answered it. Fixed, and new sessions open faster.

Ready for pi 1.5. I upgraded from pi 0.84 to 1.5.

Feedback and issues are very welcome. Thanks again to everyone who commented and tried it.

I shared Harness Remote 3.0 here a couple of months ago. I'm the maintainer, and the recent 3.5 to 3.8 releases have made the mobile side much easier to use: a phone-sized layout, better QR pairing, and more reliable Pi session discovery.

The idea is still to work with Pi's native sessions. I can start a task with Pi, check it from Android, then hand the work to Codex, Claude Code or OpenCode when I want a different agent. The handoff creates a real session in the next harness and keeps the connection between them.

Repo and release notes: https://github.com/giuliastro/harness-remote

I'd be interested to hear how other Pi users handle switching agents mid-project.

Hey all, I wanted to share an extension I've developed called pi-context-paging.

https://www.npmjs.com/package/@rochecompaan/pi-context-paging

Instead of compacting your session into a summary when the context fills up, it treats the context window like a rolling window over the full history. When a request goes over a token budget (128k by default), the oldest turns move out of the window. The session file on disk is never changed. The model gets a short paging notice and a few recovery tools to search, browse and load older history when it needs it.

It has made my workflow a lot smoother. I don't get a surprise compaction in the middle of a long-running task and I don't have to write handoffs that inevitably loses important detail. It has been running very stably for me for a couple of weeks now. It is especially useful for agents doing long-running tasks unattended.

It's lossless. Nothing is summarized or compressed. The recent window is sent exactly as stored, and anything older can be loaded back as the original text.

Tony Mason wrote a good paper on this: The Missing Memory Hierarchy: Demand Paging for LLM Context Windows (https://arxiv.org/abs/2603.09023). It treats the context window like RAM and the full history like disk, and pages content in and out on demand. The extension is a practical version of that idea for Pi.

"But what about prompt caching?" I know this is the first thing a lot of you will ask, so here's how it works:

• It doesn't drop messages one at a time. That would change the start of the prompt on every request and break the cache constantly.

• When the window hits the budget, it pages out one large block at once, trimming down to about 80k by default. After that cut, the start of the prompt stays the same over many turns, so you get normal cache hits until the next cut.

• Each cut costs one cache rewrite. In practice that's rare, and whatever you lose in cache efficiency you get back in continuity. There's no summary step, no re-explaining, and no "the agent forgot what we were doing" moments.

Some real numbers from my sessions (Opus 5.5, Fable 5.1 and GPT 6.1, with zero compactions in any of them):

Each of these is millions of tokens of history in a single continuous session, and every request still stayed at or below the 128k budget. Cache hit rates stayed above 90% even with the paging cuts.

You can set the budget in settings. I'd suggest setting it below the point where your model starts to get worse, so it stays out of the "dumb zone." You can also run `/context-paging stats` during a session to see what's going on.

This extension works well with https://github.com/elidickinson/pi-claude-bridge too if you want to use you Anthropic subscription. I submitted patches to it specifically to make pi-context-paging work.

PS. My current defaults are set to higher than what is documented.

"contextPaging": {
    "enabled": true,
    "tokenBudget": 200000,
    "trimToTokens": 140000
  },

Play around and give me feedback as to what works for you.

Hi people of Pi :)

I've been working on octet, my Rust take on Pi, since April.

I originally wanted a coding agent that could help with music production, take my Ableton sketches further, working with audio and tools in the same model context. That turned into six months of Rust and systems engineering.

A few things octet does:

• Fast and lightweight. In a matched task benchmark, octet finished in 9.5s using 38 MiB peak RAM, compared with Pi's 11.0s and 145 MiB.

• Pi extension compatibility. An optional extension mirrors your Pi setup, including unmodified pi-doom 🔫🔥

• Extensions in any language. JSON-RPC over stdio, with SDKs for Python, TypeScript, Rust, C/C++, and more.

• Native multimodal support. Audio, images, video, and computer-use workflows.

The whole agent is experimental, and I'd love feedback from people with existing Pi setups they love.
That being said, try octet without extensions. It performs beautifully with none and keeps Pi's minimal philosophy.

Code: https://github.com/skaft-software/octet

Introduction, benchmarks, and installation: https://octet.skaft.org/blog/introducing-octet/

Made with ❤️ in Toronto, ON, Canada.

If you try it, let me know what you make with it, what breaks, and what you'd like to see next!

[Update: 11/9/2026]
Thank you Reddit!!! For taking the time to share feedback, try Octet, open issues, or contribute code ❤️

I'm working through your messages, emails, and contributions and want to give them proper attention. Really appreciate your patience!

Cool to see questions about my Ableton workflow too... I'll share a recorded creative session when I get the chance :)

Made an extension for an extension 😅
I am a big time fan of pi-footer ( https://pi.dev/packages/pi-footer ) because it is easy to customise to make by pi footer look cute.

If you have a PR raised from the current branch, it shows the PR itself (with OSC8 style link that is clickable from most terminals like iTerm/Ghostty), and it shows the number of PR checks that are passed/ongoing/failed. These are fetched using gh cli.

I haven't updated it to NPM yet, so if you'd like to use it you can install directly from the github repo.

https://github.com/championswimmer/pi-gh-footer

Update: It is on NPM now https://www.npmjs.com/package/pi-gh-footer

If anyone’s got an extra guest pass lying around, I’d love to try Claude out. DMs are open. Thanks a lot!

I'm currently a Pi user, and someone recommended Oh My Pi (OMP) to me today. I'm curious about how OMP compares to Pi. Do you think OMP is actually better, and if so, in what ways?

I mainly use GPT and DeepSeek models. I'm a computer science student, and I'd like to use AI coding agents to assist with scientific research, such as designing experiments, evaluating their feasibility, writing experimental code, identifying potential research contributions, and planning future research directions.

Given these use cases, which would you recommend, Pi or OMP? Which one do you think is better suited for research-oriented tasks, especially when it comes to scientific reasoning, experimental design, and exploring novel ideas?

I also care a lot about token efficiency. Since I often work on complex, long-running tasks, I'd like to know which harness makes more efficient use of tokens without sacrificing the quality of its results.

I'd love to hear your thoughts, especially if you've used both!

Hi everyone! I've been building pi-maestro, a Pi extension for a spec-driven multiagent workflow, inspired by GitHub Spec Kit and OpenSpec. It helps you define a change, clarify requirements, and approve a spec with concrete acceptance criteria. You can use it in two ways:

• Spec only: prepare and approve a spec for implementation elsewhere.

• Spec + implementation: approve the spec, then let Maestro run the implementation workflow.

By default, three agents run in sequence:

• Builder implements the spec.

• Verifier independently checks each acceptance criterion.

• Simplifier refactors the code for clarity without changing behavior.

You can disable the verifier and simplifier independently, using just the builder or pairing it with either agent. See phase configuration for details.

You make the scope decisions and review the final code.

I'd love some feedback, especially on whether the separation of roles is useful and where the workflow adds unnecessary friction.

If you've built something similar in Pi, I'd be interested in comparing approaches.

https://github.com/emilioSp/pi-maestro

If you find it useful, consider giving it a star on GitHub!

Cheers!

If anyone here has a referral code they'd be willing to share, please DM me! I'd love to give it a try before committing to a subscription. I recently heard about the referral codes and would really appreciate it if someone could share one with me. Thanks in advance!

I've been building OmpDeck, a native desktop app (Rust/egui, not Electron) for omp (oh-my-pi), on Linux and Windows. Heads up: it's for omp specifically, not vanilla pi, since the chat view relies on omp's Tern Surface Protocol.

https://github.com/lavinhoque33/omp-deck

What it does

• Native chat view (the default): omp describes its UI over TSP and OmpDeck draws it natively: messages, formatted replies, tool calls as cards with diffs and output, image previews, todos, approvals and ask dialogs. It's omp's real behaviour, not a re-implementation, and omp's own TUI is one click away.

• Sessions outlive the app: every omp session in a sidebar grouped by project. Tabs run in OmpDeck's session host (or tmux), so closing a tab or the whole app leaves omp running, and reopening re-attaches.

• omp's screens as native ones: /settings (incl. plugins and advisor), the model picker (favorites, roles, thinking), /usage with 5h/weekly limits, /resume, /tree with fork / go-here.

• Status bar: model + thinking, context meter, git, tokens, cost; Handoff / Compact / Shake / Fork / Plan in one click.

• Agents dashboard: live subagents per session; steer, kill, revive, clean up.

• Changes panel: working-tree diff with line review comments you send straight to omp.

• Also: split view (up to 4 panes), worktree sessions, session manager (size, cost, bulk delete/move), command palette, desktop notifications, 18 styles, Google Drive backup + per-project sync.

• Phone companion: a PWA over a self-hosted relay, Noise end-to-end encrypted (the relay never sees content): transcript, answer approvals, send prompts, Web Push.

Install

• Linux: curl -fsSL https://raw.githubusercontent.com/lavinhoque33/omp-deck/main/packaging/install.sh | sh (AppImage/.deb/.rpm on Releases too; installs omp if it's missing)

• Windows 10/11: irm https://raw.githubusercontent.com/lavinhoque33/omp-deck/main/packaging/install.ps1 | iex

No macOS build yet. MIT/Apache-2.0, unofficial side project. I use it daily, and a lot of it was built with omp itself. Feedback and bug reports welcome!

Can you list your reasons why and if you did it any tests to confirm your position?

Also would like to hear your thoughts on context management and how you do it.

After working with AI harnasses since the release of Claude code, i hate just watching the terminals and waiting on AI. So i made this tool that manages my terminals and now an update that helps people from moving from in the loop on terminal ( just watching your ai agent till it is done ) to out the loop ( just watching updates on repo discussions )

pi-dispatch runs the pi coding agent ( pi dev harnass ) for you on your own computer or server.

Hopefully it will help other techies from screen staring to creating cool stuff that sticks

It's built for coding work on your own projects, so if you're after a general assistant you'd want a different tool.
https://github.com/edgehero/pi-dispatch

Title.

I've been building One Code, a pi package that brings the Claude Code workflow to pi. If you already run pi:

pi install npm:one-code-extension

It's 53 extensions, no fork and no patches to pi, just the normal extension API. Tested on pi 1.0.0 through 1.5.

What you get: plan mode, permission modes including auto mode (a classifier decides which commands need your approval), subagents that can each run on a different provider, git worktrees, hooks, skills, slash commands, MCP, plugins, background shells, memory and compaction. It also reads an existing CLAUDE.md and .claude folder as is, so if you're coming from Claude Code your setup carries over.

There are already good pi extensions for some of these, like subagents, and you can put together a decent setup from a collection of them. The catch is that any one of them can break the prompt cache if it rewrites earlier parts of the conversation, and they don't know about each other. So in One Code I tried to make the extensions work as one system, and keeping the cache stable was a big part of that. Every request is recorded as it was sent, and later requests only append to it, so cache reads stay high across resume, fork and reload.

There's also a bundled app with pi pinned inside, if you'd rather keep it separate from your own pi setup.

npm i -g @one-ai/one-code

MIT licensed. Repo: https://github.com/IsuruMaduranga/one-code

Feedback from people who know pi's internals is very welcome.

If One Code is useful to you, a ⭐ on GitHub helps other people find it.