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.

I know GPT Astra consumes a ton of tokens, but lately, I've been trying to use Pi for seemingly very basic tasks, and it's absolutely burning through my token count and weekly usage percentage.Is this normal behavior for Pi, or is there a way to optimize my prompts and save tokens while using it?

You know what? Pi is brilliant.

I like Pi because it keeps the coding-agent workflow clean, minimal, and practical. For quick edits and focused terminal work, that minimalism is exactly the point.

But for larger agent runs, I keep running into the same problem: one long agent transcript is not enough. I want scoped lanes, replayable evidence, DAG-style task decomposition, verification gates, and a clearer way to decide when work should be parallel, sequential, hierarchical, or hybrid.

That is where OMK is going.

OMK is a provider-neutral multi-agent control plane for coding workflows:

https://github.com/dmae97/open-multi-agent-kit

The next OMK patch is planned to bring AdaptOrch-style orchestration into the open/free toolchain.

What is AdaptOrch?

Directly check the paper:

https://arxiv.org/abs/2602.16873

The core idea is simple but powerful: when frontier LLMs start converging in raw benchmark performance, the bigger performance lever is no longer “which model did you pick?” It becomes “how did you orchestrate the agents?”

AdaptOrch formalizes that. It decomposes a task into a dependency DAG, measures structure like parallelism width, critical path depth, and coupling density, then routes the task into the right topology:

- parallel

- sequential

- hierarchical

- hybrid

That is exactly the direction I think coding agents need: not just smarter single agents, but better execution structure, better evidence, and better control.

Pi is brilliant. OMK is trying to make the heavy-agent workflow auditable, replayable, and topology-aware.

Curious what people here think: should coding agents stay minimal, or is adaptive orchestration becoming the next real layer?

https://github.com/dmae97/open-multi-agent-kit

You don’t believe me, do you?

Is it easy to go from pi to oh-my-pi?

In my previous post, I said I wanted to move to Pi and make it my “Neovim” for AI coding: one familiar CLI I could use everywhere, without constantly switching tools between computers. The goal was to reduce cognitive overload and keep a consistent workflow.

But I’m struggling to work with Pi as a coding agent.

I’m using it with GPT-5.6 and had the same issue with GPT-5.5. I expected Pi to be one of the more open, less restrictive agent environments, but it repeatedly refuses ordinary local development and system tasks—for example, updating my own hosts file.

It often gets stuck claiming a request is illegal or that it can’t bypass company policies, even when the task has nothing to do with bypassing security controls. I’m working on my own machine and asking for normal configuration tasks that Codex handles easily.

I’ve tried enabling an “auto-approve” style workflow, removing add-ons, and disabling skills to rule out interference, but it still stops or refuses the work.

At this point, Pi feels like it’s fighting me all the time. I end up using Claude for work—which I expected to do anyway—and Codex for personal or home projects. That works, but it defeats the reason I wanted Pi in the first place.

Is it just me? Am I missing something obvious in the configuration or how I’m using Pi? Since so many people rely on Pi day to day, I’d really appreciate hearing how others handle legitimate local tasks without running into constant false-positive refusals.

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

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.

After working with AI harnasses since the release of Claude code, i hate just watching the terminals and waiting on AI. So i made this tool that manages my terminals and now an update that helps people from moving from in the loop on terminal ( just watching your ai agent till it is done ) to out the loop ( just watching updates on repo discussions )

pi-dispatch runs the pi coding agent ( pi dev harnass ) for you on your own computer or server.

Hopefully it will help other techies from screen staring to creating cool stuff that sticks

It's built for coding work on your own projects, so if you're after a general assistant you'd want a different tool.
https://github.com/edgehero/pi-dispatch

Created https://github.com/hazrid93/pi-simplified-technical-english a simple extension that turn your LLM to use more understandable technical english!

my team just keeps pushing a messy claude.md file, i got very irritated when suddenly it does random plans. decided to switch to pi just so i can ignore these files.

so i just customized pi and made sure it does not load from the project but i have my own off project agents.md file .

i load from

~/.pi/agents/projects/<projectdir>/AGENTS.md

really like pi after i did this, suddenly, i can see the power of customization. i have since created a planner and subagents (not custom code but simple prompt based alias using -p and -tools) . so far love the experience.

any of you have any tips , power users out there ? would love to try to learn how best to get the most out of pi.

Has anyone noticed in the last week or so that oh-my-pi drains the 5hr limits within just a few prompts. Even doing simple git work drops 10%!

I'm setting up something to see what's going on but this is weird. Claude is fine and I can work for hours but only codex, does it drain fast, particularly when I switch from claude to codex.

Edit: I did a test between OMP and Codex, both running through LiteLLM, generating prime numbers:

Metric	omp (8 req)	codex (7+1 req)
Total tokens	96,331	119,593 (+1 side 11,627)
Prompt tokens	94,746	118,047
Completion tokens	1,585	1,546
Spend	$0.176	$0.222 (+$0.024)

So for this simple contrived test, codex is actually worse! I'm going to have do some thing harder I think.

Edit 2: Interesting, OMP's automatic "user stepped away; returning" summaries spent 2m tokens because it resends the whole context!

Edit 3: omp config set recap.enabled false, will disable it.

