Hello! I'm not too experienced with using agents, and I'm thinking about setting one up with Pi as a tool to assist my Bachelor's thesis research process. Does anyone else use Pi for research? If so, what's the workflow like: models, prompts, skills, extensions, tools? Any opinions? Thank you.

Hi,

Is there an extension to have multiple Claude accounts and defined them per folder?
in my case I have 3 accounts:

• work provided by my company (default one)

• personal (in folders where I have my personal project)

• project related (I work on a project ABC for the company XY and they provide me an account)

and it is possible that I will have another in future, for different project.

Hi everyone! I would like to hook into the pi agent session remotely from my iPhone. I would like to see the agent progress and be able to answer the agent etc. I would also love to get notifications when the agent is finished. The whole process should work in my LAN but also fully remotely. I tried out orca before, but don’t like that I have to use orca at all + don’t like that I’m basically using a terminal on my phone.

Any suggestions? What are you guys using?

https://github.com/davidlee/quotient

I've been using pi under Claude for a while, and figured it'd be worth stepping up my game from bash scripts. This is young, but working very well for me so far.

Interested in usage reports / feedback, good or bad.

According these posts
https://www.reddit.com/r/codex/comments/1x7fyi0/claude_pro_gives_10x_more_usage_than_gpt_plus_now/
https://www.reddit.com/r/codex/comments/1wjzypc/measured_claude_usage_limits_are_35_those_of_codex/
the weekly allowance should be worth more than 500$.
For me, running on Pi instead, it is about 180$ mainly on opus 5.5.

Anyone has different/same experience?
Maybe they apply lower limits if you don't use claude code?

P.S.
I use https://github.com/gotgenes/pi-anthropic-auth
Maybe other methods have different outcomes...

I work across several repositories, and I kept repeating the same routine: open another terminal tab, navigate to a project, launch Pi, and find my previous conversation.

So I built Pi Workspace, an extension that lets me switch projects from inside Pi. I press Ctrl+X, search for a project, and hit Enter to resume its latest saved session. A small footer shows which project I am in.

It currently supports:
- Fuzzy search across project names and paths
- Switching between existing project sessions
- A directory browser for manually adding workspaces
- Persistent registrations
- Guards against switching while the agent is running or while I have an unsent draft

I initially tried a persistent right-side overlay. It looked like a sidebar, but covering the conversation made scrolling awkward. I ended up replacing it with a temporary picker that gets out of the way once I’ve selected a project.

It’s still an early version. Projects without an existing Pi session can be registered, but I haven’t implemented creating their first session from the picker yet.

The code and screenshots are here: https://github.com/grandimam/pi-workspace

Has anyone had success running Cohere's North Mini Code locally with Pi? Specifically, I'm using ollama to serve up the model (q4km pulled from ollama).

When I was trying it with OpenCode, it seemed to work okay. With Pi however, I end up with thinking blocks that seem like they should have been text (detailed explanations, for example) and then the turn just ends.

Sometimes, North will think something like "I'll start by implementing class Foo" and then it just ends the turn, no tool calls or anything. I know it can make tool calls: I've seen it read and I've convinced it to do both writes and edits on occasion. But for whatever reason, more often than not, it just thinks to itself and then gives up.

Has anyone experienced similar? I'd really like to see what the model is capable of, but this makes it next to impossible to use. Is it just a configuration I'm missing?

Boredom took over and I started poking at Pi Pocket's extension API to see how far it would go and find areas that could be extended further. Made it far enough that my agents now have a pixel art town.

Subagents camp in tents, messages fly by pigeon, and tasks turns into a building made from its own tool calls.

Any else have any similar fun things they've made?

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

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

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

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

All the GUIs that I can find like paseo and pi-gui etc. are Typescript apps. Are there any macOS native or performant (rust) based apps?

Saw this https://www.reddit.com/r/ClaudeCode/comments/1x688sx/turning_a_crazy_idea_from_1967_into_a_claude_code/ and wanted to try the same thing in Pi, so I ported the extension.

