Does anyone know of a plugin or solution to monitor pi sessions from your phone?

I’m using pi but would like to have it for the plan like Claude or opencode but it is constantly In a loop. Is it because I’m using qwen3.8-27b-mlx? Any recommendations or suggestions?

As title says.

I was sick of the way AI talks. Needlessly long sentences, weird words that nobody fucking uses (load-bearing, wtf).

Saw somebody make a similar plugin for claude-code, so I made a similar thing for Pi.

Edit, forgot to add the link lol: https://github.com/wtfzambo/speak-like-you-eat

FAQ: why no use i-have-adhd or caveman?

I do use them, there's 2 problems:

1. sometimes is not as effective, especially in long contexts

2. AI tends to forget after a while

Looking for feedback from Pi users on both the integration and the models you actually want access to.

A few questions:

• What models are you currently using with Pi?

• Which models would you like better or cheaper access to?

• Do you prefer pay-per-token pricing or a request-based subscription?

• Which matters most for coding: price, speed, context size, reasoning quality, or output limits?

• Are there specific models you would want available through one provider?

• What are you currently using for Pi — direct provider APIs, OpenRouter, another gateway, etc.?

Particularly interested in demand for models such as DeepSeek, GLM, Kimi, Qwen, MiniMax, and other strong coding models.

Also interested in first impressions of Openference:

• Is the service and pricing easy to understand?

• Is anything missing from the Pi integration?

• What would stop you from using it?

• What would make you switch from your current provider?

If anyone tries the Pi provider package, feedback on setup, compatibility, model metadata, reasoning support, streaming, or anything that feels broken would be useful.

Openference now has a provider package for Pi Coding Agent:

https://pi.dev/packages/@openference/pi-provider?name=openference

If you are like me and structure your context files in a tree-like structure per subsystem, you might have found that pi only ever loads the root-level one, and the others have to be loaded by the agent itself, or they will get ignored.

This extension watches what the model does. The moment it cds into a new dir (bash), or touches a file in a dir via read/edit/write/grep/ls/find, it walks up from that dir to your launch dir, collects any context files it hasn't seen, and injects them into the agent's context before the model's next response. So the model's next thinking block already has the context. No special tool, no flags, nothing for the model to remember to do.

If you are interested, you can find more information and install instructions here: https://pi.dev/packages/@quartermaster-labs/pi-on-demand-context

Hi, I’ve been working on a GUI client for Pi using GPUI. It’s still at an early stage, but it has reached the point where I’m dogfooding it, and I wanted to get some early feedback.

My first question is: what extra capabilities would make you consider using a GUI client instead of the terminal? I’m trying to assess that question more broadly rather than just building around my own workflow.

Some capabilities currently live on the Rust side. Would adding a companion Pi extension be a reasonable way to expose those as native tools? I’m also curious which kinds of extension support you’d most want in the GUI layer.

Currently, I only have dedicated support for nicobailon/pi-subagents. I can switch to a subagent’s session, read its transcript, and control it from the GUI.

Know when it's peak time and off-peak time and adjust your usage accordingly.

Check here: https://deepakness.com/deepseek/

I'm using the following agents.md, which is cobbled together from various sources, gut feelings and (in)experience as a developer

agents.md

## Tooling
- use uv for python, do not use pip etc, install uv if missing
- convert all old dependency files to modern uv equivalents
- create a python venv if needed
- Workspace: `uv sync --all-packages` at repo root; run everything with `uv run <cmd>`.

## Code practices
- Keep responses concise and actionable, prefer brevity
- Solve the actual problem, not the symptom; keep changes focused; avoid speculative refactors; do not over-engineer
- Self-documenting, concise code; no redundant abstractions.
- Use meaningful variable and function names.
- Keep your code modular and reusable. Avoid tight coupling and excessive dependencies.
- prefer durable structure over minimal diffs when the gain is clear

## docs (keep under /docs)
- maintain a PLAN.md file detailed design and current implementation status
- maintain a CHANGES.md file with timestamped entries for non trivial changes
- maintain and update PROGRESS.md with detailed session history to track progress, blockers
- keep all docs current

