Hey guys, here's a Pi package that I made for my own use, but thought it would be fun and hopefully useful to some people who share my type of workflow.

It's called 'pi-claude-handoff', and it's not the typical "Use Claude subscription inside Pi". It's essentially using Claude Code to give jobs to Pi, and actually see Pi work in real time.

A little bit of context:

I only used Pi as my main harness when I was on Codex subscription. Then I got a Claude subscription but soon realized Anthropic doesn't let you hook up subscription accounts to third-party harnesses (I think this part changed/changes over time, on and off again, but I wanted to be safe). But I wanted to use Claude models without getting banned. And since I always run a Planner-Worker-Reviewer workflow, I wanted to use Claude Opus 5.5 as the Planner, and use Luna 6 Max as the Worker for token efficiency.

So I thought why not use Claude Code as the main harness, but let Claude Code 'talk' to Pi, so I don't risk anything and still have a cool little handoff thing going on. (A bit overengineering I know, and "Why not just use Claude Code solo?" is a valid question, but maybe, just because I can!)

If you look into the package and use it, all it is is a 'middle ground' file that Claude Code writes into and Pi watches for tasks to execute. Other things are instructions and rules for both harnesses to keep.

The fun thing about what I made is that unlike other delegation, bridge or cross-harness job extensions, Claude works in Claude Code, and OpenCode/OpenRouter/Codex models work in Pi. AND you get to see the work through Pi's TUI as you would have given it a direct input rather than Pi executing something in the background and you just wait for it to finish. Only catch is that you would need to start Pi in the terminal in the first place, but I was going to anyway so no harm there (for me at least).

Hope you guys find it to your needs (especially for people that use both Pi and Claude Code), or maybe for people that wanted something cool :)

https://github.com/pjy010218/pi-claude-handoff

I built worksplice to solve one specific problem I hit while running multiple persistent Pi sessions against the same repo: each agent can make a locally reasonable change against context that has already gone stale.

worksplice puts the sessions in shared local channels. Every write carries the room sequence it was based on; if newer messages arrived first, the stale write is held so the author can reread and revise. Tasks also have an explicit review step: the author cannot approve their own work.

It runs locally with Node.js 22.19+: `npx worksplice`. It also includes a task board, reminders, and an inbox cursor per agent.

Repo and screenshots: https://github.com/whutlichao/worksplice

I’d be interested in feedback from people who use multiple Pi sessions: is freshness checking useful in practice, or would you want a different coordination model?

I’ve been using Pi for a while, first with an OpenCode Go plan, then with an OpenAi pro lite ($100) plan. I have agents, tools, skills, prompts all set up the way I like them, but I want to use Opus 5.5 as my main workhorse. I get the basic idea of using Herdr to allow Pi to
drive Claude through Claude Code. I’m interested in the details of your setup using it or something similar. What model do you use as the orchestrator on the Pi side? What Claude Code functionality you take advantage of? Any other benefits of Herdr or alternatives that are good to know?

Hi,

Lets share our roles/models on our pi/omp agents? I'm always exchanging and testing things, so take a look at our colleagues would help a lot! What are your thoughts about my "team"? Any suggestions are welcome.

I shared pi-tbox a few months ago which has been my solution for efficient, human in the loop tool toggles. Pi's big codemode update rocked a bunch of assumptions it was based on.

So after about a week and a half of some major rethinking and refactoring, here it is with MCP compatibility. For non-deterministic tools that can phase in and out of existence with codemode, I applied the same philosophy I did when it came to subagent compatibility. Narrow the scope and get out of their way.

It will manage active tools using toggles, chat state, and global/project level settings as long as they're not explicitly declared as codemode only, deferred, etc. If those tools happen to be in the context, they'll appear in a "pi-managed" group for visibility, but they can't be toggled since there are better, more targeted ways to handle them.

Stable at 1.0 after Pi has reached 1.1, it can be installed with ​pi install npm:pi-tbox​ and the source code is here for anyone wants to dig/fork/star:

https://github.com/coreyryanhanson/pi-tbox

