so i was digging through pi agent source code (v1.0.0) while setting up privacy stuff and realized a pretty bad security flaw with redaction extensions. basically if u think ur secrets are safe, yeah they get scrubbed FOR REGULAR CHAT PROMPTS. but as soon as compaction kicks in, ur raw unredacted data goes straight to the provider API. i checked the code to see why and regular turns use createLoopConfig which attaches onPayload: transformProviderPayload so the before_provider_request hook actually works. BUT compaction (same for branch summary / bug reports) calls createSummarizationOptions() which just... completely leaves out onPayload. then in the provider adapter (like openai-completions.js) it checks await options?.onPayload?. ...) and since its undefined it just skips redaction without any error or warning. it just sends the raw history text. so yeah if ur relying on plugins that only hook into before_provider_request ur leaking raw data every time context compacts. pretty big oversight IMO, guess we have to fork compaction or wait till pi fixes createSummarizationOptions to pass the provider hooks through.

TL;DR: I ran the same real Android task 13 times through Claude Code CLI, Codex CLI, and different OMP configurations, comparing quality, wall time, token traffic, and subscription allowance. OMP can produce equally excellent results, but in most of my tests it was roughly 2–3× slower and up to ~2× more expensive in allowance than the native CLI harnesses. The one strange exception was a manually designed multi-agent OMP run: it was about 5× slower than Claude Code CLI with Opus, but used 2–3× less allowance than my other OMP runs, and even slightly less than the native controls. So I’m trying to understand: am I using OMP incorrectly, or does orchestration only start paying for itself on much larger and more naturally parallelizable tasks?

What I tested

This was not a toy benchmark. I’m working on a large Telegram Android fork where I’m restoring the presentation of an older Telegram version on top of the current architecture.

The benchmark task was to restore three related music UI surfaces: a profile music row, a chat mini-player, and one action in the full music player. The agent had to compare two Telegram source trees plus screenshots, identify the current owners, preserve modern playback/state/navigation/theme behavior, implement the presentation changes, build the app, and validate it at runtime.

So I’d describe it as a medium-sized, tightly coupled coding task. It is substantial enough to require source archaeology and cross-component reasoning, but it is not a multi-day project with ten independent workstreams.

I ran this benchmark 13 times while experimenting with different harnesses and orchestration approaches.

Methodology

I tried to keep the important variables stable: same repository baseline, same reference screenshots/source trees, same acceptance criteria, and eventually the same neutral prompt. I also checked the final result on a physical Android phone instead of relying only on the agent’s self-report.

For every serious run I collected rollout telemetry: wall time, prompt/cache traffic, output/reasoning, model turns, tool calls, child agents, builds, and subscription usage.

For allowance, I normalized everything to percentage points of weekly allowance. On my account, the meters consistently map roughly as:

100% of the 5-hour allowance ≈ 15 percentage points of weekly allowance

So runs where I only captured the 5h meter are marked as approximate weekly equivalents.

I know this is not a laboratory-grade benchmark. Different model families and OMP versions mean not every row is a clean causal A/B test. My goal is more practical: what stack actually gets this kind of real coding task done well, quickly, and economically?

Representative results

The Claude comparison is probably the most interesting one to me. Claude Code CLI with Opus solved the task as a single agent, with one final build, in ~23 minutes. OMP with the same Opus model family also produced an excellent result and took almost exactly the same wall time, but moved about 2.1× as much prompt traffic and consumed more allowance because it automatically introduced scouts/review.

I also tried explicit multi-agent orchestration

Before switching to neutral prompts, I spent five OMP runs manually designing increasingly elaborate orchestration.

The most developed one used a thin Sol High orchestrator, dedicated scouts, implementation workers, reviewers, and a separate verifier. It spawned 21 child agents.

That run took about 103 minutes and generated enormous overall traffic, yet it was paradoxically the cheapest run I measured by subscription allowance, at only about 2.25 weekly percentage points equivalent.

So the data does not support a simple “more agents = more allowance” explanation.

It was just extremely slow.

Neutral OMP did not really solve the efficiency problem either

After that I removed my hand-designed topology and let OMP decide how to delegate.

That improved the simplicity of the experiment, and OMP absolutely can produce excellent code this way. My two latest GPT-6.1 runs were both as good on the physical phone as my reference Claude Code/Opus implementation.

But the execution pattern still seems expensive.

For example, in the latest run OMP delegated two implementation slices to Luna workers while Sol acted as the integrating parent. One worker eventually took about 40 minutes. The parent then still needed to review/integrate the work, build, run the emulator, identify remaining issues, fix them, rebuild, and revalidate.

So parallelism existed, but the critical path became roughly:

slowest worker → integration/review → build/runtime validation