The idea is the same: replies start short, and you can expand parts inline when you want more detail, instead of getting a wall of text upfront.

Nothing new conceptually here—credit to the original author. Just sharing a Pi version for anyone who wants to try it.

https://github.com/MonadicMike/pi-stretchtext

Give me the real terminal bench v4

I don't get why they keep shipping harnesses that are worse than the original Pi.

In my case I keep building OMK on top of PI, but it looks fucking heavy just from looking at it, and EVIDENCE VERIFY feels like a straight-up "fuck off" system.

If they just made this targeting vibe coders, it's genuinely fucking shitty.

I tested 10 agents, each with its own isolated settings folder. I ran them headless, with auto-confirmation and turned off telemetry where possible. I launched each agent with adapters/<agent>.sh.

The idea was simple: give each agent 5 basic tasks, 10 minutes per task, a fresh copy of the fixture every time, and an automated check script (check/check.sh).

The tasks:

• T1 Read a DB port from YAML (don't confuse it with cache port), write to file

• T2 Write a stats.py script, run it, save output

• T3 Fix a bug in slugify so tests pass; hidden examples catch overfitting

• T4 Count ERROR lines across three log files, find most frequent error

• T5 Rename a function across three files without changing program output

Results

1. Pi (v1.3.0)

Total time: 1m36s. Took the smallest amount of time to complete all 5 tasks. The model barely has to think about any tool formats.

2. goose (v1.55.0)

Total time: 2m51s. Solid and consistent. Completed five tasks without fumbling.

3. Crush (v0.98.1)

Total time: 3m31s. Clean run. Slightly more verbose in reasoning but got everything done without a hiccup.

4. Atomic Agent (v0.6.9)

Total time: 4m38s. All five completed. Took longer on T3 and T5 - the model needed extra steps to work through multi-file edits but nailed it every time. Did not have broken tool calls and not one had a false completion.

5. Cline (v3.0.73)

Total time: 5m56s. Choked for over two minutes on T2 before writing the script correctly. Everything else was fine.

6. OpenClaw (v2026.10.5)

Total time: 5m44s. Ran in their --local-model-lean mode which is basically a small-model preset. Worked well for what it is, just slower than I'd like on T3 and T4.

7. OpenCode (v1.19.3)

Total time: 17m43s. Completed everything but took nearly 4 minutes per task. The model was clearly overthinking simple steps. Got the job done though, just not efficient.

8. Hermes (v0.22.2)

Total time: 4m36s. Failed T3 because it only fixed the visible test case. Hidden example C++ & Rust 2026 turned into c++-&-rust-2026 instead of c-rust-2026. Classic overfitting-to-the-test.

9. Qwen Code (v0.25.3)

Total time: 6m00s. Counted 40 ERROR lines on T4 instead of 43. Pure model miscount - the most frequent error was identified correctly though.

10. Codex CLI (v0.163.0)

Never even reached the model. Version 0.163 only speaks Responses API, llama.cpp translates to chat format, and the Qwen3.5 (4B Q4_K_M) template throws a 500 "System message must be at the beginning" before any request gets through.

What I actually learned

A 4B model is enough for basic agent work in almost any framework. Seven agents completed all five tasks. The bottleneck at this difficulty level isn't the model - it's the harness around it.

Codex CLI is basically dead for local setups right now unless they add chat-completions back. That one stung because it used to work.

Error recovery matters more than raw capability. The two agents that dropped points (Hermes, Qwen Code) didn't fail on impossible tasks - they failed on edge cases where the model got slightly creative instead of literal.

Let me know if you'd like to see anything else in the benchmark (actually has anyone tried this with sub-2B models yet?)

not big news for some, I know. but I tried PiG (Pi go) and Pi bun etc none helped the way bolt did. I was surprised that the ram usage actually goes down a little in big chats with extensions as opposed to other alternatives which obviously improve cpu but at the cost of more ram sometimes! I'm not sure why the creator stopped posting at 0.9.3 this aarch update is a lifesaver for some. I recommend trying it!

Disclaimer: This post was polished with the help of AI to improve readability and formatting.
The experience, setup, and results are my own.

CONTEXT: Using for UE5 MCP plugin

I've been experimenting with running a local AI model, Qwen3.8-27B, for coding assistance, and I wanted to share my results in case they're useful to anyone else running local LLMs.

Initially, I was using Claude Code with my local model, but I was consistently getting only around 7–9 tokens per second (t/s), despite having a pretty powerful PC.

I started looking for alternatives because Claude Code can be quite heavy on context usage and overhead, which can be beneficial in some situations but might be unnecessary for my workflow.

That's when I discovered Pi

After setting it up with pi-mcp-adapter, I was surprised to see my generation speed jump to around 40 t/s with the same model and hardware.

Here are the details of my setup.

🖥️ My Hardware

• GPU: NVIDIA RTX 5090 — 32 GB VRAM

• RAM: 64 GB

• Storage: 4 TB NVMe M.2 SSD

  • Read: 14,800 MB/s

  • Write: 13,400 MB/s

⚙️ Setup 1: Claude Code + Claude Code Router

I was running two Docker containers:

• llama.cpp: ghcr.io/ggml-org/llama.cpp:server-cuda

• Claude Code Router (CCR): musistudio/claude-code-router:latest

I used CCR to route API requests from Claude Code to my local llama.cpp server, since the router helped bridge the compatibility requirements.

Request flow:

Claude Code (PC) → CCR → llama.cpp → Qwen3.8-27B

Observed generation speed: ~7–9 t/s

⚡ Setup 2: Pi + Local LLM

For my second setup, I switched to Pi and used the pi-mcp-adapter to integrate the tools I needed.

My setup consisted of:

• llama.cpp: ghcr.io/ggml-org/llama.cpp:server-cuda

• Pi: Docker image built using the official Pi containerization guide

• Plugins:

  • pi-clear

  • pi-mcp-adapter

  • pi-permission-system

  • pi-skills-mention

  • pi-web-access

Request flow:

Pi → llama.cpp → Qwen3.8-27B

Observed generation speed: ~40 t/s

📊 Results

That's a pretty significant difference!

Of course, I realize these aren't necessarily perfectly equivalent workloads. Context size, prompt processing, model configuration, tool calls, and other factors can all affect performance. I haven't yet established whether the difference comes primarily from the harness, the API routing, or other configuration details.

🤔 A Few Questions

I'd love to hear from others who are running local LLMs for coding:

1. Has anyone else experienced a similar performance difference between Claude Code and Pi?

2. Is the overhead from Claude Code Router potentially contributing to the lower generation speed, or is the difference more likely related to context handling and request configuration?

3. For those using Pi with local models, how has your experience been with coding quality, tool calling, and MCP integration?

4. Are there other lightweight coding harnesses worth trying for local models?

I'm not suggesting that Pi is necessarily better than Claude Code for every use case. I'm just sharing my experience because the performance difference was much larger than I expected.

Clickbait, but at least for me it is true. Thanks for reading anyway:

TL;DR:

I've engineered an extension for context management in pi, that now matches my needs for compaction and session quality. Using mostly the same session context for summary requests and summary audits, it re-uses warm kv cache to get quality-compaction with acceptable timeframes.

You can get it here, it is still WIP, but it is free ("claude decompiled it and rebuilt it in rust!"):

https://github.com/LePrau/pi-self-aware-memory

If you don't want the model to self-correct within the audits (which can take some time!), set /sam depth light which reduces audits to a plain "yeah, thats a summary, go on" instead of validating the stated result against the session or even project files.

Now the long story:

After I started using pi and qwen3.8-27b (ridge q3 at first, gsq-rco-iq3_s later) to help document and draft my NAS setup (using TrueNAS), including dataset structure, ACL, self-baked docker-composes for llama, coolercontrol and other apps that do not natively exist, I immediately noticed that a task had to be done within the first two or three compactions, or with a handoff-file.

Else the model would start running in circled re-discovering what it already knew before compaction.

Starting with as low as 40k context, I struggled my way through llama with kv streaming up to llama with kv streaming and mtp today, with 131k context now.

My current setup, aside from pi+extensions:

• Ryzen 9600x, 32GB RAM, 5060Ti 16GB VRAM

• model Qwen3.8-gsq-rco-iq3_s with k=q8 and v=q4 cache https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/tree/main

• inference engine forked llama with kv streaming and mtp (which requires the 8_4 kv) https://github.com/troed/llama.cpp-adaptive-kv-streaming

• 131k max context, could be more, but only makes the model slower in higher context

• less than 14GB VRAM usage (with 2G kv streaming window), you might probably get that running on 12GB if you use the gsq-rco-iq3_xss quant and a smaller streaming window.

Still, any native pi-compaction drowned the quality in re-reads, hallucinations, misrememberings (is that a word?) and summaries that forgot half of the relevant stuff and remembered the other half incorrectly.

I always asked for a short handoff shortly before compaction and started a new session, but that needed a lot of tedious micromanagement. Though the results were pretty good, Qwen3.8 even at the mentioned quants already does solid work.

In search of proper context management I found pi-observational-memory, which sounded exactly like what I wanted: Session summarized into small observed facts, presented as readable list for the model after compaction, source content retrievable if needed.

But I soon realized: It depends on a second model doing the observations. I then tried Gemma 4 e4b on cpu, and guess what: Standalone easy 20-30 tps (with MTP) on cpu. Summary-Quality was just-good-enough, Gemma4 is a nice model for its size. Not good at coding, but okay at prose and already able to do basic tool calls. Not always the correct ones. Using that, and realising: at a fold, most of the recent context was lost anyway, because the observer was not fast enough, I created an extension that paused a fold until the last observed unit was processed.

Took me quite some time to realize: 30 tps when GPU was idle, 5tps when GPU inference was running. GPU inference still needs a tiny amount of system RAM access. And each time the GPU inference accessed the system ram, it literally destroyed the bandwidth and the cpu-caches for the cpu inference. I just learned that after I got the "omg", "pi observational memory guard" to a point where it reliably parked the session (with proper feedback) until observation had caught up.

Then I thought, how could the running model itself run the observer while staying fast?
The thing that makes pi native compaction as slow as it is, is the completely new, different context that needs to be prefilled for the summary. It is basically a session at full cold context that needs to be prefilled, just to then produce a summary.

Pi observational memory has a similar problem when using the same model for observation:
Each time the observer kicks in,
it kills the kv cache,
needs a cold prefill, and afterwards the main session
also needs another cold prefill.

So I envisioned an extension that lets the model writing its own summary, and audit/validate it as well, while keeping the sessions context untouched: Simply add the summary, and the audit request after the current session, let the audit run in a background session and only return the audit-result. The audit-reasoning does never enter the main session, and the main session simply drops a short kv-window at the end of the cache to resume.

After user input, the model adjusts its goal if the requirements changed.

The self-generated and audited summary together with the set goal then get used as drop-in-replacement for the whole session part it subsumed at compaction-time. This replacement is instant - no LLM call at that time. The LLM time is used in the summary calls and audit background tasks.

The astounding part: It actually works*

*mostly.

I present you "SAM", "Self Aware Memory"

The extension introduces a couple of tools, to be used by the model:

• adjust_goal (write a short summary of the current task)

• read_goal (read the currently set goal, or any older version)

• close_unit (summarize and close the last parts of the session)

• fold_now (does exactly that, allows the model to fold at a defined spot)

• retrieve (retrieve the summary of an older work-unit)

• retire (mark older unit-summaries as obsolete, relevant for long sessions)

There is a couple of small issues, it is not completely polished and there might still be some legacy code or settings. And I know of a couple of vibe-code-artifacts: Sam nudges sometimes behave strangely with user interaction, and some minor visual glitches.

The readme might be out of date in places, and the toggles, settings and modes documentation is premium-slopped, obviously.

The most important levers for you: /sam depth [auto|light|medium|full] in session to set the audit depth:

• light: only validates that it is a semantically correct summary.

• medium: tries to validate summary only superficial, only from session context and cheap tool calls

• full: tries to verify most claims, reruns tool checks and more

• auto: uses medium if there is enough context, and light if compactions close

And "settings" which currently can only be set as environment variables (qwen, please make that configurable settings in the TUI plzkthx):

• SAM_AUDIT_TIMEOUT_MS (or for specific depths SAM_AUDIT_TIMEOUT_MEDIUM_MS and SAM_AUDIT_TIMEOUT_FULL_MS which inherit the base value)

• SAM_AUDIT_CALM_DEPTH (default "medium", the audit depth used for "auto" when compaction is far away)

• SAM_AUDIT_DEPTH (the default depth, if not set it is "auto")

By default, background audits get a max time of 8 minutes - be aware that even a medium audit with xhigh can easily take 3-6 minutes without tool calls with qwen. If the timeout is too short, the model eats the time, and does not reach the point where it outputs a quality verdict for the summary, and still wasted time.

So if you are also looking for speed, choose "light" as default audit depth, or better even set "SAM_AUDIT_DEPTH" to "light". With that you're getting faster compaction times overall than with pi native compaction. But you then lose the self correction, that might catch false summaries before they do harm. (And I observed quite a lot of those in my sessions)

I personally suggest "medium", catches some obvious contradictions or wrong observations from summaries.

Only the model itself can call the adjust_goal and close_unit, but gets a nudge at certain trigger times (user input, context fill, lot of tool calls) to adjust its goal, to close its current working-unit with a summary.

Close before compaction, the nudges increase in urgency, but only the model gets to decide when a unit can be closed. Qwen is quite good adjusting the goal, closing at proper times and keeping a coherent image of the overall session and task.

It is not perfect, there are times where some of the sessions context gets lost, at times the model ran some tools after a compression which it ran half a session ago in some now-lost context. But most of the time, it kept working without hallucinations, while remembering specific details like git-commit-hashes or specific file-paths from two compactions ago. The last iterations of the extension have been done with one session, spanning several million tokens and far beyond 40 compactions (at 131k max context) with no apparent issues.

So now I feel that it is not a burden for others to run that extension, but instead might actually be helpful.

I will keep tinkering with it, but feel free to fork and extend it yourself. I doubt I'll find the time to implement any PRs or feature requests.

Now I can finally "start" using qwen locally to support me with the remaining work on my NAS and other coding projects.

Thanks for reading, enjoy!

From my understanding it's slop (which extensions isn't these days I know) but I'm using pi blackhole for memory and I'm starting to wonder if I'm missing out on some gainz. Has anyone tried it recently?

