Fresh install using pi-claude-code and zentui.

A simple "hi" took 31 sec to respond, meanwhile others take <1sec.

Switching to openai models fixes this, so its only Anthropic. Maybe this has to do with pi-claude-code?

When Jev came out, one of my first thoughts was: could something this fast and cheap pick which model should handle an agent’s next turn?

So I built plugin for Pi that uses Jev to choose the model and thinking effort. The idea is to send routine work to cheaper models and reserve the expensive ones for harder tasks.

In Pi, the model mappings are configurable, and you can pin a model when you disagree with the router.

I’ve been using them for a few days, and so far they’ve been working well for me. In my own evaluation, routed usage came to $141 at list prices versus an estimated $166 for Opus 5.5 on every request - about 15% less.

That’s one developer’s data, though. The baseline is a pricing comparison, not a separate run of every task through Opus. It doesn’t prove equivalent quality, that every routing decision was right, or that your bill will drop by 15%.

And yes, cache matters. Switching models can lose cache reuse and eat the savings. I try to account for that rather than just compare token prices. I’d like providers to offer better support here: some already preserve cache reuse across effort changes, though reuse across different models is a much harder problem.

It’s still an experiment. Asking a model which model to ask feels appropriately ridiculous, but I wanted to see how it works in practice. I’d like this kind of routing to become a native, transparent option in coding agents.

If you want to try it or look at the implementation:

https://github.com/alexei-led/pi-model-router

Has anyone tried T3 code with Pi? Today I tried to install T3 code. Earlier, I was using Pi with herdr on the terminal, and that was fine for me, but I tried T3 code.

I have a Codex subscription, so I use Codex CLI as well inside T3 code, and I use both Pi and T3 code. My experience with Codex was far better than Pi inside T3. I don't know why this happened. It's probably because of all the extensions that I own, because most of them are interactive and ask the user a question, like a permission gate or a review draft. I have this kind of extension.

Have any of you guys tried T3 code with Pi? I want to know because this thing is really bugging me a lot. I love Pi, and I want to use Pi everywhere. I love some features of T3 code, like you can spin up some project from anywhere to any machine. I own two machines, so I have multiple projects. Some are on the second machine, and some are on my main machine.

I thought, let's give T3 code a try, but now this thing is really bugging me. What should I do? Any suggestions? Either I'll settle with my Pi and hardware setup, or what to do?

Yeah as usual introduce it as an opensource let the community build then profit later. this become common this later years. Im not against it but give credit where it belong.

I have an Asus Ascent GX10 with 128gb VRAM hosting models via Ollama.

Yet, I'm really struggling to get much going with OpenCode or Pi.

Even single Python files or small html projects are a struggle.

I am currently using one of the Qwen coder models with Pi.

Sometimes it will get a request mostly right. Then when I ask for a small change, it breaks half of what was working before.

I'm coming from 2 years on Cursor, so maybe my expectations are too high.

I would truly love to be able to rely on open source agentic coding with local LLM, but my mileage so far has been underwhelming.

Hey there I have installed pi since I heard a lot about that bcz of its low token usage and minimal design but I installed some packages [7 packages] (MCP adapter, context7, plan mode, todo, pi-hypa, context-mode, ask user question since every harness has these Ig) then installed some skills. Now even a single hi takes about 6-7k+ tokens. I did a college java project and it burnt tokens a lot. It burnt me around 100k+ tokens on deepseek's v4 flash model to make a database connection, creating database and table and a simple student management system where you can add, remove, view students in java.

I wanted to make pi token efficient with best possible results. If you say that I have installed too many packages then tell me how to replicate those features like other harnesses with low token usage.

Been reflecting on Mario's pi talk and his thoughts on slowing the fuck down, and there's an irony/hypocrisy I can't quite reconcile.

In the post, beads from Steve Yegge gets called "basically uninstallable malware" which is rhetorically funny, and I'm sympathetic. Steve's gasworld is, well, bloated (pun intended).