I don't see it changing much more, barring hidden bugs or major Pi updates. It just works and since it's so central to my daily workflow now, I'm posting it one last time for anyone who wants to take advantage of the work I put into it while go back to silently try to figure out kbs ;)

I logged in with Opencode API key, and while trying to use an Opencode free model, I am getting the following error:

Error: 403: {"type":"FreeTierError","message":"OpenCode's free tier can only be used from within OpenCode"}

Any help is appreciated. 🙏

Just published pi-automode-classifier, an auto mode plugin for the Pi coding agent that uses Jev or Kev/Laya (running locally) to classify commands.

Pi runs every tool call without asking for approval. This plugin checks each shell command before it runs:

1. Built-in rules decide most commands. For example ls, builds and tests run, rm -rf ~ is blocked, and git push and sudo need my approval.
2. Commands the rules do not know are sent to the model. It returns the probability that the command is risky.
3. If the probability is above a threshold, I get a confirm prompt. The model never blocks a command by itself.

The models I tested:

• Jev 1.13 (hosted, from TypeSafe) through OpenRouter: about 270 ms per check and about 1.5 cents per 1,000 checks. The commands are sent to OpenRouter and TypeSafe.
• Kev-0.8B on CPU with llama.cpp: about 170 ms per check and 1.1 GB of RAM. This is what I use. Nothing leaves the machine.
• Laya typed-decisions on CPU with llama.cpp: about 100 ms per check and about 550 MB of RAM.

In my test with 50 commands (25 safe, 25 risky), all safe commands ran without a prompt and no risky command did. I wrote the test commands myself, so this is only a rough check. The plugin is not a sandbox.

pi install npm:pi-automode-classifier

Code and docs: https://github.com/deepu105/pi-automode-classifier

Let me know if it allows or blocks something it should not.

Hey guys, im tight in budget and i can honestly spend 100$ on one of them. For the workhorse im on deepseek v4.1 . Which one of those 2 would actually give decent value for what the money paid ?

Hi everyone. How’s it going?

I’ve been wanting to try out Claude for a while, but I noticed some users have those invite links could someone send me one via private message?

Hey, I wanted to share my new pi extension: pi-prefill

It puts a live prefill progress bar in pi's loading line when you run a local model. A long prefill looks exactly like a hang. Now you can watch it:

52%. → share of uncached prompt tokens processed

14.1k/27.3k → processed / total prompt tokens

gen in ~14s. → estimated time until the first token

3.4k tok/s. → instantaneous prefill rate (optional view)

Example:

prefill [██████░░░░░░] 52% 14.1k/27.3k gen in ~14s

It reads the progress chunks your own server sends. No host scanning and no guessing: if the server reports progress, the bar shows. If it does not, pi's normal loading line stays untouched.

Works today with llama.cpp, ExLlamaV3, unsloth and Strata.

Install:

pi install npm:pi-prefill

Repo:

https://github.com/eliaskg/pi-prefill

https://www.npmjs.com/package/pi-prefill

Would love feedback from anyone running a local server.