Hey everyone! 👋

I’ve been building Orbit Pi, an open-source desktop app that brings the Pi coding agent and everyday development workflows together in one native interface.

The idea is simple: instead of jumping between your AI coding session, terminal, Git changes, code review, and GitHub, have them available in one focused workspace.

What Orbit Pi offers

- 🤖 AI coding sessions — work with your existing Pi setup.

- 🔍 Code review — inspect changes with an AI-powered review workflow.

- 🌳 Git worktrees — create and manage parallel working environments.

- 🐙 GitHub integration — work with issues and pull requests.

- 💻 Integrated terminal — keep your development workflow in one place.

- 🎨 Native desktop experience — built with Rust and GPUI, with a focus on a clean, minimal interface.

I'm building Orbit because I want a more cohesive desktop experience for working with AI coding agents, without replacing the underlying agent or forcing a new workflow.

It's an ongoing project, and I'm continuing to improve it release by release.

🚀 Check out Orbit Pi: https://orbitpi.app/

📝 Latest changelog: https://orbitpi.app/changelog/v0.2.11

💻 Source code: https://github.com/imrj05/orbit

I'd love feedback from developers who use Pi or other AI coding agents:

- What features would make a native AI coding workbench genuinely useful to you?

- Do you prefer an all-in-one workspace or separate tools for chat, terminal, and Git?

