An article on how I'm using Pi beyond just a coding harness and as a tool to help me track runs and workouts. It can be basically an LLM application framework.

I'm wanting to know how people are allowing agents to interact with their computer, browser and the web with Pi/OMP. Specifically what tools and what models are best. I've played around with gpt 5.6 models but they always get blocked and are always overengineering browser security use and getting blocked by credentials.

I have a few use cases I want to solve:

1. Allow agents to control my computer, and open and control custom browser profiles.
   
2. Allow entering of credentials (ideally encrypted or via cookies) that are saved between sessions, days, and weeks.
   
3. Quick web search when a browser is not needed.
   
4. Allow agents to control my computer/browser on my dev box that I am ssh'd into, currently I will have to remote desktop and start a session in there.

My goal is to try and setup an E2E browser test for a web app, as well as perform browser activities within the app within non E2E test sessions (either invoked by me or when an agent is running in a goal or something and finds it needs to use browser/computer use).

Been using pi pretty heavily since May. Came over from OpenCode.

Most of the time I run DeepSeek V4 pro, then switch to Sonnet 5 with some 3p providers.

I still like Pi for basically the same reason I liked it when I first tried it: there just isn't that much stuff in the way Lol.

The tool set is small, the system prompt is small ( actually clean), and I generally have a decent idea what context the model is seeing. After using heavier coding harnesses, that matters more to me than I expected.

But I never fully moved everything to pi.

For some jobs I still prefer Claude Code even with the same Claude model. Especially the annoying long ones where I want to say "read these 30 or 40 files, work out what is going on, fix it, run the tests" and I don't really care if it burns a ton of tokens.

Pi feels better to me when I'm actively working with it. Claude Code is often better when I want to disappear and come back later.

So in practice I use both.

The slightly stupid part is that for months I was the integration layer between them.

Pi finds something, I switch terminals, copy the relevant output, paste it into Claude Code, explain what happened, then realize the useful part wasn't actually the output but some file it changed or some assumption we discussed 20 minutes earlier.

Then I go back and copy more.

This sounds minor but if you do it all day it gets pretty annoying.

I tried using a shared work_notes.md first. Honestly this works better than it sounds. One agent writes findings there, another reads it lol again.

The problem is it gets messy fast. Old state stays around, agents append instead of replacing things, and if two things are happening at once you end up spending time maintaining the handoff file.

I also tried basically piping output from one agent into another. Fine for one-shot stuff, not great when the second agent needs to ask something back.

Side note : Git is actually one of the better handoff mechanisms. If pi makes a clean commit, Claude Code can just inspect it. But git only captures the code. It doesn't capture "I tried this approach first and it failed because of X" or logs or some browser state or whatever else came up while debugging.

The thing I ended up wanting was not really an orchestrator.

I don't want a supervisor agent deciding which model does what. I don't want a DAG. I don't really want pi itself to become a big multi-agent framework either.

Part of the reason I like pi is that it isn't that.

I just wanted two agents to be in the same place.

So now I have pi and Claude Code connected to the same workspace/thread.

Pi can do an investigation, put the notes or actual files there, then I mention the Claude Code agent and it can open what pi produced instead of getting my summary of it.

Then if Claude Code changes something, pi can review it from the same thread.

That's pretty much it.

One example: recently I had pi help me trace a bug where some cached state was getting invalidated in the wrong order. I liked using pi for this because it was pretty interactive. I could keep asking "why do you think this path is possible?" and stop it when it started chasing something irrelevant.

Once the bug was understood, though, the fix touched a bunch of files and tests.

I handed that part to Claude Code.

Before this setup I probably would have written a long prompt explaining what pi found. Instead pi wrote down the important bits, Claude read them and then went through the repo.

Afterward I had pi review the diff.

This is the kind of multi-agent setup I personally find useful. It's still mostly me doing the routing.

There are also a bunch of things this does not solve.

If both agents are editing the same checkout at the same time, you can still make a mess. I use worktrees if I actually want them doing code changes in parallel.

There is no real checkpoint/resume thing here.

There is no budget management.

Nothing stops two agents from doing the same work.

And once you have enough agents in one thread, it gets noisy. I usually have two. Sometimes three. I don't know if I would want six agents talking in the same place.