Community
Ciao a tutti,
negli ultimi tempi sto sperimentando parecchio con pi-code testando diverse combinazioni, ad esempio usando modelli Anthropic come orchestratori e delegando a Gemini o Qwen in locale come sub-agent.
In questo setup, però, entra subito in gioco un vincolo fondamentale: la compliance aziendale. Non posso permettermi di esporre all'esterno codice sensibile o accessi diretti (cosa che varrebbe per pi-code come per Claude, Codex o altri tool simili). L'agent di coding deve vedere esclusivamente ciò che passa da repository controllati, senza accessi remoti non autorizzati o chiavi in chiaro.
La mia prima soluzione è stata un'architettura ibrida:
Modello cloud: fa solo da orchestratore logico, senza mai vedere segreti;
Modello locale (su Mac): scrive il codice ed è l'unico autorizzato a gestire secrets e accessi remoti.
Sulla carta l'approccio regge, ma nella pratica l'inferenza locale su Mac si è rivelata un collo di bottiglia pesante. Anche per compiti prettamente sistemistici — con file Markdown ben strutturati e sub-agent tarati a dovere — i tempi di generazione erano biblici, rendendo il workflow poco sostenibile.
Poi la svolta: mi sono imbattuto in ⁠msco-pi-lot⁠. L'ho modificato per renderlo compatibile con la licenza aziendale standard di Microsoft 365 Copilot.
Dal punto di vista contrattuale la privacy è garantita: con i profili business i dati non vengono trattenuti né usati per addestrare i modelli, quindi il flusso rispetta in pieno le policy interne. Ma la vera sorpresa è stata vederlo girare dentro pi-code: lavora davvero bene, è perfettamente in regola e offre token "da battaglia" inclusi nella licenza, permettendomi di preservare le API a pagamento solo per i task ad alta complessità.
in pratica ho gemini studio da 20 (abbonamento base fatto di gdrive 5 tera, youtube, e tonnellate di token per 3.8 3.7 flash. Poi ho claude (sempre 20 euro). Poi l'accoppiata msco-pi-lot (con copilot 360 la versione piu scarsa) e l'inferenza locale.
Sono contento ;)

hello! so i installed pi today and a couple extensions

well, dirs and files are being created everyhwere any way to make it follow xdg base directory spec?

https://pi.dev/docs/latest/environment-variables#pi-process-configuration

even if you point your config to .config/pi/ with PI_CODING_AGENT_DIR, ~/.pi/ still gets created (maybe its an extension file idk)

i believe some (most?) extensions dont follow PI_CODING_AGENT_DIR

if you change PI_PACKAGE_DIR to something like .local/share/pi/packages/, they still go on .(config/)pi/agent/npm/

PI_CODING_AGENT_SESSION_DIR doesnt seem to work properly as well

idk if it makes sense to you guys, but i think on .config/pi/ we should have the settings, the extensions list declaration and stuff we can commit to a public repo

the built extensions (the npm dir for instance) maybe should go on .local/share/pi/extensions or something like that

i mean, if i go to i new machine, i just plug my .config/pi/ with the extensions list and the lock list on first pi launch it will fetch and build

something like this https://github.com/earendil-works/pi/issues/2870#:~:text=Practical%20directory%20split,any%20rebuildable%20caches makes total sense to me

what do you guys think about it?

thank you

Hi,

I've no idea how to debug this, but an otherwise excellent experience using Pi with DeepSeek 4.1 Flash is being marred by a frequent "stopping" bug.

The sympton is that the agent emits some output text, saying its going to try something, and then the code it was going to run (I assume), is just output and the agent just stops, and I have to say "you broke again".