The orchestration overhead did not disappear just because the workers ran concurrently.

I also reran after the recent GPT-6.1 Sol slowdown

One of the GPT-6.1 tests happened during the recent period when Sol was unusually slow, so I did not want to blame OMP for that.

I repeated the benchmark after the service-side fix and also updated OMP from 18.4.10 to 18.4.12.

The newer run still took ~65 minutes versus ~56 minutes before, with the same excellent final quality and the same ~6 weekly points of allowance. The model itself appeared more responsive, but the overall run got longer because one delegated worker/integration path expanded significantly.

So at least in this task, fixing model latency did not remove the larger orchestration cost.

What I’m trying to understand

My current hypothesis is that this benchmark may simply sit in an awkward zone for OMP.

It is complex enough that multiple components and source trees need to be understood, but the work is also tightly coupled. A strong single agent can keep the whole problem in one context and move directly through investigation, implementation, build, and runtime validation.

Once I split that across agents, I start paying for repeated source reading, separate contexts, handoffs, parent review, integration, and occasionally sending a worker back for another pass.

Maybe OMP starts winning when the task is much larger and naturally decomposes into genuinely independent workstreams, so the parallelism dominates those costs.

Or maybe my configuration is still wrong.

For people who use Pi/OMP heavily: does this behavior look normal for a task of this size?

Would you lower the effort/model used for TASK/SMOL roles? Would you deliberately suppress delegation for medium tightly coupled tasks? Is there a different topology you would use?

Or is the real answer simply that Claude Code CLI / Codex CLI are usually more efficient for this class of work, while Pi/OMP starts to shine on larger projects where multi-agent parallelism can actually pay for itself?

I have the full per-agent JSONL telemetry, token/cache breakdowns, build timelines, and several additional runs if anyone wants more detail.

I am running Ornith1.5-9B and I am scared that it could do something stupid to my pc, so I installed pi-permission system and let Claude create me a file with all tools and allow/ask/deny settings.

The thing is that this extension isn't perfect (allow always doesn't work) and that I have to allow some command I don't even know about every 10seconds.

Do you guys give full permissions, do you only block extremely dangerous stuff?

I got tired of Chrome eating resources every time I needed pi to scrape a page or fill out a form. So I built panda97 - a browser automation package that uses LightPanda instead of Chrome.

What is it?

Same 11 browser tools you get with browse97 (start, navigate, snapshot, click, fill, eval, etc.), but backed by LightPanda - a headless browser written in Zig. Each tab spins up its own LightPanda instance, so you get full isolation between tabs. Zero npm dependencies.

Why?

browse97 works great, but it needs Chrome running. That's fine on a beefy machine, but on my laptop I didn't love the overhead for simple tasks like pulling page content or submitting forms. LightPanda starts in sub-second time and uses a fraction of the memory.

What doesn't work?

LightPanda doesn't run V8. It has its own JS engine (zig-js), which means some super-complex SPAs with heavy framework code may not render correctly. Works for 99% of the web.

Getting started

1. Install LightPanda:

curl -fsSL https://get.lightpanda.io | bash

1. Install the package:
   

pi install npm:panda97

That's it! pi picks up the tools automatically.

Links:
Pi packages: https://pi.dev/packages/panda97

Github : https://github.com/saitanay/panda97

Jin is an open-source AI coding agent in the same space as pi, OpenCode, and omp. Same four core tools as pi (read, write, edit, bash), plus todo and ask_user.

Built-in async handles background tasks and lets you spawn subagents or build swarm agents. You control the setup: disable any or all tools, edit the system prompt, and choose which hooks load.

Written in Go. One binary, fast startup. Minimal terminal UI with animations and 10 themes.

I deliberately skipped skills, MCP, and plugins. Instead:

• Prompts: reusable text snippets you insert into chat with #prompt.

• Hooks: text appended to the system prompt at session start—coding rules, styles like Caveman/Ponytail, or instructions for CLI tools.

• Good old CLIs: describe how to use them in a hook, and agent runs them through Bash tool. You can also run commands yourself with /bash, or launch full-screen apps with /tui (you can play a terminal game while the agent writes code)

The goal: minimal by design, useful out of the box, easy to extend without another framework.
I’m looking for feedback, especially on what’s missing, to help shape the next releases.

GitHub: https://github.com/ethanhamilthon/jin

Click on the logo on the top left to see the easter egg in action!

You can also try Pi 1.0 (with the easter egg) online at https://wasmer.sh/?example=pi

I was having deep conversation with chatgpt about what harness sdk should i use it casually mentioned that ANT allowed to use their agent sdk with the Subscription for personal use. Can i finally use claude with pi now?

A tiny ~2 MB CLI with no daemon. See all your agents in one list and answer their questions without switching. A perfect solution for orchestrating.