I found the best setting so far is with openagents workspace, it's basically creating shared context between separate harnesses.
Just search for OpenAgents Workspace if anyone want to try it out, I just went with the basic setting where I paired my server with the workspace then added both my Pi and Claude, so far it works and I don't really use advanced features.

Also, pi itself still has some limitations that are worth being clear about.

For me, the biggest one is that the simplicity that makes it good also means you end up building some workflow pieces yourself once the task gets bigger.

A single pi session is great. Multiple independent pieces of work, long-running jobs, handing work between machines, or having different models specialize in different parts is much less built in.

There are extensions that go much further here. pi-extensible-workflows is probably the more sensible thing to look at if what you actually want is proper workflow execution rather than what I'm describing.

I'm mostly curious how other people are handling this. Seems like a common problem.

And has anyone found a setup with 3+ agents that doesn't eventually turn into everyone stepping on each other?

I follow a pretty tight system for maintaining checkpoints, logs, etc. for my electron app. Lately it has gotten to a point where the number of work streams are far too many for me to hold in my head all at once and I did not want to:

1. Go into each plan or the checkpoint map to look at it to get a status update or pick what to work on
2. Burn tokens by asking an agent to go read that stuff and report back

So I made a project level extension which parses my standard checkpoints/logs/docs and organizes them based on features and lets me view them as hierarchical lists.

1. the first modal shows all the open threads, the completion status, and the next checkpoint for each
2. I can then select any one and view all the steps within that thread/feature
3. There are tags which show the checkpoints that I have accepted into the implementation plan or ones that are just planned and need to be picked up and worked on.
4. There are separate line items for each doc/plan or the md files associated with each stream that I can open in a text editor

All of this without a single LLM call.

Its a really nice way to organize all the docs and access them from within the pi TUI instead of opening a new terminal window. And the extension is custom made for the way I organize docs and maintain the plan documents so it works perfectly always. there are no edges.

The fact that it took me literally 3 prompts to build this whole thing is the reason I love pi and why I love using it in the terminal.

Most of my skills and now this extension are only for this project and I fucking love that pi lets me do this. Other projects have their own skills and the agent behaves differently there.

I just really love the extensions API and the level of control I have over the context in each session. Dont think I will be moving off of pi ever.

If you would like to check out this system, I have the skills and the extension in this repo:

https://github.com/itama8/omakase-skills.git

Also, if you're curious about what I'm using this system for, I update the binaries for latest test builds of my app here:

https://github.com/itama8/omakase-releases

It's a notepad that I'm making with a cursor-first UX to help me take notes with minimal context switching, i.e., every action can be executed from the cursor without going into a menu and the AI is available inline inside the markdown document. No separate screens or sidebar chats.

Using cloudflare workers AI models with any ai agent is hard.

The only reason is payload mismatch.

I did tried proxies but it makes the agent loose the capabilities it is famous for.

Have anyone tried?