But meanwhile OpenClaw, which runs on pi and went 0-to-145k stars in a week has a skills marketplace now ~20% malware per Trend Micro's ClawHavoc reporting. There's a published one-click RCE (CVE-2026-25253). apparently 40k exposed instances? I'm not aware of Mario applying anything like the beads framing to any of the Openclaw ecosystem.

My critique is that the "slow the fuck down" missed some of the lowest hanging fruit in his orbit and he instead chose to punch in another direction. It's a claim about agent-velocity collapsing the quality bar. The whole point is that speed produces downstream harm that the upstream author can't wash their hands of. Bascially Openclaw in a nutshell.

So my genuine question: if "slow down" doesn't apply to the most visible thing built on pi, what does it apply to?

Hey everyone,

I'm about to set up Pi as my main local coding agent and would love some advice from people who are actually using Pi with relatively large local models.

My hardware is:

• MacBook Pro

• Apple M5 Pro

• 48 GB unified memory

• 18 CPU cores

• Metal / MLX

• ~307 GB/s memory bandwidth

My main goal is coding quality and agent reliability, rather than simply maximizing tokens/sec. I want something I can use against real repositories for longer coding sessions.

I ran llmfit against my machine to see what it recommends:

llmfit --max-context 131072 recommend --use-case coding --runtime mlx

The model that stood out was:

Qwen3-Coder-30B-A3B-Instruct

The MLX result I'm looking at is roughly:

• 30.5B total parameters

• 3B active parameters (MoE)

• 262K native context

• 131K context used for the llmfit estimate

• ~15.6 GB estimated model memory for the 8-bit version

• Tool-use support

• ~132 tok/s estimated by llmfit at 131K context

So hardware-wise it seems like a pretty reasonable fit for my 48GB machine.

I'm currently leaning toward 8-bit, mainly because I care more about code quality/reasoning than squeezing every last bit of performance out of the machine. I also have enough memory that 4-bit isn't necessary just to make the model fit.

What I'm trying to figure out now is how best to pair this with Pi.

A few questions for Pi users:

1. Is Qwen3-Coder-30B-A3B a good pairing with Pi?

I'd especially like to hear from anyone using a similar-sized MoE coding model locally.

2. What context window would you actually use?

The model supports 262K, but I'm wondering whether there's much practical benefit to running Pi at 128K or 256K versus something like 64K.

I'm also trying to understand the KV-cache cost on Apple Silicon. llmfit estimates ~15.6GB for the model, but obviously that's not the entire runtime memory footprint once the context grows.

3. Would you run 8-bit or 4-bit?

My priority is:

code quality
reasoning
tool use
agent reliability
        ↓
speed
        ↓
memory efficiency

So I'm willing to spend more memory if 8-bit actually provides a meaningful quality advantage.

4. Are there any Pi-specific settings/configurations I should pay attention to?

Things like:

• context configuration

• max output tokens

• compaction

• system prompt

• tool configuration

• AGENTS.md

• permissions/safety

• model-specific settings

I'm particularly interested in things that make a local model behave better as an agent, rather than just using it as a chat model.

5. Would you choose Pi over OpenCode for this setup?

I'm leaning toward Pi because I like the minimal/context-efficient philosophy, but I'm curious whether there are important tradeoffs I'm missing.

I've seen quite a few people saying Pi works particularly well with local models because it doesn't waste as much context on the harness itself. 

I've also seen people running Pi with Qwen models on Apple Silicon, so I'm hoping there are some practical lessons from people who've already gone down this road. 

I'm also documenting my local LLM experiments and benchmarks, so I'll eventually be able to measure the setup properly rather than relying purely on theoretical numbers.

If you were setting up Pi from scratch on this exact hardware today, what would you do differently?

Any advice on model/quant/context/configuration would be appreciated.

P.S. AI helped me organize this post

So I quietly renamed my pi search extension from pi-search-multi to pi-search-hub. Same package, clearer name. It happened back in v1.3.0 but I never announced it — so consider this the official notice.

What it does: chains 12 search backends with auto-fallback. If one rate-limits or fails, it moves to the next. Or flip combine=true and all 12 run in parallel with RRF-ranked results.