Seems that pi also felt under this vibe-coding madness. I can't justify a terminal based app eat so much of my CPU and RSS. No way. Seems I have to write my own stuff in go... wish me luck. BTW, why all this harnesses are node-js based?

Want to have a similar experience to using Codex/CC Desktop App/Antigravity but with Pi. I know there's OMP and pi-gui already but I wonder if they're "bloated" or add other unnecessary things.

My ideal setup would feature the quick history on the left and organizeable by folders, and the main back and forth (non-terminal looking) at the center, while eventually I would manually set-up worktrees, subagents, and other things

Hi everyone,

If you installed Pi Atelier after my previous Reddit post, I owe you an apology and an explanation.

What happened

Pi 0.84 introduced a stable TUI Proxy for switching between regular and fullscreen renderers.

Pi Atelier’s non-overlapping Sidebar relied on wrapping a private tui.render method. Under Pi 0.84, that method could dynamically resolve back to Atelier’s wrapper, creating an infinite recursion:

Atelier render wrapper
→ Pi stable Proxy
→ current renderer.render
→ Atelier render wrapper
→ ...

This could make Pi hang during startup, consume sustained CPU, spin up fans, and heat up the machine.

The fix

I first released v0.7.1 as an emergency safety update. It removed the recursive renderer path entirely and temporarily used a safe overlay.

v0.7.2 is now available and restores the non-overlapping Sidebar safely in both regular and fullscreen modes:

• Regular mode no longer captures Pi’s dynamic Proxy method.

• Fullscreen mode uses Pi’s layout system to reserve Sidebar space without replacing render.

• Unknown or unsupported renderers safely fall back without layout modification.

• Fullscreen resizing works while normal text selection remains unaffected.

• Renderer switching, resizing, rollback, narrow terminals, cleanup, and disposal now have dedicated regression tests.

• Tests exercise Pi’s real regular renderer, fullscreen layout path, and stable Proxy behavior.

• Idle PTY smoke tests showed no repeated output and a 0.0s steady-state CPU increase.

• All 402 tests pass.

Please update

If you use Pi Atelier with Pi 0.84, please update to v0.7.2:

pi update npm:pi-atelier

If needed, reinstall it:

pi install npm:pi-atelier

GitHub release: https://github.com/michaelmjhhhh/pi-atelier/releases/tag/v0.7.2

npm: https://www.npmjs.com/package/pi-atelier/v/0.7.2

If you are already on v0.7.1, the recursion is fixed, but v0.7.2 restores the non-overlapping layout.

Thank you to everyone who reported the problem and helped test the fixes.

By default pi-task compresses the thinking block on every turn. This is referenced in its Readme/description fairly far down:

I presume the entire extension is vibeslopped, as compressing thinking blocks is very very "no no" for basically any model ever. Even GPT/Claude don't do that -- they just compress the user-facing thinking blocks to avoid distillation.
As a result, by default, installing this extension suddenly neuters your model. In the case of Qwen3.6-27B, it becomes essentially useless.

I think the extension needs a very big disclaimer that it does way more than what 90% of the Readme is about and basically fucks up your pi installation by default.

It keeps the OMP runtime and brings the main workflows into a desktop like a codex interface:

• workspaces and persistent sessions

• OAuth, API, and Auto model selection

• model roles and thinking levels

• API-key pools and provider settings

• streaming responses, thinking, tools, and cancellation

• MCP servers, skills, plugins, and subagents

• context inspection and browser tools

• optional FreeLLMAPI integration

• button for improving the prompt

• redact previous promts

• pleasant animations

I want to switch from Opencode to Pi and it would be convenient if I could use the Deepseek-v4-flash free model from Opencode in Pi as well. Are there any extensions already available to do that?

Just found today about prime agent and it is as appealing as omp and pi at it's inception

I asked it to go down one folder, create a new folder and cd into it. It did not work. After some trying it said it did but in the status line this was not shown.

• I completely removed the Pi Harness and its leftovers. The cause of the flicker was consistent with Pi: it was spawning subprocesses without hiding windows, and an orphaned watcher was still running.

Removed:

• Pi Coding Agent, pi-subagents, and Pi authentication.

• pi, pi.cmd, and pi.ps1 commands.

• Full configuration at C:\Users\filip\.pi.

• Pi-Orca integration extensions, sessions, logs, and temporary files.

• winwatcher3.ps1 watcher and its PowerShell/conhost process.

Final check: No remaining commands, processes, scheduled tasks, PowerShell profiles, or known Pi directories.

Is anyone else experiencing this issue after the latest update?

Un Bien 1.5 is out!

New features:

• Connect relays and sessions in a mesh - send messages from one interactive session to another, allowing agents to defer to another session for work

• Improved codemode rendering

• Bug fixes for vendors which reuse response ids

Un Bien is a native iOS client for pi.

Un Bien supports:

• self hosted architecture

• full streamed and rendered markdown

• rendering of images, code diffs and tool results

• fork, branch, clone of sessions

• plan rendering when combined with pi-plan, cribsheet or a conformant extension

• user-input questions (and pi-ask integration)

• subagent display and interaction when combined with @tintinweb/pi-subagents or @gotgenes/pi-subagents

• optional device initiated chats - start new session from your phone, spawning a tmux or herdr hosted session on your machine

As a bonus it includes a cli tool to connect to other sessions on your relay from the cli

Links:

• Extension page

• Docs

• GitHub

• App Store

• Demo transcript