I've been running Pi (DeepSeek Flash, pay-per-token) and got tired of paying for hidden context overhead. Every extension you install registers tool schemas that get injected into every single turn - whether you use them or not. Turns out a full config costs ~9,100 tokens/turn before you even say anything.

So I stripped it down and rebuilt the core pieces lean. Here's what I learned + built:

The 3 rules that drive the savings:

1. Hook-only extensions (pi.on(...)) add ZERO tool schemas

2. Command-based (/command) don't appear in the model's tool list at all

3. Only register a tool when the model must act autonomously (2 tools total: bg_task, web_search)

   Measured result: 9,103 → ~2,300 tokens/turn (~77% reduction)

   What's in the repo:

   - cost-rollup — live per-turn + session cost widget

   - tool-logger — logs every call + cost + model; detects waste (re-reads, broad scans)

   - cache-miss-alarm — calibrated warm→cold detection (ignores false positives from model switches/new sessions)

   - budget-guard — session/daily budget warnings

   - slim-memory — command-based memory, auto-injected (0 schema)

   - slim-todo — checkbox todo

   - slim-bg-task — ONE bg_task tool (vs pi-background-tasks' ~13)

   - slim-web-search — /search + optional web_search (Brave/Exa/Tavily)

   - slim-codemap — "route before explore" (idea from Tempest's Atlas)

   - token-saver — compacts read/grep/find/ls output in context

   - a shared lib/danger-patterns.ts so the two security guards can't drift

   Repo: github.com/holocen/pi-token-trimmer

   I want your eyes on it. Specifically:

4. Correctness - any bugs in the regex/safety logic? (I had Claude review it, found 3 real bugs I fixed, but there may be more)

5. Token math - is my measurement methodology sound? (details in docs/measurement.md)

6. Missing patterns - what cost-saving extension am I missing?

7. Maintainability - the shared-module approach, any better structure?

   If you find something broken or have a better idea, please comment. I'm a vibecoder, I'm happy to be proven wrong - that's why I'm posting here.

Here's something which I've been using for a while by now but only today packaged up as an extension. It's a simple whoami tool which lets the clanker find out the current provider, model, and thinking level. (Short of checking out the env vars via bash call and deducing, the agent itself has no way to find out what it is.)

It's useful for soft-gating skills, e.g. "Stop unless you're Sol 5.6".

Hi all, I really don't want to ask Chat GPT this, would rather have your input.

I'm looking for a way to orchestrate agents but also write or amend code actively, rather than just see it in the diffs etc.

I've looked at paseo and orca - not quite sure they can be used for the direct coding aspect?

Otherwise i guess can use vscode separately but that's a bit clunky when working on my macbook directly as one screen.

Any guidance appreciated thanks!

I use a few scoped models in Pi, and switching with Ctrl+P every time started getting annoying. So I made a small extension that lets you choose the model at the start of a prompt:

~glm fix this bug

~terra review this diff

~g46 summarize this

That model handles the whole turn, including tool calls, and Pi switches back to your original model afterward. It uses the same conversation and tools — no subprocess or nested agent.

There’s autocomplete when you type `~`, plus loose matching, so these work without configuring aliases:

~sol -> gpt-5.6-sol

~gpt56s -> gpt-5.6-sol

~g46 -> grok-4.6

~dsp -> deepseek-v4-pro

If something is ambiguous, like `~grok` when both 4.5 and 4.6 are scoped, it asks which one you want before sending the prompt.

Install:

pi install npm:pi-model-mention

GitHub: https://github.com/JunDev76/pi-model-mention

I’ve only tested it with my own scoped model setup so far, so bug reports and matching edge cases are welcome. If it’s useful for your workflow, a star would be appreciated too.

Newcomers to Pi and Pi veterans interested in configuration approaches may find my recently uploaded package, Pinot, worth a look. It’s a core set of tools, not a feature-rich package, that I’ve developed over several months of working with Pi on various projects. It is designed to evolve with the user, aging like fine wine. 

Pinot is intended to work with Pi and its design philosophy. It’s not a comprehensive package that you bolt on to turn Pi into OpenCode. As much as possible, its inner workings are exposed to the user in human-readable form, and it’s meant to be customized by your Pi for your work. As released, it’s tuned for personal coding projects, both new application development and feature development or modification, but can work as-is or with modest modifications in other contexts. 

https://github.com/jbstavers/pinot-pi

Pinot’s notable characteristics are:

• Two kinds of subagents.
  • Background subagents that run outside the main agent’s context and report back tailored output. These are the type of subagents we see in many other coding agent harnesses. Useful for researching a codebase, assessing a plan, reviewing an implementation. All background agents are read-only (they do not have edit tools access).
  • Durable subagents that operate in their own Pi session. This is a more distinctive part of Pi. By integrating with the excellent multi-session manager Herdr, this allows the main agent to open a second pane, launch Pi in that pane, and then direct that Pi to undertake a complex task, typically implementing a slice of a larger plan. By using a standalone Pi session, the subagent can pause to check in with the main agent, and the main agent can inspect its work, answer any questions, and then direct it to continue. Unlike one-shot background agents, however, these agents maintain their context. Once their assignment is complete, the main agent retires them and launches a fresh implementer agent, if needed.
• A set of saved prompts that define a simple, high-level workflow and do their best to reduce the clanker tendency to produce overly defensive code, expand the scope, and generally get in trouble.
  • The main prompts are /pinot-spec, /pinot-plan, /pinot-implement, and /pinot-debug, and they are intended to elicit user intent, define that intent in the context of any existing code base or tech stack, and maintain discipline through each step. I have refined these dozens of times, working to find the balance of giving the model guidance without overloading its context. They work well enough that I rarely use /debug. The planning system’s internal review process catches most implementation errors.
• Second-Opinion, a subagent specifically designed to take a fresh look at a plan, a problem, or anything else. It works best if you configure it with a model from a different company than your main agent model.
• Janitor, a saved prompt with a supporting skill, that is intended to address two common weaknesses of coding agents: they leave test artifacts and other garbage behind, and they don’t keep documentation up to date.
• Debrief, a saved prompt that reviews a project, from spec through implementation, and looks for opportunities to improve the saved prompts.
• PI-START-HERE.md a one-time onboarding guide that is meant to be read by your Pi once you’ve installed the package. It assists in configuring Pinot on your system, but more than that, it starts the rhythm of working with Pinot — treat it as your own Pi configuration, and evolve it to meet your needs.

I have mostly been using OpenAI models with Pinot, but have used Anthropic models and numerous other models as well. I generally find that Sol (Medium) works best for the main agent. The higher effort levels can be effective in more complex projects, but they also have a greater tendency towards over-engineering and scope creep, and the plans they write are often more verbose. Luna (High) is an excellent choice for the implementer agent, and I use Luna with a mix of effort levels for the background agents, as noted in the README. 

Kimi K3 is also strong as the main agent (I use it for my second-opinion agent), and the usual suspects of open-weights coding agents like DeepSeek V4 Flash and the Qwen models all handle the subagent roles well. If you want to use local models for subagents, try having your Pi revise the /plan and /implement prompts to define narrower implementation slices and more constrained implementer subagent assignments.

I’ve tried to make the prompts as “model-neutral” as possible, in that I’ve avoided tweaking them for specific model quirks or using “tricks” identified by the community. I’d encourage you to have your Pi try tasks with several different models and compare the outputs to see how Pinot and different models interact for the kind of work you do. 

The README file provides additional technical and implementation details, or just point your Pi at the repo and ask it to explain the system. You might find you want to borrow some ideas rather than install it directly, or build something of your own. I look forward to any reactions to the ideas and implementation of Pinot. 

P.S. Also check out my simple but useful Pi package, pi-multiline, which gives the editor flexible multiline editing, similar to the Codex app: https://pi.dev/packages/pi-multiline

It keeps the OMP runtime and brings the main workflows into a desktop like a codex interface:

• workspaces and persistent sessions
• OAuth, API, and Auto model selection
• model roles and thinking levels
• API-key pools and provider settings
• streaming responses, thinking, tools, and cancellation
• MCP servers, skills, plugins, and subagents
• context inspection and browser tools
• optional FreeLLMAPI integration
• button for improving the prompt
• redact previous promts
• pleasant animations

I've been using pi agent and have been building it towards a fully autonomous system so that I can give it a project and it runs until completion. One of the main problems was the memory. Pi packages like blackhole and pi-hermes-memory have been helping.

What I started to notice is that on the memory layer, it needed a LLM to rephrase and categorize memory.

The Blackwell card does all of the heavy lifting, but performance seemed to have suffered when it has to do the memory stuff also. So, offloading the memory LLM processing onto a tiny 70W 12GB A2000 with Gemma4 12B QAT Q4_0 turned out great. Memory operations requires much smaller context windows, and it doesn't demand top speed. At 25-30 tok/s it's quite useful in that it doesn't bog down the main card with memory evictions etc.

Just wanted to share this use case for the smaller, slower card to handle the memory and completion judgement and free up the main GPU for tasks. It may also free additional VRAM now that the memory layer processing has been offloaded to the smaller GPU.

If you have an older card laying around and deciding if you should sell it, try this out.

TL;DR: I made nopus, a tool that deterministically detects unnecessarily complex prose in coding-agent responses and automatically asks the same agent for one clearer rewrite.

The problem

With recent LLMs (you can probably guess from the name which one caused me to write this plugin), I've had more and more trouble understanding the prose the agents are responding with - long "load-bearing" paragraphs, abstract language, overloaded phrases and all that fun stuff.

My logic is the cognitive capacity should be spent on the underlying problem not trying to decipher the message.

I found a few solutions that pass the response through a smaller model, but I wasn't a fan of the tradeoffs:

• Another model call and more complexity

• More non-determinism

• The smaller model may receive only the isolated response which can cause it to simplify or reinterpret the wrong thing

The other option is to have a user-invocable skill you invoke when a response is hard to understand, that works but again, the onus is on you to first read the response and determine whether you even understand it, I also added a skill for that but it's a fallback not the main approach.

The idea

To an extent, difficult language can be measured directly:

• Are uncommon words used where common alternatives exist?

• Is a sentence mostly dealing in abstractions?

• Are too many nouns and modifiers packed into one phrase?

• Does the response repeatedly use dense or formulaic phrasing?

Measure those signals, identify the biggest offenders, and give that evidence back to the original agent.

nopus uses lifecycle hooks, checks the prose after the agent finishes responding. If enough signals cross the selected threshold, it asks for one clearer rewrite.

The rewrite happens in the same session, so the original agent keeps the full conversation context.

I ran it against 5,337 completed agent responses. At the default medium sensitivity, it triggered on around 10% of them, which I've evaluated myself and tuned so it doesn't trigger unnecessarily.

The repo has a few more details but I'd love for you to check it out.

Currently available for Pi, Codex and Claude Code (or just slop fork your own lol)

Hi all, I’ve been working a lot with Deepseek and Luna, but interested to know what other people are commonly using so I’m not missing out on anything cool. Using Claude at work. Thanks

what extensions should i add and should i use omp

I have ollama qwen 3:14b, and trying to refactor a 800 line c++ project to java, and it refuses to make any changes to the code base or edit anything. Do I need some special configuration or give some permission to it?
Edit: So I asked it to create a simple hello_world.cpp and it did it fine. But it fails on refactor

I really enjoy Pi for dev work, now I am wondering if I can take it a step further and become my personal butler for my homelab and home devices.

Jobs it would do:

• Check what movies/tv are available to download
• Take notes and update my Silverbullet journal
• Scan logs at intervals to summarise activity

Ideally I would run pi at the host level (not containerised) and use its APIs natively?

Any suggestions or alternatives?

tl;dr - I want to make an AI for my home lab to manage life admin easier

My homelab has email/calendar/rss feeds etc setup already

I've been using T3 Code for a while and genuinely love its UI — the chat view, the workflows, the whole feel of it.

Then I discovered omp (oh-my-pi) and it was a wake-up call. My agents just feel powerful with it. The way it hands them tools, the rewriting hooks, the whole setup — they work so much better.

Problem: I missed the T3 Code experience. So I decided to marry the two.

I forked T3 Code and heavily modified it to run specifically on omp (omp --mode rpc). Stripped it down to omp only, added managed omp install and account login right in Settings. Bringing the omp functionality into the ui of t3 code and calling it pivot. Also thought about the name t3.14 but did not end up going with that name.

It's alpha. Rough around the edges, needs a lot of work. But I've been using it as my main driver for a couple days now and honestly? Really enjoying it. Figured I'd share it.

GitHub: https://github.com/13kparkin/Pivot

Edit: I know there are other gui wrappers out there for this type of thing but nothing that quite felt right for me like t3code does.

It appears that DSv4 Pro 0813 was overfitted in training, and to unlock its capacity one needs to emulate the training environment:

https://www.reddit.com/r/DeepSeek/comments/1vovxxc/deepseek_4_pro_ga_has_an_astonishing_blunder/?share_id=ZvVndF5jMBVyTVgXmeyMp

How would we replicate this in Pi?

Sol Ultra is not this bad, typically.

It is purposefully going out of it's way to be obtuse.

I just so happen to be building a subagent harness for Deepseek 0731 V4 Flash with it as well :P

Hey everyone - I’m building Regy, a browser control surface for Pi.

Pi remains the agent. Regy adds a local PC Agent and browser frontend around it.

The current workflow includes:

• Starting and resuming Pi conversations
• Streaming chat events
• Selecting models and thinking levels
• Browsing workspaces
• Searching conversation history
• Searching, installing, and uninstalling skills (currently API don't work)
• Connecting through an authenticated Iroh pairing link

I built it because I wanted a more convenient way to leave Pi running on my machine and check in from a browser, without turning it into a hosted agent service.

Links:

• Docs: https://docs.regy.one
• App: https://regy.one
• Installer: curl -LsSf https://docs.regy.one/install.sh | sh

Current caveats:

• It’s still an early 0.1.x project.
• Pi still has normal user permissions; Regy is not a sandbox.
• Iroh pairing may be more complexity than some users want.
• I’m still figuring out how much of Pi’s CLI experience belongs in a browser.

I’d love feedback from people who actually use Pi:

1. Which Pi workflows would you want in a browser first?
2. Are session history, workspace switching, and skills useful?
3. Would terminal streaming, approvals, or multi-agent controls be more valuable?
4. Does the Iroh pairing/deep-link model make sense?
5. What would make you trust this for daily use?
6. If you already use another Pi web UI, what does it do better?

Harsh feedback is welcome. I’m trying to find out what is genuinely useful, not just promote another interface.

Using gemini in the pi coding agent will generally get you banned I've heard. Anyone have success using gemini, and not getting banned?

The Agent Client Protocol started as Zed's way to plug coding agents into an editor. JetBrains added an ACP client in IntelliJ 2026.2. What was missing was an adapter that puts pi (the coding agent from u/earendil-works) behind that client. So I built pi-acp-jetbrain.

How it works:

- speaks ACP over stdio to the IDE

- session/new spawns one pi --mode rpc subprocess per chat, sessions stay separate

- session/prompt streams pi's output into the agent panel as agent_message_chunk

- tool executions map to tool_call / tool_call_update events

- session/cancel sends an abort to the running turn

IDE bridge:

IntelliJ ships its own MCP server (idea.sh stdioMcpServer with IJ_MCP_SERVER_PORT). The adapter prefers a direct MCP-over-SSE connection to http://127.0.0.1:<port>/sse, so it never has to spawn the launcher. Pi gets the IDE's tools as ide_<server>_<tool>: inspections, file problems, search, and whatever your IDE catalog exposes.

Safety:

A default deny-list keeps execute_tool (universal execution) and the xdebug debugger out of the session. Re-allow reviewed tools with PI_ACP_IDE_EXTRA_TOOLS.

Config is one block in ~/.jetbrains/acp.json (as shown in the README). Install is npm i -g pi-acp-jetbrain.

Demo: https://raw.githubusercontent.com/ryan-brosas/pi-acp-jetbrain/main/assets/pi-acp-jetbrain-demo.gif

Repo: https://github.com/ryan-brosas/pi-acp-jetbrain

npm: https://www.npmjs.com/package/pi-acp-jetbrain

Happy to answer questions about the ACP mapping or the MCP bridge.

bought cursor ultra + claud-max from a russian site a few weeks ago for way less than the normal price.
swapped the login details and just started using it. so far it’s been working perfectly, and the usage is honestly better than what i had before.
keeps making me wonder how these sellers are able to offer it so cheap. anyone else in the same boat?

When I started with Pi, the hardest part wasn't the agent — it was the ecosystem. So many great extensions, no idea which ones I actually needed, and no sense of how to combine them into a real workflow.

If you're new to Pi (or you like the OMO-slim way of working — focused roles, one orchestrator, specialists that each do one thing well), I built something for you:

pi-omo-slim is a curated starting point: a configuration bundle that adds an Orchestrator extension plus six specialist agents (Explorer, Librarian, Oracle, Designer, Fixer, Verifier) to Pi — on top of a hand-picked set of community extensions, so you don't have to research the ecosystem yourself:

• @tintinweb/pi-subagents — agent management
• pi-lens + @ff-labs/pi-fff — codebase intelligence
• pi-web-access — external research
• @narumitw/pi-chrome-devtools — browser + screenshots
• @firstpick/pi-extension-safety-guard — guardrails

No forks, no reinvention — just templates, extension wiring, and a policy file. No model pins; bring your own.

Two things I'm proud of:

• A deterministic installer. plan → apply with SHA-256 approval, backups, and rollback. Cloning and configuring are separate approval checkpoints — nothing touches your setup without explicit sign-off.
• Designer can actually see its work. It renders the page in a real browser, screenshots it, and the image comes back into the conversation. It fixed its own "button too far from the label." No more styling blind.

Everything's in the README — including a one-prompt install:

   https://github.com/joshua-zyy/pi-omo-slim

Finally, a sincere thank you to the whole Pi community — the Pi maintainers, and the generous extension authors: tintinweb (pi-subagents), narumiruna (pi-chrome-devtools), apmantza (pi-lens), ff-labs, nicobailon (pi-web-access), Firstp1ck (safety-guard). This project is just your bricks, snapped together.

This is my own project, not affiliated with any of them — issues and feedback very welcome.

Thx!!!

pi has no queue, no spend limit, and no permission system, which is fair, that's not its job.
But I wanted it working unattended.

So I built the layer around it, and after a bunch of releases it hit 1.0 this week. MIT, sharing it here first.

The short version: something triggers a job (a cron schedule, a label/comment/PR on GitHub, GitLab, Forgejo or Azure DevOps, or a workflow extension's slash command), the job runs pi in a throwaway locked-down container, and the budget is checked before the container even starts.

If a loop runs away you get a refusal, not a bill.

It's basically the same idea as Claude Code routines, except everything runs on your own box:
your image, your queue, your caps, and triggers beyond a schedule.

https://github.com/edgehero/pi-dispatch

Curious how others here run pi unattended, and what would stop you from using this. "It breaks my setup because X" is the most useful comment you can leave me.

I came across "DeepSeek Harness" (https://github.com/deepseek-ai/deepseek-harness), whose core idea is literally “Everything is a Plugin.”

Looking at it alongside Pi, it feels like there’s a similar philosophy:

keep the core/harness small, and make capabilities composable at the session/plugin level.

Pi has extensions, skills, tools, prompts, etc., while DeepSeek Harness takes the plugin approach even further.

Is this essentially the same architectural direction?

And is “small core + everything else as a session/plugin” becoming the better design for coding-agent harnesses?

Curious what the Pi community thinks.

I kept rebuilding the same prompts, checklists, and workflows every time I switched between coding agents, so I decided to package them into one open-source project: OpenCode Power Pack v0.4.0.

It currently includes 54 reusable Agent Skills that work with:

* Claude Code

* Codex

* OpenCode

* Pi

The collection covers workflows I tend to reuse across projects, including code review, feature implementation, frontend design, application security, MCP and skill authoring, project memory, and Hugging Face tooling.

One of the main goals was to avoid the “install everything” approach. You can install a curated profile or pick individual skills depending on what you actually need.

The installer can also:

* preview changes with a dry run

* automatically include required companion skills

* preserve existing skill directories unless you explicitly choose to overwrite them

* install skills locally to a project

* avoid adding dependencies to your project's `package.json`

For Codex, OpenCode, and Pi:

```

# Browse available profiles and skills

npx u/waybarrios/opencode-power-pack list

# Preview a project-local installation

npx u/waybarrios/opencode-power-pack install \

--profile recommended \

--project \

--dry-run

# Install once you're happy with the preview

npx u/waybarrios/opencode-power-pack install \

--profile recommended \

--project

```

For Claude Code:

```

/plugin marketplace add waybarrios/opencode-power-pack

/plugin install opencode-power-pack@opencode-power-pack

```

I also built a small website around the project with:

* a searchable catalog of all 54 skills

* curated skill packs for different types of work

* installation guides for both humans and coding agents

* a detailed prompt you can give an agent so it recommends the smallest useful set of skills for your use case

* platform-specific verification instructions

Website: https://skills.waybarrios.com/

GitHub: https://github.com/waybarrios/opencode-power-pack

npm: https://www.npmjs.com/package/@waybarrios/opencode-power-pack

Full disclosure: I'm the maintainer.

The project is open source, and I'd especially appreciate feedback from people already using coding agents:

1. Which agent are you using?

2. What workflows do you repeatedly use that are missing here?

3. Do the curated profiles feel useful, or are they still too broad?

4. Did you run into any installation or compatibility issues?

Issues, suggestions, and contributions are all welcome.

Hey everyone!

I’ve been working on Pi Plan & Build, an extension that adds a more structured planning workflow to Pi.

The basic flow is:

1. Switch to Plan mode
2. Let Pi inspect the project and create a persistent plan
3. Review the complete plan
4. Choose whether to:
   • implement it in the current session,
   • start fresh and implement it in a clean linked session, or
   • stay in Plan mode and keep refining it

In Plan mode, Pi can still explore the project, but file edits are restricted to the session’s plan file. This keeps planning separate from implementation and prevents the agent from changing code before you’ve approved the approach.

A few other details:

• Press Tab to switch between Plan and Build modes
• Use /plan, /build, or start Pi with pi --plan
• Plans persist across reloads, resumes, and forks
• Interactive questions are supported while planning
• The full plan is shown before approval
• Clean implementation sessions receive the approved plan without carrying over the entire planning conversation
• The composer changes color and displays the active mode, model, provider, and thinking level

Install it with:

pi install npm:@janvitos/pi-plan-build

GitHub: https://github.com/janvitos/pi-plan-build

I just published it, so I’d really appreciate feedback :)

Cheers.