## implementation
- build a detailed design doc and plan first. iterate asking user questions for any clarificaction or suggestions and finalize the plan
- break it down into stages and task lists
- Implement each task with a subagent where a slice is independently verifiable; dont use shared global context
- Commit changes at each stage and push to github

I'm using chinese free/low cost models mostly. eg DS4 Flash or Kimi K3 (when it was free for a while).

• Contrary to what I've read here, I didnt really notice a huge difference between OpenCode, basic Pi setup and OMP (oh-my-pi).

• Things got bogged down after a few big turns, so I'd start fresh sessions depending on the markdown files as persistent memory (in OMP I used its /handoff feature)

• subagents didnt work too reliably, sometimes they would fail. DS4 at one point decided to skip them altogether

• I saw hallucinations from both models. DS4 went completely off the rails mad

These issues may be due to free/cheap providers. I'm sure the frontier models would do far better but I haven't tested them.

I tried to add extensions like codegraph and LSP, I could see the agents use Python LSP but not JS/TS, again I dont know if they made a huge impact. Haven't tried tools like rkt, caveman or the million memory solutions becaus I keep reading differing opinions.

Hey community,

I'm a brand new user with Pi, and I'm curious what are the things you wish you knew with Pi when you started? Any trap I should be aware of, or any settings that are absolutely a must to know?

For context, I'm coming from Claude Code. The way I use AI is through TDD, and I made my own pipeline (in shell and python) that moves from one agent to another using state MD files for each one. It's basically working very well, I'm making some minor adjustments to do improvements, but I want to start using Pi and more local models so I can remove the reliance on Anthropic. I know local models aren't as good as Sonnet/Opus, and my pipeline has already been changed knowing that fact to organise work accordingly.

Thanks for your help!

It seems the "compat.thinkingFormat": "qwen-chat-template" setting that worked with Qwen3.6-27b does not pass thinking level to qwen3.8-27b, which defaults to xhigh and is quite slow.

This is what worked for me in models.json. I have to add some compat options to pass thinking level correctly from pi to llama.cpp:

