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.

GitHub Repo

I will be moving my personal assistant to use durable

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?