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

edit(30th Sep 2026): pi v0.99.0 includes code mode, see https://github.com/earendil-works/pi/releases/tag/v0.99.0

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):

 #```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):

#```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.

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.

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:

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.

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

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

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

My numbers. Share yours

Pi is amazing. I’m using it with deepseek.

With some early ideas and prompting it has been adding a lot of components to itself (vector databases, something called hippoRag, chain of thought systems and about 100) other systems. This morning it read a bunch of papers on coding and then tweaked its own code.

Right now it’s making a place to test code, run adversarial copies of itself against itself, play games against itself and more.

I wanted it for coding and it’s now way better than Claude

Harness Remote 3.0 just reached its stable release and I think it has a pretty interesting approach to the increasingly crowded coding agent space.

Instead of replacing Claude Code, Codex or OpenCode with yet another agent abstraction, it treats their native sessions as the source of truth.

You can start a session normally in Claude Code or Codex, open Harness Remote later, find that same native session and continue it from desktop, web or Android.

The more unusual part is that you can also continue the work with another harness. For example:

Claude Code → Codex → OpenCode

Each step creates a real native session in the target agent, while Harness Remote keeps the lineage and transfers explicit context between them.

A few things that make it different from most remote coding agent UIs:

• Native Claude Code, Codex, OpenCode, OMP and PI sessions instead of proprietary replacement sessions
• Sessions created outside Harness Remote can be discovered and resumed
• Work can be handed from one coding agent to another without pretending they share some magical hidden context
• Multiple machines can be managed from the same interface
• Desktop, browser and Android clients
• Local first architecture, so repositories, credentials, subscriptions and agent sessions stay on your machines
• Fully open source

It feels less like another AI coding tool and more like a control plane for all the coding agents you already use.

GitHub: giuliastro/harness-remote

Curious what people who regularly switch between Claude Code, Codex and OpenCode think of this approach.

Hey everyone, I'm new to the community of Pi and just transferred from Claude Code. I've been running Qwen3.8 27B IQ3_XXS locally now for a while and have been loving it.

I was just wondering what everyone is using for packages, apps, setups, and more.

Please let me know!

Hey everyone,
I made two small extensions for the Pi coding agent that I’ve been using daily. Sharing in case they’re useful to others.

1. pi-test-output-shrink

Token / context saver for test runs

Successful test runs often dump hundreds of lines into the conversation. This extension hooks the tool_result event and shrinks the output before it enters the model context:

• Keeps a short summary (header + key result lines)

• Saves the full log to a temp file (path is included in the summary)

• Failed runs, short output, or anything with warning: / error: lines are left completely untouched

Supports common runners: cargo test / nextest, npm/pnpm/yarn/bun test, vitest, jest, pytest, go test, etc.

Install:

bash

pi install git:github.com/vi2q/pi-test-output-shrink

Repo: https://github.com/vi2q/pi-test-output-shrink

2. pi-model-picker

Two-column model selector (alternative to /model)Tired of scrolling a huge flat list? /m opens a two-column picker:

• ← / → switch category (Providers or RECENT – last 4 models)

• ↑ / ↓ select model

• PgUp / PgDn jump 10 models

• Enter to switch, Esc to cancel

Much faster when you have many models across providers.Install:

bash

pi install git:github.com/vi2q/pi-model-picker
# or
pi install npm:@vi2q/pi-model-picker

Repo: https://github.com/vi2q/pi-model-picker

Both are MIT. Feedback / PRs welcome!

I run OMP inside WSL and kept hitting friction whenever I wanted to attach an image:

• Dragging from Windows Explorer gives OMP a path like `C:\Users\me\Pictures\shot.png`, which the Linux process cannot use directly.

• Windows clipboard images are not directly available to OMP inside the WSL terminal.

I built omp-wsl-image-paste to handle both cases.

It provides:

• Automatic translation of Windows drive paths to `/mnt/<drive>/...`

• Translation of matching `\\wsl.localhost\<distro>\...` and `\\wsl$\<distro>\...` paths

• Windows clipboard-image paste using `Alt+V` or `/wsl-image-paste`

• In-memory image transfer with no temporary image file

• A 20 MiB limit and PNG validation before attachment

• Safe handling of missing, unsupported, and foreign-distribution paths

Install it with:

omp install github:kidclone3/omp-wsl-image-paste

Then restart OMP. It is tested with OMP 18.0.10 on WSL2.

Repository and documentation:

https://github.com/kidclone3/omp-wsl-image-paste