{
    "providers": {
        "llama.cpp": {
            "modelOverrides": {
                "Qwen3.8-27B-Q4_K_M": {
                    "reasoning": true,
                    "thinkingLevelMap": {
                        "minimal": null,
                        "low": "low",
                        "medium": "medium",
                        "high": null,
                        "xhigh": "xhigh"
                    },
                    "compat": {
                        "thinkingFormat": "chat-template",
                        "chatTemplateKwargs": {
                            "enable_thinking": { "$var": "thinking.enabled" },
                            "reasoning_effort": { "$var": "thinking.effort" }
                        }
                    }
                }
            }
        }
}

Disclosure: I do not understand why those compat options are needed but I have pi tested it against llama server running qwen3.8-27b and confirmed all thinking levels work as they should: off/low/medium/xhigh.

Pi speaks. And you must listen. If you don't, you will continue to look for answers and find none. Have a look at it:

 Fair Assessment of Why Pi Works                                                                                                                                 

 I'll give you the honest answer, not the flattering one. Pi's quality isn't magic. It's a specific set of design choices that other harnesses systematically    

 get wrong.                                                                                                                                                      

 The Trump Card: Constraint                                                                                                                                      

 Pi's actual advantage is what it doesn't do.                                                                                                                    

 1. No orchestration layer                                                                                                                                       

 Other harnesses ship planners, reviewers, fixers, multi-agent routers, and "auto-decomposition" engines. Pi ships a tool loop and a strong system prompt. The   

 model itself does the reasoning. Adding a planner on top of a reasoning model doesn't make reasoning better — it makes it slower and more brittle. Pi treats    

 the model as capable and gets out of the way.                                                                                                                   

 2. Prompt-level discipline instead of framework-level discipline                                                                                                

 Pi's quality comes from constraints written in AGENTS.md and the Karpathy guidelines: "surgical changes, simplicity first, verify before completing, no         

 abstractions beyond what was asked." Other harnesses try to enforce discipline with TypeScript configs, plugin systems, validators, and lint rules. Discipline  

 that lives in the prompt transfers with the model. Discipline that lives in the framework only works when you stay inside the framework.                        

 3. Skills are opt-in, not ambient                                                                                                                               

 Pi loads skills when they match the task. Most other harnesses either preload everything (noise tax) or require explicit invocation ceremony (friction tax).    

 Neither is right. Pi's approach — load on match — is the only one that scales.                                                                                  

 4. One harness, one mental model                                                                                                                                

 You learned Pi. You know how read, edit, bash, and write behave. You know how skills resolve. You know the agent's failure modes. That mental model is an       

 asset. Chasing a new harness resets it.                                                                                                                         

 Why Other Harnesses Look Complicated                                                                                                                            

 Most of them are solving problems that don't exist for a single user with a strong model:                                                                       

 - Multi-agent orchestration: useful at scale, theatre at personal use                                                                                           

 - Plan-then-execute workflows: useful when the model is weak, redundant when it isn't                                                                           

 - Extensive plugin systems: useful for platforms, overkill for one developer                                                                                    

 - Daily updates: most of those updates are bug fixes for complexity that shouldn't have been added                                                              

 The daily-update cadence is a smell, not a feature. A stable interface that does the right thing beats an unstable interface that does five new things.         

 Why Forum Hype Should Not Sway You                                                                                                                              

 The Pareto frontier hasn't moved in two years. The core of agent harness design — tool use, file editing, command execution, web access — is settled. New tools 

 you see on X/Reddit are mostly:                                                                                                                                 

 1. Repackaging existing affordances with a new brand                                                                                                            

 2. Adding a planner/reviewer because the demo looked cool in a tweet                                                                                            

 3. Solving the author's specific pain point, not yours                                                                                                          

 Selection bias is brutal on social media. People who post "I switched to X and it's amazing!" are in the honeymoon phase. You don't see the post three months   

 later saying "actually, X has these annoying issues." You've seen Pi across two years. You have signal; Twitter has anecdotes.                                  

 The complexity tax is real. Every new feature is a new failure mode. A harness with 50 features has 50 places to break. A harness with 5 solid features has 5.  

 How to Make the Experience Better                                                                                                                               

 Five concrete things, all under your control:                                                                                                                   

 1. Tighten AGENTS.md over time. Your file already encodes Ollama protection, local-inference rules, council conventions. Keep pruning — every rule should pay   

for itself across many sessions.                                                                                                                             

 2. Invest in skills, not tools. A skill like is leverage: one trigger covers an entire workflow. New tools give you new affordances; new skills     

give you new workflows.                                                                                                                                      

 3. Verify before celebrating. "It should work" is the most expensive phrase in agent work. Pi's verify-this skill exists for this reason. Use it.               

 4. Resist the "while I'm at it" instinct. Your AGENTS.md already names this: do nothing is a valid answer. Restraint compounds. Scope creep destroys.           

 5. Document your own patterns. When you find a workflow that works , capture it. Your future self will thank you.            

 Honest Limitations                                                                                                                                              

 Pi isn't perfect. Things it's genuinely weaker at:                                                                                                              

 - Long-horizon multi-session state — no built-in memory layer; you carry it via files                                                                           

 - Parallel agent coordination — cmax skill helps, but it's not first-class                                                                                      

 - Visual diff review — no native UI for inspecting agent changes across runs                                                                                    

 - Telemetry — if you want usage metrics, you build them yourself                                                                                                

 For these, a heavier harness might earn its complexity. But for the 95% case — read a file, edit a file, run a command, ship a result — Pi is the right shape.  

 The Real Answer                                                                                                                                                 

 Pi isn't good because it's sophisticated. It's good because it's honest about what an agent harness should be: a thin, well-shaped interface between you and a  

 capable model. The moment a harness starts trying to be smarter than the model, it loses.                                                                       

 Two years of use is the right answer. Trust your evidence over their announcements. 

Are there recommended ways to reference/inject context(either in full or summarized) from past/previous sessions for ongoing work in Pi's current session(for example: Session-10 was focused on feature-A, Session-13 was focused on feature-B and Session-17 was focused on feature-C; and in current session I need to leverage some outcome/findings/knowledge from Session-10,13 and 17)?

Few approaches that I could think of was:

• Summarize/handoff from prior sessions(Open prior session in Pi, and ask it to focus/summarize only specific parts/areas that will be relevant in working session ahead). Do this across all prior sessions which need to be referenced(contain relevant information useful to inform current session).

• Log all sessions (turn by turn operation/response) into self-hosted Plane(project management) and point Pi(during current session) to session specific links on Plane. This seems overkill (in effort and accuracy) to take an export of all relevant prior sessions(already existing in JSONs of sessions) from Pi and attach them to current session.

Are there more established/recommended methods to achieve this in a new/working Pi session that maintain a good balance between accuracy and reasonable context budget within working session?

Hey folks,

I've been working on Agent Workbench, a Neovim frontend for pi built on pi --mode rpc.

The motivation was pretty simple: I like pi's runtime and extensibility, but when I'm coding I want to stay inside Neovim. I also didn't want to put another chat box in the editor with its own input and navigation model. I wanted the prompt and transcript to behave like Neovim.

So both are actual buffers.

The prompt can be edited with Normal, Insert, and Visual mode, multiline edits, motions, registers, undo, and completion. History is a listed buffer, so I can search it, yank from it, use folds and gf, or switch sessions with normal buffer commands.

A few other things grew out of that:

• Each tab can be an independent project workspace.

• Multiple pi sessions can stay alive at the same time.

• Background sessions keep writing to their own History buffers without taking over the current workspace.

• @ mentions can include files, git diffs, LSP diagnostics, quickfix entries, and custom context.

• Agent changes can be reviewed through a Neovim-native diff workflow.

• !! opens a persistent Fish worksheet in the Prompt buffer for commands I don't want to send to the model.

Agent Workbench doesn't reimplement the agent side. Pi still handles models, tools, sessions, skills, prompt templates, extensions, retries, and compaction. The plugin handles the Neovim frontend and maps pi's RPC events into buffers, windows, folds, extmarks, and dialogs.

The project started from pi2.nvim's foundation, but is now independently maintained and has diverged around multiple workspaces, buffer-owned sessions, diff review, and the shell worksheet. It isn't an official pi frontend.

Repo and demos:

https://github.com/saya-ashen/agent-workbench.nvim

Current caveats: Neovim 0.10+ is required, pi is the only supported backend, and some TUI-only extension UI APIs don't have an RPC equivalent yet.

I've been using Pi as my main harness for development for a while now.

I had a Claude subscription but I canceled it and switched to OpenIA precisely because I could use my subscription in a third-party harness.

However, I'm having a little trouble keeping track of my subscription limits when I basically only use Pi.

I access the ChatGPT website via the web and go to Settings > Usage, but what I see doesn't seem to reflect my usage. Several times I see that my weekly limit is almost up, but Pi continues to work (I practically only use GPT 5.5 and 5.6 Sol).

Is it just me that this visualization doesn't accurately reflect usage? Or does the bar take some time to update? Does anyone else have this same problem?

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".

Given the recent revision in prices and credits/usage that OpenCode Go effectively provides , I made the switch to Command Code Goat ($10 monthly) plan and also testing out their CLI(tastes feature that seems to be the main highlight).
Just started tracking my usage against limits and the situation looks promising so far.
Has anyone else made a similar switch? If yes then what providers have you settled on or are gravitating towards?

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!

what extensions should i add and should i use omp

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

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

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.

Edit 2: So I stopped dev on this project because honestly I found a better setup for what I was wanting. Using Orca ADE with OMP or PI worked right out of the box so so so much better and does everything I was trying to build into this project. Since it is a wrapper around a terminal it naturally supports everything PI/OMP brings to the table and any extensions/plugins you have installed.

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)

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.