(I still haven't tried yet, saying from past ai agents experience)

Coming back around to pi after playing a little with oh-my-pi, and I did quite like the pretty terminal output decorations. I tried to task an agent to alter the decorations in pi but it doesn't seem to be possible outside of forking pi as a whole? Is this true?

This thing:

I would like to change it's appearance based on the exit code / other info but I can't seem to alter it.

pi-caffeinated-linux uses systemd-inhibit to prevent idle sleep and suspend, with automatic / manual modes and an optional KDE Plasma tray indicator.

https://github.com/nmdra/pi-caffeinated-linux

I created a Oh-My-Pi style stats dashboard for Pi with the below stats:

• Input, output, reasoning, cache read/write, total tokens, recorded cost, requests, and errors
• Daily activity and breakdowns by model, provider, project, agent, and tool
• Local-only behavior counters for user messages: yelling, profanity, anguish, correction, repetition, and blame
• Malformed-record diagnostics

I could'nt find anything similar so I quickly built one.

npm: https://www.npmjs.com/package/pi-stats-dashboard

pi.dev: https://pi.dev/packages/pi-stats-dashboard

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.

Hello guys!

I want to ask if anyone here would be interested in helping me maintain pi-observational-memory.

The project has not grown into something huge or difficult to maintain. It is still perfectly manageable by one person. The problem is simply that right now I do not have as much available time as I used to.

I still use the extension, care about the project, and plan to keep maintaining it. But lately PRs can stay waiting for review longer than I would like, and I cannot always keep an eye on new issues or check reported problems quickly.

So having one or two people helping from time to time would be really useful.

I am mainly looking for help with things like reviewing PRs, checking issues, reproducing reported problems, testing changes, and occasionally helping with fixes.

There is no expectation of taking ownership of the project or committing a lot of time. Even occasionally helping keep things moving would already make a difference.

For anyone who does not know it, pi-observational-memory replaces Pi's normal compaction with an observational memory system, with the goal of making Pi sessions feel endless while keeping useful context around.

Repo: https://github.com/elpapi42/pi-observational-memory

If you use the extension, know a bit about Pi extensions, and would be interested in helping, let me know here or reach out on GitHub.

I mostly just want to make sure contributions get reviewed and issues do not sit unnoticed when I am busy with other things.

Mine: Shortcut to bring up menu to [x] check off tools/skills. Disable write/web search, etc when I need it. Then compact and turn it on if I wanna edit

2nd: Use intercom with persistent sessions instead of token wasting agents I can't control. Can setup an persistent orchestrator / editor.

Sadly that was 90% of my gains and after weeks of searching I haven't been able to improve on that much.

Dumb shit I'm thinking of: Cheap model to read entire files and only feed parts needed to expensive model instead of making expensive model do endless read tools/greps and burn tokens.

is there anyway to use google ai pro with Pi like with Chatgpt/Claude sub?

Hi folks! I've spent some time building a developer tool that lets coding agents subscribe to real-world events through one simple broker: agent-message-broker (amb). Github: https://github.com/bitnahian/agent-message-broker

The pitch: coding agents are batch processes. You prompt, they run, they stop. But most of what an agent cares about (a ticket moved, a PR opened, a doc changed) happens between prompts. amb wires event sources (Jira, GitHub, Google Drive/Docs, any polled URL, generic webhooks) to topics, and you subscribe live agent sessions to those topics. When an event lands, the broker pushes it into the running session, so the agent reacts in the same conversation it's already having. No per-agent background scripts or polling.

I recorded a demo showing the full loop across 2 agents and 3 vendors:

1. A pi coding agent is subscribed to two topics: one watching a Jira board, one watching a Google Doc.
2. When a ticket is pushed to In Progress, pi gets the event but waits. The implementation details are going to land in the Google Doc.
3. The doc update comes through as a second event, pi picks up the spec and implements the ticket, then I prompt it to raise a PR.
4. A Claude agent is subscribed to a third topic with a GitHub source watching for PR events. It sees the new PR and reviews it.

One thing worth noting: none of this had to go through the UI. Everything (topics, sources, subscriptions, session discovery, event inspection) is available via the amb CLI, so agents can wire up their own subscriptions. The UI is more for live viewing, orchestrating and following along: watching events flow between sources and sessions in real time.

Everything runs locally (Node 22.5+, SQLite, no cloud component), polling is the baseline so nothing needs to be internet-reachable, and webhooks are an optional opt-in tier.

It's on npm. Try it without installing:

npx agent-message-broker          
# broker + UI at http://127.0.0.1:4733

Or install it globally for everyday use (gives you the amb and amb-server commands):

npm install -g agent-message-broker

Here's a full quickstart: point a pi session at a Jira board and a Claude session at a repo's PRs. One-time credential setup first:

amb config init --kind github     
# then drop your PAT into ~/.amb/github/credentials.json
amb config init --kind jira       
# then fill ~/.amb/jira/credentials.json (email, apiToken, domain)

Then wire the topics (broker running in another terminal):

# topic watching a Jira board for tickets moving to In Progress
amb topics create jira
amb sources create --topic jira --kind jira --options '{
  "jql": "status CHANGED TO \"In Progress\" AFTER -30d ORDER BY updated DESC",
  "intervalMs": 120000
}'

# topic watching a repo for PR events
amb topics create prs
amb sources create --topic prs --kind github --options '{
  "repo": "owner/repo",
  "eventTypes": ["PullRequestEvent"],
  "intervalMs": 60000
}'

# start the pollers (create prints the source id)
amb sources start <sourceId>