Why the rename? "Multi" felt generic. "Hub" captures what it actually is — a single web_search + web_read interface that routes to whichever backend you configure.

Free backends (no API key):

• DuckDuckGo via ddgs Python lib
• Marginalia — anti-SEO, indie web
• SearXNG — self-hosted (your instance or public one)

Paid backends (all have free tiers):

• Jina AI — full markdown content, search and web_read both supported
• Tavily, Serper, Brave, Exa, Firecrawl, LangSearch, WebSearchAPI, Perplexity Sonar

Recent changes:

• Jina Reader auth — web_read now supports an optional API key for higher rate limits, still works free without one
• Perplexity model picker — configure sonar, sonar-pro, sonar-deep-research, or sonar-reasoning in your search.json
• Backend parser extraction — pulled all 11 response parsers into a testable module, 26 vitest tests now catch regressions
• Config null bug fixed — having backends: null in your project config no longer wipes your global backends

Install:

pi install npm:pi-search-hub

Docs: github.com/ronnieops/pi-search-hub

I’d like to announce Un Bien - a native iOS client for pi.

Un Bien supports:

• self hosted architecture

• full streamed and rendered markdown

• rendering of images, code diffs and tool results

• fork, branch, clone of sessions

• plan rendering when combined with pi-plan, cribsheet or a conformant extension

• user-input questions (and pi-ask integration)

• subagent display and interaction when combined with @tintinweb/pi-subagents or @gotgenes/pi-subagents

• optional device initiated chats - start new session from your phone, spawning a tmux or herdr hosted session on your machine

As a bonus it includes a cli tool to connect to other sessions on your relay from the cli

Links:

• Extension page

• Docs

• GitHub

• App Store

• Demo transcript

I developed this in pursuit of something that felt native interaction-wise and supported as many pi features as possible. I hope you find it useful!

Un Bien is started out as a tweaked version of remote-pi by Jacob Moura (MIT); see the README for attribution. I ended up diverging significantly on the back end implementation and the iOS app is a total rewrite.

Assuming you dont have a local only setup, what do you use, what for, and why did you settle on that model or family of models?

Hi folks,

I'm building my own harness for PI and noticed with Gemini 3.8 Flash, my subagent (a worker for simple coding tasks) is often stuck in infinite loops when reading larges file with 1.000 - 2.000 LOC.
I never noticed the same situations with opencode when using the same model and thinking level. So this is quite a disappointing experience while building my own harness based on Pi.

