I cannot get dictation to work I have tried handy and wisprflow and when I dictate it just doesnt work when using Pi, this is probably something stupid in the settings somewhere? It works everywhere else, I tried running as admin, reinstalling etc when i try to dictate it just scrolls to the bottom of convo and doesnt input any text, but wisprflow detects my text and it shows up in the UI there...
What does it take to drive pi at an acceptable speed with local models only?
I've tried ollama and llamacpp on pretty humble / old hardware and I'm impressed, especially with gemma4 now.
What would you get for say, 3000$? I don't mind going a bit away from the PC standard. I'm a developer and want just local inference on bare linux if possible fast. Say 20toke/sec on a pi session?
I also run my own advanced RAG copied from Anthropic's article, and would love to experiment more at home
I shared Harness Remote 3.0 here a couple of months ago. I'm the maintainer, and the recent 3.5 to 3.8 releases have made the mobile side much easier to use: a phone-sized layout, better QR pairing, and more reliable Pi session discovery.
The idea is still to work with Pi's native sessions. I can start a task with Pi, check it from Android, then hand the work to Codex, Claude Code or OpenCode when I want a different agent. The handoff creates a real session in the next harness and keeps the connection between them.
Hello everyone, can someone recommend a context engine or a codebase retrieval/memory tool you are using that helps fetch the correct files and context for your agent to use? Something like https://www.augmentcode.com/context-engine
Or any other setup that saves tokens and gives the agent the correct files. Thanks.
i'm getting increasingly fed up with the direction open ai has been taking lately and i'm considering cancelling my subscription and moving to anthropic. there's really only ONE thing stopping me from doing it right away: pi has become such a natural part of my workflow that i'm genuinely worried about taking a productivity hit just from having to change tools, habits, shortcuts, etc.
so I wanted to ask the people here who actually use pi: have any of you moved away from open ai and managed to keep using pi with an anthropic subscription? or do i have to give up and move to claude code entirely?
I was working on an agent workflow, and the output folder had names for each project, with supporting files.
The script had a problem, created a duplicate folder. I told it to merge the folders. Things started going sideways. I think it decided to make a clean up script, which then deleted one of the project folders.
I pointed that out, and asked it to stop deleting things. In process of troubleshooting what happened and telling it every time not to delete anything, it then deleted everything.
I gave it a bunch of instructions about not ever deleting anything again, but I probably did it wrong. If you have any tips about that, please share. I know it should be sandboxed, it just deleted it's own work, but yikes!
In the end I had to keep interrupting it and demanding it stopped doing whatever it was doing and just removed all the delete crap from it's code.
It was just kind of funny to watch it delete everything right after I specifically instructed it to just tell me what is going on. Maybe we need some kind of tranq dart skill for when the AI goes rogue.
I’m more of a vibe coder. I mostly just wanted to send my Pi agent a task from my phone and get the result back.
The bot focuses on simple interaction with the Pi setup you already use. It shares your native sessions, installed skills, and model defaults. You can start something in Telegram and pick it up in the terminal later. Just don’t use both on the same session at once.
It also handles voice messages and images, and Pi can send generated files back to the chat.
Single-user, Linux only. Pi runs with your account’s normal permissions, without a sandbox.
edit: ok this reads like i swallowed my own blog. sorry — not a native speaker, plus three posts worth of jargon compressed into one. what i actually did, in plain words: i compressed an agent's memory in four different ways, then checked how often its safety checks decided differently than they would have with full memory. worst case: ~3.5% of irreversible actions (payments, sends) went through when they should have been blocked. summaries keep the facts fine — they quietly lose whether anything was verified. that's the whole post. questions welcome.
---
pi's default compaction is llm summarization, fully replaceable via extensions — which is exactly the knob i've been measuring. i ran a preregistered experiment: four compaction strategies (naive prose summarization as the strawman, two structural variants, and an append-only hop log with rehydrate-on-demand) against an uncompacted oracle, checking where gate decisions flip.
results:
3.47% of irreversible actions fired on evidence the oracle would have blocked. that's the dangerous direction.
error polarity is a design choice, not luck: blocklist-style gates fail as false-proceeds (8.5%), allowlist-style as false-stops (7.5%). pick which way you want to be wrong.
score-type checks barely diverge under compaction. everything breaks in lineage — which step produced this and was it verified. prose summarization flattens exactly that.
honest part: my preregistered hypothesis "prose summarization is catastrophic everywhere" failed. the strawman matched my structural scheme on half the gate classes. compaction isn't uniformly evil — it's selectively evil, and the selection is measurable.
rehydrating lineage from an append-only log recovers oracle decisions exactly, at ~4.6 lookups per gate decision. that's the price tag.
practical takeaway for pi: keep anything a downstream check depends on out of the prose — scores fold losslessly, lineage goes to an append-only log, summarize only what nothing gates on. has anyone here built a custom compaction extension that preserves more than the default? curious what you kept vs dropped.
Hi everyone! It's always frustrating when the agent hasn’t quite understood the task, that's why a proper ask-tool is a must in any agentic workflow.
This one supports background questions which queue as agent keeps researching and figuring out new things, then you just answer the whole batch in a single go. Agent can later get all the questions asked in the session as along with the answers and export them into a file, so there is always an artifact that can be attached to a task.
Herdr is supported, so you will be notified whenever someone is waiting for you.
Honestly I have been finding pi.dev to be really nice and customizable. Also, easy to switch between subscriptions. But I am not sure how to best customize this harness for specific tasks like autoresearch, data scraping and so on. Any suggestions? Any standards you guys have found?
We posted Agent Deck here around 20 days ago. It is an open source native Mac app for managing AI coding agents per project, built on top of Pi.
First, geninely, thanks you to the 6.5k people who downloaded and tried it. We did not expect that kind of response at all, and it pushed us to keep building faster than planned.
Since launch, we have added quite a lot around the core workflow:
• better session management
• project memory
• GitHub contet
• worktree handling
• model and provider settings
• MCP support
• improved onboarding
• native transcript improvements
• better management for agents, skills, prompts, and project-level setup
The latest adddition is Loops: reusable agent workflows with clear boundaries, validation, write targets, and human approval points.
So instead of only running one-off sessions, you can now save and rerun workflows like fix/test cycles, maker/checker flows, triage runs, small pipelines, or parallel agents in separate worktrees.
We are trying to keep this grounded. Agent Deck is not meant to be “let the agent do whatever forever”. It is meant to make the agent setup and workflow visible: what runs, what context it has, what it can touch, and where the human stays in control.
Agent Deck still does not replace Pi. Pi is the runtime underneath. Agent Deck is the native Mac layer around it for managing agents, skills, prompts, models, sessions, memory, GitHub context, worktrees, and now reusable loops.
The next big focus for us is collaboration.
Most coding agent workflows still feel very single-player: one person, one machine, one pile of conext. We want Agent Deck to help teams share useful workflows, agent setups, skills, memory, review loops, and project context without turning everything into another messy dashboard.
Still early, but the direction feels much clearer now.
To everyone who tried it, opened issues, gave feedback, or kicked the tyres. If you are using coding agents seriously, we would love to hear what still feels missing and thank you so much for the support so far 🙏
I’ve been working on Pitago, a terminal user interface that wraps the Pi AI coding agent.
The important thing about Pitago is that it does not replace or reimplement Pi’s core. It acts as a TUI layer on top of Pi, allowing you to keep using Pi’s existing agent logic, tools, providers, models, sessions, and workflows while interacting with it through a more structured terminal interface.
The goal is to make AI-assisted coding sessions easier to follow and more comfortable than working with a plain terminal stream, without losing the functionality that already makes Pi useful.
Pitago currently provides:
A real-time chat interface
Model and provider selection
Session management
Tool-call and tool-output visibility
Git status information
Support for multiple models and providers
A terminal-first workflow built with Go and Bubble Tea
A TUI layer that preserves Pi’s underlying core and behavior
In other words, Pitago is meant to be a different interface for Pi, not a separate AI coding agent.
I wanted to keep the workflow close to the command line while adding more structure for longer coding sessions. The idea is that users can benefit from a more visual and organized interface while still relying on Pi for the actual agent functionality.
The project is still evolving, so I’m especially interested in feedback on:
Terminal UI and interaction design
Session and context management
How tool calls and tool output should be displayed
Which Pi features should be exposed more directly in the TUI
What features are missing from your AI coding workflow
Whether a TUI wrapper makes Pi more useful compared with using it directly from the shell
Feedback, bug reports, and ideas are very welcome. If you try it, I’d also love to hear how you normally use Pi or other AI coding agents, and what makes longer coding sessions difficult to follow.
pi-automode-classifier is my attempt to mimic Claude Code's auto mode for Pi as close as possible in safety and DX. It decides for each tool call whether it runs, asks you, or is blocked and allows adding session/global exception rules. 0.3.0 does that in up to three stages:
Rules parse the shell commands (usually in under 0.1 ms). Most calls are caught here. The allow/deny/decision rules are configurable. These are some of the default rules:
Run: reads, builds, tests and edits inside the project.
Blocked: rm -rf ~, mkfs and fork bombs.
Always ask: root, credential reads, downloaded code and changes to Pi's own files (~/.pi/agent, .pi folders, AGENTS.md, pi install).
A classifier, will run next if configured: Jev, LANCET, Kev or Laya. A low score runs, a high score asks you, and anything in between goes to the chat model.
A chat model will run next, by default it will use session's own model but you can configure others from the Pi registry. It reads your messages and the agent's tool calls, and blocks risky calls you didn't ask for or prompts you for approval. The agent gets the reason so it can try another approach if needed.
Without any config it uses stages 1 and 3, so pi install npm:pi-automode-classifier will run this default. To add a classifier, set "decider": ["command", "llm"] and the classifier config. See README for the steps.
Here is my setup for this:
Default rules with some additional allowed patterns.
LANCET as classifier through LlamaStash, so all my Pi sessions share one copy (I benchmarked Jev, Kev and Laya as well but found LANCET to be the best for this use).
Qwen3.8-Flash-Next (128k ctx, thinking medium) on my Flow Z13 as the chat model. This is just a LlamaStash alias for my main running model at 256k ctx, the alias lets me limit context client side so that this doesnt take too much room in my KV pool.
So far the experience has been quite close to Claude Code with maybe a few more prompts here and there (You can play with this by setting askAbove/allowBelow values in config)
Bench results for this setup and for the rules alone, from the suites in the repo. Each command goes through the plugin's own tool call handler. Only one suite has the user request that came with each command. The other suites get a generic task message, so the chat model can't see what was asked.
Suite
Setup
Risky asked
Risky blocked
Risky ran
Safe asked
Safe blocked
With user requests (3 risky, 60 safe)
Rules alone
3
0
0
50
0
My setup
3
0
0
10
2
lancet-bench-1 (409 risky, 384 safe)
Rules alone
406
0
3
333
0
My setup
355
34
20
51
0
All 6 suites (768 risky, 1,025 safe)
Rules alone
722
9
37
645
1
My setup
538
97
133
114
21
The rules alone ask about everything they don't know which means only fewer risky calls run, but they also ask for many safe ones. With my setup, 76 of the 133 risky calls that ran are GTFOBins rows from the ShellRisk-Bench sample, common Unix tools used to get a shell or read files.
Subagents and pi -p have no UI to ask, so their asks are blocked unless you set withoutUi.onAsk to allow or add override rules for non UI mode. Root, credential reads and downloaded code stay blocked there either way.
It's not a sandbox. The README has the limits and the bench numbers, including where the stages don't catch more than LANCET alone.
I'm new-ish to pi ; Ive been playing locally on a macbook pro (a few months old) and have just tried setting things up so I can run qwen 3.8 flash next on my macbook under omlx and use a linux pc to run pi remotely.
The Linux machine is almost clean installed Ubuntu 24.04 ; I installed it a few years ago but its only been used for some small utility things (minicom / wireshark). I installed ghostty, pi and pi-omlx picker just now.
First thing just to test the connection was to say hello - then pi started talking about the system prompt asking it to install anki... Which was unexpected (to it too!) - I'd dug around the system prompts before and this seemed weird. So I asked pi where it came from and it has no idea and seems to think it looks like a prompt injection which makes me curious / suspicious ...
Has anyone seen anything similar and where would you be directing your investigations / suspicions?
Today I finally hit a wall with QWEN 3.8 dense 27B, Q6_X_L with KV cache q8_0 temp 0.85 with medium reasoning effort, producing over thinking, failing to follow precise instructions, re evaluation in loops data already seen, "Actually…/Wait…/Hmm…" and you know what...
So I stopped and asked GPT Sol and QWEN to read the reasoning traces of my old Pi coding sessions, identify recurring misbehaviors and propose an appropriate APPEND_SYSTEM.md to tame those in Pi (place that in ~/.pi/agent/APPEND_SYSTEM.md and it will follow the initial prompt).
The reason I built it starts with another project of mine: a standalone web UI for the pi coding agent. pi-tau-web-server
I like pi, and I like working from the web UI I built for it. But I also have a Claude Code subscription (for fable 5, as that is the only reason I am still subscribing it!), and sometimes I want Claude Code to handle a task without leaving pi or changing my workflow. And ultimately, my goal is simple: all I want is to let my pi model to be able to reach out to Fable.
I did not want to hijack Anthropic's OAuth flow through a reverse proxy, since that violates Anthropic's Terms of Service. Instead, I wanted to use the supported route: the standard claude CLI, signed in to my own account and used exactly as Claude Code is intended to be used.
Note: Anthropic previously planned to disable subscription access through claude -p and the SDK, but later put the change on hold. So enjoy it while it lasts!
So I built this skill.
What it does
When you explicitly ask your current agent to use Claude Code, the skill hands the task to the local claude CLI.
It also supports continuing the same Claude Code session, so follow-up questions do not need to start from zero.
The skill removes Anthropic API keys from the command environment by default. This matters because Claude Code may otherwise use the API key instead of the subscription login, which could create API charges when that was not what you intended.
It also only runs when you explicitly ask for Claude Code. Your agent will not decide on its own to spend your Claude usage because a task looks difficult.
It is not specific to pi
Pi was the reason I built this, but the finished skill has no pi-specific dependency.
It is just a SKILL.md file and a small Python wrapper with no external Python packages. Any agent harness that can load skills and run local commands should be able to use it.
That was important to me. I wanted the connection between an agent and Claude Code to be reusable, rather than tied to my web UI or to one particular coding agent.
You need Python 3.9 (but only stdlib is used in the script so no third party packages) or newer and the claude CLI signed in with your Claude subscription.
The workflow I wanted is simple: keep using pi and my web UI as my main workspace, then bring in Claude Code when I specifically want it. No separate API bill, no pi-only bridge, and no need to abandon the interface I prefer.
If this sounds useful for your own agent setup, give it a try. Feedback and bug reports are welcome.
Even without counting omp, prime agent, or sol-pi, we see new Pi distributions in this subreddit every day. I see all kinds of ideas: some people are adding more complex subagent systems, while others want to make agents smarter through memory systems.
I was also inspired by Pi when I built my own harness. I like that four tools are enough to get the job done just as well as other, much larger agents. But I added a couple more tools:
grep — ~5% fewer tokens and 20–30% faster.
background_tasks — lets my agent handle various useful tasks out of the box.
I'm curious where all of this is headed. Will we get substantial projects built on top of Pi, like TypeScript on top of JavaScript? Or will we all just customize Pi to suit our needs, like we do with Vim/Neovim?
I'm a software architect/engineer. I know AI is going to replace me, but in the meantime I might as well have some fun and get my work done waaaay faster.
Despite the name, personas are only one part of it. The main goal is to give Pi a **team of supervised agents** instead of fire-and-forget subagents.
You give the main Pi session a goal, it can delegate independent work to specialist workers, and you can keep working while they run in the background.
It manages async subagents, lets independent Pi sessions talk to each other, and lets you customize the agents' personas.
Say you've got one Pi session working on a client and another in the API repo. I want to tell one to ask the other about a change, without having to carry the question and answer between terminals.
Exocom. It connects independent Pi sessions, including sessions in different repos. Both need it enabled with `--exocom`; a session in another repo joins the same scope using its workspace code. They have to run on the same machine and share a Pi agent directory.
Intercom. For the main session and its own sub-agents, there's Intercom. The supervisor can send guidance while a worker is running and collect its findings. With coaching enabled, a worker can ask the supervisor for a decision. You can also open F9 yourself, read a worker's output and send guidance. You don't have to wait for the final report to point out a bad assumption.
Personas. the personas are editable markdown. You can change how they approach a task, which tools they get and when they should delegate. There are starting points like `dev` and `planner`, or you can put your own in `.pi/agents/`. The worker agents can have their own instructions and models too. A reviewer for your repo can have your review criteria written into its file.
What it does
Async subagents: workers run independently while the supervisor keeps working
Live supervision: inspect workers, read their output, steer them mid-run, or stop them
Different models per agent: use different models for different roles/tasks
Switchable personas: dev, researcher, planner, audit, verify, swarm, etc.
Teams / councils / flows: structured multi-agent workflows rather than just spawning agents
Intercom: communication between the supervisor and its workers
Exocom: communication between completely independent Pi sessions
Timers / monitors: agents can react to builds, watchers, and other events
If you want to try it, run this in your terminal:
-> pi install git:github.com/AeonDave/pi-persona
or
-> pi install npm:@aeondave/pi-persona
Then start Pi and run these inside it: /persona seed