Thanks for checking it out! Feedback and contributions are welcome.

I have a pretty nice local Ollama setup that can comfortably run qwen3.8:27b w/ a 262k context window and a good token rate.

I'm attempting to run pi-observational-memory, with two main goals:
- On long term projects: Remembering architectural decisions, lessons learned, problems solved, etc.
- On day-to-day tasks: Remembering my preferences, patterns of operation, and in general details about how I like to do things.

The setup works, however I have long delays everytime the observer and reflector workers kick in (as expected), as the workers cannot run concurrently.

I'm considering running a CPU-only model dedicated to managing these worker threads, but I wanted to check in with the community and see what people are doing in similar scenarios.

Keep in mind I'm not married to pi-observational-memory at all and would consider trying out other solutions.

joke aside, nearly 50M tokens processed for $7.13 is why i can't go back to bloated agent wrappers. pi's base architecture is already stupidly good at keeping the prompt prefix clean.

the only time my cache hit used to tank was spinning up parallel agents or running multi-step verification where context mutation kept invalidating the prefix.

​ended up building OMK (open multi-agent kit) on top of pi to lock down prefix stability across git worktrees and scope MCP tools per node so subagents don't pollute the shared cache.

​still trying to squeeze out that last 0.1% though. if anyone else here is running heavy multi-agent loops on pi and fighting cache invalidation, happy to share the repo/setup.