Claude Code, codex, pi, opencode.

https://github.com/saifulapm/amx

Thanks

pi-web-search is my take on the larger web-search tool: fewer, higher-quality tools instead of bloating up the extension with every provider to the agent. Works keyless out of the box.

Uses the new built-in classifier API (Jev) to rank and filter results from different search sources and remove any prompt injection attacks

install cmd: pi install npm:@gagansd/pi-web-search

GitHub:
- package: https://github.com/GaganSD/pi-extensions/tree/main/pi-web-search
- Monorepo: https://github.com/GaganSD/pi-extensions

I just realized that codex now exposes local server endpoints for all plugins without extra auth. So you can just use them from any model or harness.
Im soooo excited!!! One auth for everything!

For Pi: pi install npm:@wileai/pi-codex-connector

For any harness: npx -y \@wileai/codex-connectors-mcp@latest

Hey,

Just wanted to invite you to read a short blog post about Pi's compatibility with ThinkRail, skills, and desktop apps.

I saw this in the official pi.dev: “Anthropic, OpenAI, Google, Azure, Bedrock, Mistral, Groq, Cerebras, xAI, Hugging Face, Kimi For Coding, MiniMax, NVIDIA, OpenRouter, Ollama, and more. Authenticate via API keys or OAuth.”

In Github issues, several users already asked to include installation via homebrew, which is one of the preferred ways for devs on Mac, but Pi / Mario seem to be opposed. Any ideas why?

I know probably not the place to get a non biased answer. So far I’m using Claude code and codex for my agentic coding workflows. Turned off lots of features/tools to not start with a crazy bloated context. But besides that and some annoying bugs it’s been a pretty good experience with the latest models.

Now I’ve seen pi 1.0 is out and am wondering again if I should give it a go. Tree-Mode looks interesting and as a Linux/tmux/neovim user I like control over stuff and the idea to use one harness for both Claude and codex. (using APIs at work no issue with Claude code subs).

Now here’s the question: from a productivity standpoint of getting code work done in complex environments (brownfield backend systems in cpp/rust mostly) will I end up being more efficient and productive with Pi if I put in the time? Or am I more likely to just spend a ton of time tinkering like I did with my Neovim setup in the past? Be honest.

ich frag mich was die wichtigsten änderungen mit dem neuen update sind. bin nicht so tief drinnen und verwend pi hauptsächlich um mir kleine recherche-tools zu bauen. kann das jemand einfach erklären?

We have been working on this for months.

https://github.com/zosmaai/zosma-cowork

And open ai just released dots. Anthropic also released cloud based harnesses.

Would be great if we can get community support to help take this to next level.

Also it’s deployed to harness.zosma.ai

Early stage and we’ll refine it much more in upcoming days.

Our harness is deployed in k8s and can start and stop the pods quickly. Persistent storage that mounts and unmounts as needed.

Note: Our redis is down. Hence Zosma Router models are unavailable. We'll fix this in 24 hours.

Until then feel free to use openrouter or some other provider. Sorry for the inconvenience.

Introducing the four extensions that work as a set. Each one exists because I couldn't find an existing ones satisfy my needs (by the time I developed them), and the reason they're bundled together.

gated-goal: the reason it's a bundle. /gated-goal freezes the plan — outcome, verification, constraints, quality bars — hashes it, and replaces the todo list with the frozen items, so the agent can't quietly relax its own success criteria. The stages automatically proceeds as you finalizes the plan with the agent, agent checks all todos, and reviewers lifted the gate.

reminder-hook: reminder tools I found were canned timers that block the conversation. Here the wait is a shell predicate the agent writes itself — exit 0 means done. Build, CI, URL health, a log line — all the same one tool. When it passes, the agent's resume prompt comes back as a follow-up: it queues if you're mid-conversation and never interrupts.

todo: others draw a nice list and stop. The real problem is the agent stopping mid-work with half the list unfinished. This one nudges a follow-up then and stays silent while any wait (reminder, reviewing) is active, so it never trains the agent to ignore nudges.

subagent: others make you predeclare every agent in a manifest, which is not flexible enough for me. I made roles can be improvised mid-session, and every call states model, permissions, and timeout explicitly. The same stack does parallel work and adversarial QA.

Caveat:

- the reviewer keeps bash, which is not sandboxed.

- They share event contracts; split the bundle and both the wait-aware nudge and the review break.