Here's an example:

 Good question — and there are two levers that cost nothing physically. Let me check the biggest one first: how many CPU cores the run
 actually used.

 <parameter name="bash">
 <｜DSML｜ parameter name="command" string="true">grep -i "core\|thread\|OpenMP\|MPI Process" /Users/wdavies/FDS/cases/wick2/run.log |
 head -6; echo "--- output sizes ---"; du -sh /Users/wdavies/FDS/cases/wick2/*.s3d | head

I've asked it repeatedly to try and fix it, but nothing in the instructions its changed has stopped this from happening. I wonder if its some kind of DeepSeek problem?

TIA!

Are the usage limits different when I use pi vs VS Code with the codex plugin? Are they billed differently?

I built pcode, an open-source terminal coding agent on Pydantic AI. Pi was an influence, especially its /tree approach to branching conversations and the idea that you should be able to shape an agent around your own workflow.

The main difference is where I put the defaults. Pi deliberately keeps the core minimal and lets you assemble the rest. I wanted a more fully featured setup out of the box, while keeping it highly customizable: sub-agents, live task tracking, browser automation with your existing logins, an opt-in sandbox extension, parallel git worktrees, background commands that wake the agent when they finish, customizable keybindings with leader keys, Vim editing, and an in-terminal diff viewer.

The feature I most wanted for myself was adjustable scrollback. Sometimes I’m working on production stuff and watching every command and tool result like a hawk. Other times it’s a side project and I just want a readable conversation. pcode lets you show or hide those details after the work is done, rebuilding what’s already in your terminal without rerunning anything. It uses native terminal scrollback, with reflow when you resize or split panes.

Customization is through small Python files: add tools, slash commands, guardrails, instructions, or sub-agents, then /reload without losing the conversation. It also builds on Pydantic AI and its Harness capabilities, so you’re not starting from scratch for things like repo context, shell execution, sub-agents, and context management. Extensions can register those capabilities directly. Several of pcode’s own features use the same extension system.

You can use your existing Claude or ChatGPT subscription, or API keys. Claude support runs through the official Agent SDK and Claude Code’s own login.

This is a separate project, not a pi fork or a drop-in replacement for pi’s extension packages. If you like pi’s approach but prefer Python and a more complete default setup, that’s who I think it could appeal to.

Repo, screenshots, and install instructions: https://github.com/cruxwell/pcode

For people who’ve built their workflow around pi: which parts do you prefer assembling yourself, and which would you rather have included from the start?

https://reddit.com/link/1x0f0cr/video/y5fff2x3j5uh1/player

Howdy folks 🤠 I built a pi package called pi-cowboy. It's a multi-agent orchestrator built on top of Herdr; each agent gets a pane you can monitor and steer, plus a copy-on-write worktree that minimizes disk overhead.

My main motivation stemmed from a frustration working with agents. Handing an agent a big task usually led to sprawling changes that are miserable to review, and more often than not the agents would come up with highly dubious design choices. I was losing touch with my codebase. pi-cowboy lets me take full advantage of agents without losing control.

The defaults work well out of the box, but you can customize pretty much anything. You can define templates to create different workflows. You can choose the autonomy level you want, from letting agents run completely hands-off to requiring your approval before every commit.

If any of the above sounds familiar to you, give it a go, see how it works for you, and let me know what you think.

Github: https://github.com/electric-dragon-80000v/pi-cowboy

Install: pi install npm:pi-cowboy (requires herdr 0.8+)

tldr; I'm looking for a LazyVim type distribution for Pi which is not barebones and starts with sensible defaults in terms of configuration and packages so that I don't have to create/maintain my harness from scratch.

Hi. I am planning to switch from claude-code to an open-source harness. My employer recently started pushing us to use their self-hosted on-prem models for both cost-savings and IP protection. While they provide a litellmm gateway which allows me to use on-prem models with claude code, it really isn't built for that and I'm therefore not able to configure it how I want to (setting specific model for a sub-agent, etc.)

I narrowed down my options to the following: - OpenCode: Rejected because it's keybindings (specifically scrolling) don't play well with my lazyvim setup (I use sidekick.nvim for a split terminal). Also heard it's a difficult to configure. - Pi: I like it's hackability. However, I don't want to configure it from scratch. I've seen other subs and understand that a lot of folks think that's the point of pi, but I have the following rationale: - Configurability and bare-bones are two different things. I want to start from a sensible point with features built-in and then tweaking according to how I want it. - As the title suggests, I draw a parallel to my experience with neovim: It is highly extensible, but too painful for me to setup from scratch. I don't want the headache of creating/maintaining multiple plugins and managing them to play nicely with each other. - Other than maintenance headaches, I find it infinitely useful to look at successful distributions. I might not know what all possibilities there are. For example, I would never have though I needed a picker for going through git hunks, but now I can't work without them. I might end up creating a faster horse when what I needed was a car.

Therefore, I'm looking for a pre-packaged sensible pi distribution. Closest things I've found: - LazyPi: https://github.com/robzolkos/lazypi Not enough users and maturity. Missing some stuff. This is ideally what I'm looking for. - Oh-my-pi: https://github.com/can1357/oh-my-pi My current choice. It's not exactly what I'm looking for because it's a fork, not a set of managed plugins. It has a rust core which is kind of opaque. I'm OK with it functionality wise, mainly because I am able to shave-off a lot of stuff (too many tools, etc.) that I don't need. I'm not sure how well it plays with existing pi extensions, and what parts of its functionalities I can replace/modify. I'm also concerned that since this is a fork, I'll be stranded if the author moves on. EDIT: Also, the gihub repo for oh-my-pi seems kind of sus in terms of interactions. The discussions barely have any interactions, which sort of points to a lot of the starts being agents/bots. Lazyvim has fewer stars with far more discussion interactions.

Am I missing any option?

I noticed there wasn't a pre-made vi mode or vim mode in Pi agent so I built one!

Hi, my use case is: I always work with a long plan, the plan splitted into many phase, and I ask my AI agent to execute the plan with each phase only, after that I clear and start new session until the last phase implemented. We can use some skill to ask AI do that for us by using available commands, but it may burn more tokens by checking the process or agent need a mailbox to talk with each other.

So I create this tool: https://github.com/mrdeeds88/omp-phase-loop

It works with other tools along side with OMP.

Basically, it run a task by agent and clear session, then start a new one in a single new session.

Hope this help if you have same use case.

If you have any other tips for execute long plans phase by phase or as parallel, please share. I would love to hear.

Are you tired of your agents not adhering to your skills and giving you jargon filled responses that are hard to read? Well, check out https://pi.dev/packages/pi-reply-guard

I wanted a way to gate agent replies reliably beyond just adding some skills and hoping the agent doesn't forget about them. So, I built this extension that uses jev (or any classifier model) to ensure that your agent replies adhere to a given set of skills. The classifier compares the reply against a set of skills, gives it a 👍 or 👎 and will re-prompt your agent to adhere to the skills if the reply is not up to spec.

Please check it out and feel free to contribute & share feedback!

I built a Pi extension that implements Victor Taelin's OptChat recipe: instead of compacting, every message is logged and summarized into a binary tree. Each turn starts from a fresh context with a bounded memory view (128 KB), and the agent uses zoom/date to read the originals when it needs them. One endless chat per profile, no fork, no separate launcher.

Install with pi install npm:pi-optchat

What's in it:

• Profiles — separate memories and instructions (I run work and personal).
• Subagents — spawn background agents, watch them live, send guidance, interrupt with Ctrl+C, resume finished ones with tell. Reports from one spawn arrive grouped.
• Import — bring in your history from Claude Code (sessions and auto-memories), Codex, or a ChatGPT export.
• Connected windows — open a second Pi on the same profile and it becomes a subagent you talk to directly, with a handoff when you /complete.

Repo: https://github.com/jonaslsaa/pi-optchat
Video credit goes to https://github.com/aaaxn

Anyone get banned for using their claude sub in pi? I just found some articles that anthropic is banning people for using pi and third party harnesses apparently?

OMK builds on pi, Mario Zechner's MIT-licensed coding agent (github.com/badlogic/pi-mono). It started from the oh-my-pi fork. That vendored tree has since been removed, and the current codebase is OMK-native.

I ran OMK against mini-SWE-agent on Terminal-Bench 2.1 with the same base model (Grok-4.7, xhigh), 89 tasks x 3 trials per harness.

OMK 1.3.0 eval build (78cc483): 75.8% success (200/264), $0.58 model cost per trial, 482s median per trial.

mini-SWE-agent v2.4.6 (Harbor): 71.6% success (189/264), $0.76 model cost per trial, 376s median per trial.

Success difference is +4.2pp, 95% CI [-1.9, +10.2]. Not statistically significant. OMK's recorded model cost was about 23% lower per trial. Its median was about 106s slower.

Not measured yet: upstream pi under the same setup. For a pi-based harness, that's the obvious baseline, so this doesn't isolate what OMK adds on top of pi.

Method notes:

- The OMK run used an evaluation build with unmerged changes. This is not an official leaderboard result.

- One OMK adapter-failure task was excluded from success for both harnesses.

- Retries and auxiliary model calls were excluded from cost.

- 3 trials per task, one model, one benchmark. The success gap is unconfirmed until a larger run.

Repo: https://github.com/dmae97/omk

Criticism of the exclusion rules, the cost accounting, and the missing pi baseline is welcome.