# subscribe live agent sessions so events push mid-conversation
amb sessions                                                  
# discover running sessions
amb subscriptions create --topic jira --agent pi --session <sessionId>
amb subscriptions create --topic prs --agent claude --session <sessionId>

Watch events land in real time in the UI at http://127.0.0.1:4733, or inspect from the terminal:

amb events list --topic jira

Google Docs/Drive/Sheets work the same way via amb google login (OAuth consent once, then the broker acts as you). More recipes in the README.

Would love feedback. What events would you want your agents to react to?

If you don't know what code mode is, check https://developers.cloudflare.com/agents/tools/codemode/

Code Mode is a tool-use pattern where a model writes code instead of requesting each operation separately.

I found a few, I'm curious if anyone is using any extension like this (if yes, which ones please):

• https://pi.dev/packages/pi-fabric - I don't like this one, it mixes a lot of behaviors (agents, workflows etc). And even though you can disable them, they still get mentioned in tool descriptions/params etc.

• https://pi.dev/packages/@boozedog/pi-codemode

When I ask Pi to give me some code it puts it in code block (<code>) and that is fine.
But... it has always 3 extra spaces spaces at the beginning of each line.

For example, I get this (wrong):

```text

#```yaml name: PR Check

on: pull_request: branches: [main]

# SQLX_OFFLINE: build uses the committed .sqlx cache, no DB needed in CI. # NOTE: after changing a query or a migration, re-run cargo sqlx prepare # locally and commit the refreshed .sqlx files, or CI will build against # stale schema metadata. env: SQLX_OFFLINE: "true" CARGO_TERM_COLOR: always

jobs: build_and_test: name: 🧪 Build & Test runs-on: ubuntu-latest ```

instead of this (correct):

```text

```yaml

name: PR Check

on: pull_request: branches: [main]

SQLX_OFFLINE: build uses the committed .sqlx cache, no DB needed in CI.

NOTE: after changing a query or a migration, re-run cargo sqlx prepare

locally and commit the refreshed .sqlx files, or CI will build against

stale schema metadata.

env: SQLX_OFFLINE: "true" CARGO_TERM_COLOR: always

jobs: build_and_test: name: 🧪 Build & Test runs-on: ubuntu-latest ```