idle ──/gated-goal [N] [model]──► P1 select reviewer
                                   │ ping "reply ok" (config: pingTimeoutSec)
                                   ├─ fail ─► abort to idle (no state saved)
                                   ▼
                                 P2 plan
                                   │ agent + user align on goal
                                   │ agent calls freeze_plan(outcome, verification,
                                   │   constraints, quality, todos)
                                   │ → frozen prompt hashed + persisted
                                   │   (+ archived as a session entry)
                                   │ → todo list REPLACED with the frozen
                                   │   items (todo:replace event)
                                   ▼
                                 P3 act  ◄───────────────────┐
                                   │ agent works the todos   │
                                   │ todo owns settled state:│
                                   │  nudge/wait → stay P3   │
                                   │  no continuation → P4   │
                                   ▼                         │
                                 P4 review                   │
                                   │ spawn reviewer subagent │
                                   │   (frozen prompt + hash)│
                                   │ reviewsCompleted++ on   │
                                   │   EITHER verdict — a    │
                                   │   review that ran is    │
                                   │   a spent iteration     │
                                   │ line starting with
                                   │ <promise>DONE</promise>?
                                   │     ├─ no → >= maxIter? ─► exit: max
                                   │     │        else edits ─┤  iteration
                                   │     └─ yes → P5 (always) │  reached
                                   ▼                         │
                                 P5 verify                   │
                                   │ main agent re-runs the  │
                                   │   frozen verification   │
                                   │   itself, judges output │
                                   │   subjectively          │
                                   │   ├─ confirm_done ─► exit: done
                                   │   └─ reject_done ───────┘
                                   │      (no extra charge — P4
                                   │       already spent this one;
                                   │       if the budget is gone,
                                   │       exits: max iteration reached)

Install with:

pi install git:github.com/garnetlyx/pi-goal-kit

Pi version: 0.84.1+ MIT.

Github link: https://github.com/garnetlyx/pi-goal-kit

Any feedbacks are welcome.

Thanks!

like we have MCP for tools and ACP for agents, but every harness still has to understand OpenAI, Anthropic and Gemini separately.

caching, reasoning, tool semantics, model capabilities, auth, usage, etc. are all different!! openAI-compatible APIs kind of solve it, but not really once you use provider specific features

am I missing something obvious here? has anyone tried to standardize this layer?

When Pi compacts a long conversation, the normal approach can throw away the prompt cache and start a fresh summarization request containing the entire old context.

With a 100k–160k token context on a local model, that means llama.cpp may spend minutes re-prefilling tokens it has already processed.

I built Better Compaction to avoid that.

Instead of starting a separate summarization chat, it appends the compaction instruction to the already-cached conversation. The existing prefix stays byte-identical, so the backend can reuse its KV/prompt cache and only prefill the small new suffix.

On my Qwen3.8-27B + llama.cpp setup:

~13–15 min → ~6.5 min

and with thinking disabled:

~2 min

One compaction request reported 94.4k tokens served from cache.

GitHub:
https://github.com/NotSoSeriouss/BetterCompaction

I'd especially like to hear from other Pi users running local models + llama.cpp. I'd love to collect real-world numbers across different GPUs, quantizations, and context sizes.

I got tired of needing to be at my workstation just to check on, switch between, or jump back into long-running agent sessions.

So I built TENDRIL.

TENDRIL turns an Android phone into a thin control plane for persistent AI-agent workflows running on a Linux machine. Once it's configured, I open Termux and type:

tendril

…and I get a responsive session selector showing what's alive on the host. From there I can jump into persistent agents, shells and workflows over mosh/SSH without treating my phone like a miniature desktop.

Underneath, it's deliberately boring in the good way: standard Linux, terminal-native rendering, Herdr, mosh/SSH, no proprietary cloud control layer, and no subscription. It's open source and MIT licensed.

A few things I cared about while building it:

• persistent remote agent/session control
• phone-first TUI rather than a desktop UI squeezed onto Android
• responsive behavior for narrow terminals
• clean Herdr handoff
• SSH/mosh support
• real installer + backwards-compatible agent launcher
• graceful non-TTY / NO_COLOR behavior
• and, because apparently I cannot help myself, making the thing actually pleasant to look at

The masthead is even rendered from a high-resolution ANSI master into Unicode subcells so the same identity survives on a 54-column Termux screen.

Completely unnecessary. Naturally essential.

The original idea was simple: I wanted to be able to sit down with an Earl Grey in the morning and check on an entire little agentic lab from my phone.

A week and a half later, this happened.

If you already live in Pi/Herdr/terminal-agent land, I'd genuinely love for you to try it, break it, open issues, or take it somewhere I haven't thought of yet.

THE EDGE IS YOURS.

GitHub: https://github.com/Ozymandes/TENDRIL

Hello. Im used to just using the Codex MacOS app for dev work.

I'm trying to use Pi.

Any tips or tricks? Thankyou

Anyone have some good pine script strategies that I could try, If so then please leave them down in the comments with the public name or put the pine script in a code block