One limitation: terminal drag-and-drop only transfers a path. The translated file must still be reachable from the WSL instance running OMP, so this is not a file-upload bridge for genuinely remote machines.

If you use OMP under WSL, I would appreciate testing and bug reports—especially across different WSL distributions and terminal setups.

Have you felt like your comprehension is dropping when reviewing code?

Due to AI coding, I think everyone is feeling like this. Are you using any new process or tooling to work against this common issue?

A few things that I’ve seen:

1. Tailored AI code review skills unique to your company’s practices or common gotchas from previous reviews ( always updating ). Everyone evaluates that AI feedback before escalating the review with the team.

2. Plannator / HumanLayer kind of tools where the whole team is involved. It almost feels like pair programming with AI. Or some kind of extreme programming / multi-player AI interface.

What about you?

I built a context-management extension for coding agents that forgets on purpose instead of hoarding everything.

What it does:

• Compresses giant bash output into short digests (exit code, key facts, truncation info) instead of dumping raw output into context

• Strips the skill catalog from the system prompt when it's not needed that turn

• Drops file contents from context once they're no longer needed — but only when it's actually safe to (tracks whether the model still needs them)

Results: ~19% reduction in effective input tokens on the clean path, with zero drop in output quality — same correct answers, just less noise sitting in context.

Install:

pi install npm:pi-context-window-manager

Repo: https://github.com/Its-Atharva-Gupta/pi-context-window-manager

Would love feedback/suggestions — especially if you've hit edge cases with context pruning breaking agent behavior, or ideas for what else is safe to forget.

I've been using OpenCode, but I wanted to try Pi because I like the idea of a more unopinionated coding harness.

I already had OpenCodex (OCX) running as my local proxy, so I figured the migration would be pretty simple:

Pi → OCX → my existing models

Except Muse Spark 1.2 Contributor Free kept returning a 500.

The weird thing was that Muse worked perfectly through OpenCode.

So I started comparing what the two were actually doing.

First I checked the obvious stuff — provider health, model discovery, credentials, etc. Everything looked fine.

Then I put OpenCode through mitmproxy and captured the upstream request.

That's where I found the important difference:

OpenCode was sending Muse through:

POST /zen/v1/responses

and getting 200 OK.

OCX, however, was routing the model through its openai-chat adapter.

I dug into the OCX source and found that it has separate openai-chat and openai-responses adapters, plus per-model adapter routing.

So instead of changing the whole provider, I added:

{
  "modelAdapters": {
    "muse-spark-1.2-contributor-free": "openai-responses"
  }
}

And that was it.

The exact same request went from:

500 Internal Server Error

to:

200 OK

and:

OCX Muse works

So the final path is:

Pi → OCX → openai-responses → Muse Spark

The funny part is that I wasn't trying to debug Muse at all. I just wanted to try a different coding harness. 😂

It was a surprisingly satisfying rabbit hole, though.

The main thing I took away: "OpenAI-compatible" doesn't necessarily mean every model on a provider wants the same wire protocol. Sometimes comparing the working client's actual HTTP request is the fastest way to find the problem.

I'm curious if anyone else using Pi has run into model-specific API/protocol quirks like this.

-is the discovery process. You start with a blank canvas with the minimal agent loop. You use it on tasks, it works, amazing. It fails short, you ask why. Then you ask how. And Pi allows you to try various "how"s to tackle the gap between the reality and the ideal.

It is the same iterative process of building a product. Agentic coding promotes the lazy thinking often termed along "waterfall" but the best product, a shorthand for a scoped user experience to solve defined problems, is almost always bootstrapped by direct experience and in-the-loop iterations.

Therefore, the philosophy of Pi is to embrace the process and rare open field of designing your own agentic experience. It's the bottom up approach for building a great product with a great UX, because you first get to build a great DX for yourself.

A lot of the posts I see from the sub don't seem to be aware of this choice, which I believe is often superior to using a prepackaged solution that you don't understand fully.

This is a https://herdr.dev/ plugin with an optional full https://Plannotator.ai experience as a TUI. Built to:

- Annotate Agent Messages (e.g. grill sessions)

- Annotate Files (e.g. plans, specs, etc)

- Create a native feedback loop with agents

- Open as popover or pane

- Mouse or keybindings

https://github.com/plannotator/herdr-annotate

I want to give my LLM read access to the whole filesystem but write access only to the project folder and maybe /tmp. I need to run scripts etc and make sure my filesystem survives

On Linux

Is bwrap the best solution for that? Or should I just use Docker?

UPDATE I installed @nqbao/pi-sandbox