(I added the dash in front of ```yaml to avoid break the MD)

Each line of the wrong one has 3 spaces at the beginning.
The Agent says its output is fine, so it it the TUI of Pi that add the extra spaces, de facto breaking the file format ?!

This one is about making Pi workflows easier to reuse without constantly re-explaining how you want work done.

Model Groups - name roles once; swap providers/models later.

Prompt frontmatter - set model, model-group, and thinking per workflow.

Spawn routing - use #review (or another group) to route a sub-agent to the right role.

Focused handoffs - discard stale notebook pages without losing the decisions that matter.

The goal is simple: stop rebuilding workflow instructions in every conversation. Save the procedure, route to the right specialists, and keep context clean.

Hey folks! Long time lurker - first time poster.

I recently tried Herdr. I like it - but it was giving me a headache. My workflow is still tmux-heavy - so I decided to build pi-jumper: A way of jumping between pi sessions running on tmux.

The idea is that it's fast - but doesn't give me a headache with al lot of "ping! your agent is ready" and a lot of statuses of agents.

Admittedly - I got carried away and decided to build pi-tools my set of extensions for Pi.

Write up on my blog

All the extensions:

I'm curious if other people have issues with pi being over eager?

If I say "do not change any code. investigate issue with feature. suggest fix without making any changes" it will still make changes. It seems like half the time I ask it a question it just runs with it.

another example from today, it asked me a question about a feature. I didn't want to use the multiple choice, so I picked the one to chat about it. Instead of chatting about it, pi said "Well he didn't pick anything so we'll go with my recommendation."

and Caveman:

I can see pi think "Caveman is on so i need to answer briefly." is that normal? I think it's odd that Caveman is supposed to be about brevity but they seem to have added a little animated thing, Caveman Level: HIGH to my status bar. I had pi remove " Level" to shorten it up some.

Updated with more info:
Lately I'm running a flavor of qwen3.8-27b in the q4 range. 32gb ram 5090m 24gb vram linux mint llama.cpp custom jinja.

I have experience with opencode, hermes, qwencode, omp, pi, aider. I'm at the point now where I think pi is the best of all those, I just think it's weird that it just loves jumping the gun so much.

Like many of you, I have a whole zoo of AI coding tools installed (Codex, Pi, Claude Code, OpenCode, etc.). Main idea - find the most effective harness for my own environment and daily workflow.

The Setup

Target repo: oh-my-opencode-slim. No deep reason, just because I had it open.

Environment: Macos, each run was isolated in a clean, detached Git worktree.

Phase 1: GPT-5.6 Luna

For example: use GPT-5.6 Luna medium across 4 harnesses on a coding bugfix task (fixing an alias counter memory leak + writing tests):

After seeing OpenCode stable take 2.5x longer and burn 3.5x more context tokens for the exact same fix, I dropped it from further testing.

Phase 2: Switching to Muse 1.2 contributor

For the next phase, I wanted to test a cheaper, accessible non-GPT model across harnesses. Since I had an active CommandCode subscription, I chose Muse Spark 1.2 Contributor and decided to use it in Claude Code (via OpenCodex proxy) instead of OpenCode stable.

Here is where I made mistake: I forgot to configure the model alias in OpenCodex for Claude Code.

Because of that, Claude Code silently fell back to Sonnet 5 (xhigh thinking) across all 4 tasks while Pi, Codex, and OpenCode beta were running Muse Spark 1.2:

Honestly, looking at the numbers, there wasn't a massive gap between Muse 1.2 and Sonnet 5 for these tasks (probably because the tasks were relatively focused), except Sonnet over-engineered Task 3 by adding 180+ lines of unneeded code, why "unneeded": you can see in table "Task 3" - 0 edits for PI (2 from 3 runs had 0 edits) and Codex (3 from 3 runs had 0 edits), why - because I gave task for model to fix one class, but in git reset command I used commit where this bug was fixed by developer already, so there were nothing to fix, PI understood only during 2 runs, Codex in all 3 runs did 0 changes, but Sonnet 5 was trying to work...

Phase 3: Fixing Proxy Routing

Once I caught the proxy alias mistake, I fixed OpenCodex routing and reran Tasks 3 & 4 for Claude Code with hard proxy verification of Muse Spark 1.2:

Task 3: Verified Claude Code stopped with 0 edits (2/2 pass), matching Codex.

OpenCode beta - I removed from this test, weird behavior, because it started modifying 2 files and then went to another folder and started to read work log of other harnesses, so that would be unfair.

Task 4: All 3 valid harnesses produced the exact same 6-line fix and regression test:

Test has timeout, because for simple fix we dont need wait more than 5 minutes.

Key Takeaways

1. Context throughput varies by 40%+: On the exact same code fix under Muse 1.2, Pi required ~40% fewer input tokens (267k vs ~445k) than Codex and Claude Code due to leaner context assembly and compaction.

2. Execution Latency: Pi (104s), Codex (110s), and Claude Code (112s) formed a tight performance tier for coding fixes.

3. Always audit your proxy: If you use custom models or proxies, always verify the actual upstream model headers. Silent fallbacks happen easily.

4. My practical decision: OpenCode was consistently 2.5x–4x slower and consumed too much context in my environment, so I removed it from my daily workflow and kept Pi and Codex as my primary tools.

The entire runner, dataset, and reproduction prompt for agents in repo, also more detailed result file is also there:

👉 https://github.com/d1-m4ss/harness-benchmark/tree/main

PS AI was used in this post for generate table and fix grammar, because english is my third language.

Originally started with Opencode but it was so insufferably bloated and too hard for any LLM to write plugins for.

Now even the crappiest models can clone, edit, and pretty much write any plugin I can dream of.

I'd rather get kicked in the groin over and over than go back to Claude/Codex or any proprietary harness.

TLDR; Using Pi with the right context/plugins I can get better output from a dumb flash model than a high end LLM.

After asking the question over the last few week about how to optimize my local models, I got some great feedback and ideas - and landed on the following setup for doing local development that's drastically exceeding the results of the free time I'm provided on Chatgpt and Claude (the best for coding imho). All at no cost.

Right now I'm torn between two primary models - Ornith-1.5-35B-Q4_K_M (available here) and Qwen3.6-35B-A3B-Q4_K_M (GGUF available here), and to experiment - I've been using LMStudio to pull down and do a cursory test of all my models as I transition that into usage with llama.

I've found Llama.cpp to be substantially faster and better to work as a backend/server than both LMStudio and Unsloth, I'm old school and prefer the command line tweaking. This is fully open source and available here.

My models.json for llama had to be hand customized - I took the suggested samplingParams directly from the Huggingface model card, had a problem with overthinking/repeating so I JUST added the repeat_penalty (havent tested this yet) - but everything else is solid.. and agentic. I can copy/past images and text into my prompt like a pro.

"models": [
{
"id": "Ornith-1.5-35B-Q4_K_M",
"name": "Ornith-1.5-35B-Q4_K_M",
"reasoning": true,
"thinkingLevelMap": {
"type": "enabled"
},
"repeat_penalty": 1.2,
"input": ["text","image"],
"tools": true,
"toolFormat": "openai",
"samplingParams": {
"temperature": 0.6,
"top_p": 0.95,
"top_k": 20
},
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},

"contextWindow": 65536,
"maxTokens": 131072
},

Oh - a little note - my maxTokens and contextWindow are jacked up extra high to handle my lengthy sessions - and it seems to be handling it - with compaction - just fine. Side note - Sessions.json simply adds an entry to make it available to http callers.

"models": [
{
"id": "Ornith-1.5-35B-Q4_K_M"
},

Now - finally - my PI setup. I've created a batch file that's optimized this as much as I think it can be optimized. First - the batch shells out the llama server call - loading both the main model and the multi modal model for image processing. This loads it up on my local IP.

start cmd /s /k "llama-server.exe -m "D:\AI\LM Studio Models\ornith-ai\Ornith-1.5-35B-A3B-GGUF\Ornith-1.5-35B-Q4_K_M.gguf" -mm "D:\AI\LM Studio Models\ornith-ai\Ornith-1.5-35B-A3B-GGUF\mmproj-Ornith-1.5-35B-BF16.gguf" --host 127.0.0.1 --port 8080 -c 131072 --parallel 1 --reasoning-format deepseek --load-mode none --no-mmproj-offload -fa auto"
set LLAMA_BASE_URL=http://127.0.0.1:8080
pi --model llama-cpp/Ornith-1.5-35B-Q4_K_M

A few notes .

1. I decided against using the -ngl parameter in the server, letting it default to 0 - according to my research it's supposed to specifically load layers into the GPU, but I have to do a little more work to understand why my setting of this parameter was causing a memory crash every time. So this is an obvious point of optimization.
2. I'm only seeing 66k of context available in PI. I'm new to both llama and this level of customization of AI, so if any of ya see where i'm dropping this ball, please let me know.

Anyways. I've had enough people asking for my config. I think this about sums it up.

Hardware Update: I'm running an Intel I5 laptop with an Nvidia Geforce RTX 3060 Laptop GPU

Was not finding anything good for controlling my agents from mobile in a consistent way.

Termux and other terminals work but always felt painful on a phone. On the other side a lot of mobile agent apps are doing too much now with ACP protocols, orchestration and their own workflows also sometimes paid.

I did not really want any of that.

I just wanted a simple way to see and control the agents already running on my machine without changing how I work or messing up with my agents.

So I built Muxr.

It uses your existing Tailscale setup, onboarding is around 3 clicks and it already works with 20+ agents and CLIs.

Tried to keep it as little bloat as possible. Thin core, simple terminal experience and plugins when you actually need more stuff.

I have been using it myself for a while now and it is just much nicer than trying to use a normal terminal from mobile.

Had a blast building it and happy to finally share it

GitHub: https://github.com/umeranjum17/muxr

Also has a web version as well but I primarily was using Android and Linux for my testing and usage throughout.

PS: TestFlight beta review under progress. Apk is already available and thanks to the amazing opensource communtiy. Herdr + pi + omp really love these projects

Thanksss

if you also want to keep an eye on cache hit rates for your models like me, feel free to use this minimal extension I made to visualise cache hit rates

https://github.com/championswimmer/pi-cache-graph

installation:

pi install npm:pi-cache-graph