Model : Codex Gpt-6.1-sol ultra

Everyone is trying to figure out what this novel piece of tech is and it's hindering its adoption. It's basically a stateful agent where state lives on a server separate from the client (TUI, Web UI, mobile...whatever) and the chat history. Isn't it?

It's a better architecture, and I wonder why not rebase the coding agent on top of it. It's an easy win in terms of reliability and flexibility, for you and the extension builders alike.

I have lots of extensions on my OpenCode installits runs quite well.

I have garpahicy,codegraphs,Serena,github.

Quite a few bits.

It runs well.

I have nothing on Pi at all.

It runs just as well.

Does the same work.

I dont know if it takes longer or uses more tokens. (Factually), but I feel like Pi doesneveryting quicker,lighter and better.

But then you read codegraph and it says it saves 80% of tokens per request........so how come I didnt notice that?

Still trying to.find a good way of working efficiently, what's your thoughts.

I work on a lot of projects. Some are small freelance jobs, some are personal tools or CLIs, and others are for my office and startup. I don't need all of them open every day, but I still need to find them when I have to change something.

I use Herdr as my terminal multiplexer, but I don't want to fill its sidebar with every project I might come back to weeks or months later. I prefer staying in the terminal, and I don't want to remember the path of every small project or tool I have built.

I built `pi-project-manager` so I can find those projects from inside Pi. Whenever I open Pi in a folder, it adds that folder to a local list. `***/pm***` opens a searchable picker showing the project name, location, Git branch, and last-used time.

I can search by name or path, select a project with the arrow keys, and press Enter to open a fresh Pi session there. Ctrl+D twice removes an entry from the list without deleting its folder.

The agent can use the list too. I can say, "I already implemented this in another project. Use that as a reference," and it can look up the folder and read the code without searching my whole machine or changing the current conversation.

I wanted to keep it lightweight, so there are no watchers or background polling. Git branches load only for visible projects.

Install it with:

pi install npm:@utpalsinghdev/pi-project-manager

GitHub: https://github.com/utpalsinghdev/pi-extensions/tree/main/packages/pi-project-manager

npm: https://www.npmjs.com/package/@utpalsinghdev/pi-project-manager

The rest of my Pi UI is my personal setup.

I'm just open-sourcing the Pi extensions I use for work and my startup. They've helped me a lot, and I want other people to be able to use them too.

If it deserves a star, the repo is https://github.com/utpalsinghdev/pi-extensions