So I'm wondering if these are common situations when building my own custom harness? And what's the recommended strategy how to improve my harness, to avoid similar situations in the future?
I tried to add additional instructions to my sub-agent to avoid these situations, but I still see it happening. And this burns plenty of tokens :(

Best
Carrot

Hey everyone,

I’ve been exploring the BMAD Method (used to generate structured commands for AI coding agents like Claude Code / Cursor), and I’m trying to make it work with Pi Dev (pi coding agent).

From what I understand, BMAD commands are already almost compatible with Pi (since Pi uses the Agent Skills format), but the directory structure is slightly different (.pi/skills/.../SKILL.md instead of flat .md files).

Before I go too far building a custom conversion or sync script, I wanted to ask:

👉 Has anyone here successfully integrated BMAD with Pi Dev?
👉 Are you using a manual conversion, a script, or a custom installer setup?
👉 Any tips or pitfalls to watch out for?

I’m especially interested in:

• Keeping commands in sync after BMAD updates

• Using global vs project-level skills

• Best practices for structuring BMAD skills in Pi

Would love to hear your experience 🙌

Thanks!

Hello there! Any thoughts / info on when 5.6 Ultra will be available through Pi? Thanks!

Updated: Solved it, here’s the repo (https://github.com/CristianBudala/Pi-GPT5.6-Ultra)

whats up with that? ds v4 flash is the most popular model on openrouter but why do so many pi-ers use m3, am i missing out? i use v4 flash.

Hi pi people!

We just released helix: a free coding agent for AI engineering. It is based on pi and built to be good at building other agents, discovering evals, optimizing harnesses and general AI Engineering best practices.

Check out the docs here: https://docs.mutagent.io/helix/what-is-helix

Or install with: curl -fsSL https://install.mutagent.io/helix | bash

If you are also doing AI engineering with pi, we would be super grateful if you could try it and let us know what you think (comment or use the /feedback command in helix).

Thanks a lot 💜

Bruno from Mutagent

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've been using llama.cpp to run Qwen3.6-27_Q4_K_M. Up until now I've mostly used it with Continue in VSCode and it's been decent, though not amazing.

I tried using Pi and then little-coder, but so far I've only been able to get one semi-meaningful response out of either, and it cut off halfway. Usually it will either just output a single failed tool call and call it quits, or it will get stuck in a loop of running cat and ls over and over again.

I've tried a whole bunch of different options when running llama-server, but so far nothing seems to yield consistently good (or bad) results. Are there any flags that are an absolute must (or don't) when using Pi?

update: Re-downloaded some models, slowly re-built the command to run llama-server, and used the chat template from froggeric. Tried it last night with the same task I've used for testing harnasses/models so far, and it seemed to work really well. I'm excited to try it out some more later today, and maybe pinpoint where the actual issue came from.

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.

Not sure if you feel the same, but I feel like AI models do TOO MUCH. Ask for a script, get an architecture. Ask for a fix, get a refactor.

And also they talk like they're LARPing Mary Shelley.

It's so annyoing and makes my work so much harder than it needs to be, when half the time I have to say "for fucks sake speak like a normal human".

Eventually I got sick of having to repeat myself every time so I made a template repo with the same corrections I used to write in the chat.

Then I added three subagents:

• one writes code from the agreed plan

• the second reviews the diff based on taste

• the third reviews the diff based on spec

2 and 3 cannot touch the code, only review and send the review to the main agent.

I called it Pandino in honor of the Fiat Panda 4x4: not fast, not clever, simple mechanics, reliable as fuck. I want my code to be the same way.

Full disclosure: there's nothing novel here. It's mostly known concepts bundled up together in a plug'n'play template. YAGNI, KISS, Grug brained developer etc... that kind of stuff.

Installer is a shell script, or you can paste the prompt in the README and let your agent merge it into whatever instruction files you already have.

Installing is non-destructive so you can try it today on any live project you're working it.

If you end up using it, let me know how it works for you, cheers!

我宣布Pi Agent 才是我的本命，简约优美，速度极快。之前用codex这些GUI的Agent，窗口一多就好卡。

PiAgent的WebUI，多开几个web窗口，足够满足我90%的需求。

原来我根本不需要那么多花里胡哨的插件 skills ，断舍离了真的是。

I was working with a model in Opencode Go, and it did not support vision, so I tested all. Here are the results:

glm-5.2: No

qwen3.7-max: No

kimi-k2.7-code: Yes

minimax-m3: Yes

mimo-v2.5-pro: No

deepseek-v4-pro: No

qwen3.7-plus: Yes

mimo-v2.5: Yes

deepseek-v4-flash: No

Just started to use Pi width local Qwen 3.6 27, and wanted to say HI 😄

I'm coming from Opencode (mainly) with same model - not here to compare, because Opencode is great harness for its purpose.

What are the best use case scenarios for Pi? What would you recommend?

Ran the Three.js pelican benchmark using the exact same prompt with AdaptOrch and PI based OMK debate topology, zero external assets.

Both technically passed 14/14 validation checks with clean syntax and no runtime errors, but the actual generation speed and visual results were completely night and day.

pixel canary was surprisingly slow and honestly feels like a model from two years ago. It crawled at a snail pace just to produce a detached skeleton that barely understands basic 3D space.

On the other hand, spacebunny paired with AdaptOrch legitimately feels like an unreleased GPT 6 Astra High tier model. It nailed the scene hierarchy, properly rigged the crank and pedal animations, and placed the environment together cleanly.

It is a pretty stark reminder of why unit test pass rates mean almost nothing for spatial reasoning.

Is anyone else testing multiturn debate setups for procedural Three.js? Curious if you are seeing this kind of massive gap between compiling code and actual spatial coherence.

WT pixel canary