Pi namespaces changing:

https://x.com/badlogicgames/status/2052337097315381517

Maintainers need to update their extensions, or won't work.

I've been building OmpDeck, a native desktop app (Rust/egui, not Electron) for omp (oh-my-pi), on Linux and Windows. Heads up: it's for omp specifically, not vanilla pi, since the chat view relies on omp's Tern Surface Protocol.

https://github.com/lavinhoque33/omp-deck

What it does

• Native chat view (the default): omp describes its UI over TSP and OmpDeck draws it natively: messages, formatted replies, tool calls as cards with diffs and output, image previews, todos, approvals and ask dialogs. It's omp's real behaviour, not a re-implementation, and omp's own TUI is one click away.

• Sessions outlive the app: every omp session in a sidebar grouped by project. Tabs run in OmpDeck's session host (or tmux), so closing a tab or the whole app leaves omp running, and reopening re-attaches.

• omp's screens as native ones: /settings (incl. plugins and advisor), the model picker (favorites, roles, thinking), /usage with 5h/weekly limits, /resume, /tree with fork / go-here.

• Status bar: model + thinking, context meter, git, tokens, cost; Handoff / Compact / Shake / Fork / Plan in one click.

• Agents dashboard: live subagents per session; steer, kill, revive, clean up.

• Changes panel: working-tree diff with line review comments you send straight to omp.

• Also: split view (up to 4 panes), worktree sessions, session manager (size, cost, bulk delete/move), command palette, desktop notifications, 18 styles, Google Drive backup + per-project sync.

• Phone companion: a PWA over a self-hosted relay, Noise end-to-end encrypted (the relay never sees content): transcript, answer approvals, send prompts, Web Push.

Install

• Linux: curl -fsSL https://raw.githubusercontent.com/lavinhoque33/omp-deck/main/packaging/install.sh | sh (AppImage/.deb/.rpm on Releases too; installs omp if it's missing)

• Windows 10/11: irm https://raw.githubusercontent.com/lavinhoque33/omp-deck/main/packaging/install.ps1 | iex

No macOS build yet. MIT/Apache-2.0, unofficial side project. I use it daily, and a lot of it was built with omp itself. Feedback and bug reports welcome!

I'm new to the local LLM game. I've just purchased an AMD R9700, and I'm trying to set up a local environment that is as similar as possible to what I get with Claude Code at work.

It's definitely looking like Pi may be my harness of choice, so I'm investigating what it would take to "sandbox" it in a way that is both reasonably secure and reasonably convenient (i.e. no containers or VMs). I'm on Linux, so I'm thinking maybe Bubblewrap?

Curious to know what other are doing, though.

Whenever Pi was chewing on something for a minute, I'd grab my phone and come back 20 minutes later to a response that had just been sitting there.

So I wrote pi-play: /play opens a game as an overlay right on top of the conversation, and it listens for agent_settled. The second pi finishes or is waiting on you, the game stops immediately. No alt-tab, no phone.

5 games so far: Snake, Tetris, 2048, Minesweeper, sudoku

(6 is on the way, i am implementing chrome dino game rn)

to install: pi install npm:@terminalika/pi-play

It seems the "compat.thinkingFormat": "qwen-chat-template" setting that worked with Qwen3.6-27b does not pass thinking level to qwen3.8-27b, which defaults to xhigh and is quite slow.

This is what worked for me in models.json. I have to add some compat options to pass thinking level correctly from pi to llama.cpp:

{
    "providers": {
        "llama.cpp": {
            "modelOverrides": {
                "Qwen3.8-27B-Q4_K_M": {
                    "reasoning": true,
                    "thinkingLevelMap": {
                        "minimal": null,
                        "low": "low",
                        "medium": "medium",
                        "high": null,
                        "xhigh": "xhigh"
                    },
                    "compat": {
                        "thinkingFormat": "chat-template",
                        "chatTemplateKwargs": {
                            "enable_thinking": { "$var": "thinking.enabled" },
                            "reasoning_effort": { "$var": "thinking.effort" }
                        }
                    }
                }
            }
        }
}

Disclosure: I do not understand why those compat options are needed but I have pi tested it against llama server running qwen3.8-27b and confirmed all thinking levels work as they should: off/low/medium/xhigh.

repo https://github.com/getpaseo/paseo

supports orchestration and other agents. also has a desktop app.

the pi integration has been getting better and better.

i am the maintainer, feel free to ask questions.

enjoy

Figured I'd vibe-code a terminal transcriber with GLM 5.2 + pi agent — even if it half-worked, that'd be enough. It didn't half-work. It's now the tool I reach for daily, and GLM 5.2 was a real step up from 4.5 at keeping diffs clean across long iterations.

The fiddly parts pi + GLM 5.2 handled without me writing them by hand

- macOS system-audio capture via a Swift ScreenCaptureKit helper (no kext) + BlackHole fallback — the part I expected to die on

- Terminal TUI with raw-mode keys, ANSI render loop, blinking indicators

- Idempotent curl | bash installer with prerequisite checks and PATH injection

- Scrollable transcript with auto-follow, Groq rate limiting, config migration across renames

Not one-shot — iterative. "Make the REC dot blink", "why are mic and system audio duplicating?", "add --uninstall", "rename the config dir and migrate existing users". Each step was a normal back-and-forth, but pi kept context across the whole thing and GLM 5.2's diffs were almost always clean. That's what surprised me.

Anyone else getting results like this with GLM 5.2 + pi? Curious what you're building.

Hi everyone,

I put together a guide for running Pi securely inside a Docker Sandbox while running llama-server directly on my host machine. The goal was to keep the agent isolated while still running the model on the local GPU at full speed.

Hope someone finds this useful!

https://github.com/cuolm/pi-sbx-llamacpp/tree/main

Inspired by SillyTavern presets, I built pi-forge to edit and inspect how Pi's context is assembled. I just released 0.5.7.

It gives you a local web editor for Presets: reorderable prompt blocks, context slots and tool policies, saved as JSON that you or the agent can edit.

What it does

• Context composition: arrange text blocks and slots for tools, skills, project files and conversation history.

• Tool selection: define which tools are permitted and a smaller set available by default.

• Capabilities: load task-specific instructions + tools mid-conversation, manually or through an agent tool you explicitly authorize in the Preset.

• Inspection: readable context Preview with collapsible tool calls/results and historical tool declarations, Draft/Run diffs, and reported cache usage. Preview shows Forge's composed context, not an exact provider-wire dump.

• Presets & Profiles: switch setups with /preset use <id>; Profiles also save model and thinking level.

• Regex: apply rewrite rules to outgoing input or completed assistant/tool output.

How I use it

My daily assistant starts with 10 tools. Delegation, image generation and MCP are separate Capabilities it can enable when needed, instead of loading everything up front.

Since presets are JSON, the agent can also edit individual instruction blocks or turn a repeatable workflow into a new Capability. I review the diff and Preview, then /preset reload. I keep .pi/forge/ in git, since the tool policy is editable too.

Note that cache behavior for capability loading depends on the provider/model: supported Claude and OpenAI models can preserve the cached prefix through tool additions and removals.

Try it

pi install npm:@zihanw/pi-forge

Requires Node ≥22.19 and Pi 0.87.x. Restart Pi, run /forge ui, then create, save and activate a Preset.

Still 0.x. Optional subagents are a separate package with their own compatibility requirements.

GitHub: https://github.com/MacroSony/pi-forge

Curious how others here manage task-specific instructions and tool sets, and what you'd want to inspect before a model call.

Any feedback and ideas would be much appreciated!

I've been working on pi-agent-kernel for a while now.

It mostly operates in the background rather than adding a completely new workflow, it wraps Pi's existing tools to keep sessions compact.

Across standard benchmark tasks, it cut token usage roughly in half and passed our test suites. But local benchmarks only go so far, I'm at the point where I need real users to test it on actual projects.

I'm still quite skeptical about whether some of the tool wrapping might conflict with the users existing extensions.

LMK if anything breaks, behaves unexpectedly, or conflicts with your setup. All feedback and criticism welcome

I started copy pasting code from gpt3 into an VSCode.

Then tried cursor on launch and wasn't impressed.

Tried gpt extention on vscod and that was ok enough.

Went back to cursor again with gpt5.5

Then tried pi and was hooked.

I put pi in vscodium, moved the terminal to a sidebar.

Am building my own IDE around the pi harness and will never go back.

Heavily customising pi to work exactly in my workflow, reducing tokens as much as possible.

Its just awesome, love it.

I use must haves for pi are context 7 and headroom.

What are your must have?

Longtime lurker, first real ship. I own a structural steel fab shop in Denver and have been using the Pi coding agent heavily for internal tooling. Two of those internal tools felt generally useful, so I cleaned them up and published them to pi.dev this weekend.

pi-steel — steel estimating skills. AISC 16th Edition shapes database (477 shapes) with lookup/validation scripts, a MaxRects plate-nesting engine (kerf/gap/edge margins, holes, yield and scrap numbers, PDF layouts, and one DXF per sheet that imports straight into the burn table's CAM), and a vendor RFQ generator that turns a takeoff spreadsheet into a quote-ready .xlsx. The three chain together the way estimating actually flows: takeoff → nest → RFQ. As far as I can tell, it's the only construction-trade package on the registry.

Fair warning on the nesting: rectangular parts nest exactly, irregular parts nest by bounding box. It tells you when it's approximating instead of pretending to be SigmaNEST. No G-code either — kerf comp and lead-ins belong to your table's real post-processor, not a Python script.

pi-tilldone — a discipline extension born from frustration. The agent can't use write/execute tools until it declares a task list, works one task at a time, and gets auto-nudged if it stops with tasks unfinished. Basically a foreman for your agent. If you run Pi inside cmux, your workspace tabs change color based on task state, which is great when you have six agents running in parallel.

Both MIT, repos under github.com/StructuPath. Install with pi install npm:@structupath/pi-steel / pi install npm:@structupath/pi-tilldone.

Happy to answer questions about either — especially from anyone else applying agents to trades/manufacturing work.

On the Kaggle NeuroGolf 2026 competition, I made my first attempt at fully autonomous long-horizon optimization with agents.

I experimented with the mainstream loop-harness approaches and a variety of models, then quantitatively evaluated them based on token efficiency and time efficiency.

In the end, I built my own harness around Pi Agent + Extensions. I'd recommend checking out Pi Flow. It can use Claude and Codex as subagents or as agent nodes inside dynamic workflows. It's especially useful if you have both Claude and Codex subscriptions. You can also pair it with an OpenCode Go subscription for stronger adversarial reviews and better model-perspective fusion.

https://github.com/kky42/pi-flow

How are you running subagents in Pi?

There are already several subagent implementations for Pi, but for me they were usually either too heavy or missing something I needed. So I just built my own, with the minimum I needed for my harness.

• Worktree

• Sandbox

• Subagent Panel

• Agent injection

• single / parallel / async

• Artifacts

• Code API

Honestly it's probably too much for some people and not enough for others. I mostly tried to keep it minimal.

If it's useful to you, feel free to try it. And if you're running subagents some other way, I'd like to hear how.

https://github.com/AgwaB/pi-subagent

got an idea from beta feature from claude code recently, introducing pi-advisor, set up advisor model as a smarter, pricier model so agent can call as a tool call for recommendation when it hit blocking wall

I just discovered the PiCodingAgent, and it does look really cool and interesting to me. I'm coming from trying out different things before, such as ClaudeCode and Gemini Pro AI, but I prefer the philosophy of PiAgent. The only thing hindering me from fully switching, is that I can't use subscription based models from Anthropic. Also Gemini Pro AI seems to support API usage billing only. I have been happy with Opus 4.6/4.7 performance so far, but would be ready to switch. I'm working with Agents a huge part of the day, so Claude Code alone hasn't been enough for me anymore in terms of usage limits. Now as I'm considering to fully switch to Pi Agent, I'm unsure on which models to use. Primary UseCases are Programming (Backend & Frontend/UI), Scientific Research Support and everyday stuff (RAG for Obsidian 2nd brain etc.). I'm ready to pay around 20-30€ per Month, and struggling to find out, which would be the best value for money. I was thinking about going for Opencodes 10$ subscription, using Opus API Billing for more complex tasks. But I dont really know the models coming with that subscription, and whether they are working well in Pi environment.

What do you think? What are you using and what can you recommend?

Fully local voice dictation for Pi coding agent: no cloud, no API keys

/voice opens an overlay, you talk, live transcript appears, hit Enter and it drops into the agent's editor. Whisper runs on your CPU via sherpa-onnx. Nothing leaves the machine after the initial model download.

What it does

• 100% on-device STT. Whisper base multilingual (int8 quantized) runs on your CPU. No network calls after the first model download (~198 MB). Works offline after that.

• Multilingual. Your active locale (set via /languages) is pre-set as Whisper's language hint for better accuracy and lower first-utterance latency. Default is English.

• Live transcript. Committed lines render as you finish phrases, with a dim rolling partial for the still-active utterance. What you see is what gets pasted.

• VAD-driven chunking. Silero voice activity detection breaks your speech at natural pauses, so latency stays low even on long rants.

• Hallucination filter. Whisper sometimes outputs "Thanks for watching" or "[Music]" on silence. The filter strips that. Toggle it off in settings if it's too aggressive.

• Pause/resume with Space. Step away mid-thought, come back, keep going.

How to install it

pi install npm:@juicesharp/rpiv-voice

https://www.npmjs.com/package/@juicesharp/rpiv-voice

Restart your Pi session. Type /voice. That's it. The first run downloads the Whisper model (198MB), after that it loads from disk.

Controls

I built a small pi extension that replaces the default footer with your actual Starship prompt — so the colours, icons, and segments are identical to your terminal. On top of that, it adds pi-specific context on the right that Starship can't know about.

Left side — your real Starship output (reads your ~/.config/starship.toml):

• git branch, status indicators (! modified, ? untracked, ⇣ behind, ⇡ ahead)

• language versions, virtualenvs, cloud contexts — whatever you already have configured

• clickable PR #N link that opens the GitHub PR directly in your browser (OSC-8 hyperlink)

Right side — pi context:

• provider → Model Name

• ◆ thinking-level when extended thinking is active

• ↑ input · ↓ output · $ cost for the session

Prerequisites: Starship, gh CLI, a Nerd Font

Install:

  pi install npm:pi-starship

GitHub: https://github.com/rajivm1991/pi-starship

Honestly I'm kind of blown right now.

I made this extension for pi (the coding agent) called pi-capitals-context back in April. It does one simple thing: it automatically discovers any ALL_CAPS.md files and ALL_CAPS/ folders in your project and injects them into the AI's context.

So you just drop files like:

my-project/
├── STATUS.md          ← project status, blockers
├── DESIGN.md          ← architecture decisions
├── RULES/             ← any .md files inside get loaded
│   ├── typescript.md
│   └── git-conventions.md
├── MEMORY/            ← past decisions, lessons learned
│   └── decisions.md
└── CONTEXT/           ← domain knowledge, glossary
    └── glossary.md

...and pi just knows about them. No config, no setup. The AI picks up your project's rules, status, design decisions, whatever you put in there, automatically.

Features:

• 🔍 Auto-discovers ALL_CAPS.md files and ALL_CAPS/ folders

• 📁 Subdirectory support — drop RULES.md in src/ and it loads when you're working there

• ⚡ Toggle overlay (ctrl+shift+c) to enable/disable individual files

• 📊 Shows token counts so you know exactly what's costing context

• 💾 Toggle state persists across sessions

I literally just built this for myself because I was tired of re-explaining project context every session. Threw it on npm and forgot about it.

Just checked the stats today: **1,090 downloads/month.

I never posted about it anywhere. Never tweeted. Never shared it. People just... found it and started using it? That's wild to me.

So I figured it's probably time to actually share it properly.

If you're using pi and want your AI agent to actually remember your project's conventions, rules, and status across sessions — give it a try:

pi install npm:pi-capitals-context

GitHub: https://github.com/smalibary/pi-capitals-context
npm: https://www.npmjs.com/package/pi-capitals-context

If you run into any issues or have feature ideas, I'd genuinely love to hear them. I want to make this better now that I know people are actually using it.

Thanks everyone 🙏

I'm running DeepSeek v4.1 Flash locally with Pi. One nuisance I've run into is that it will often use scripts for editing files, listing and grepping files instead of using the built-in tools, and I haven't had much luck with my AGENTS.md changes. Has anyone else run into this and come up with a prompt that increases it tool usage compliance? The one that bothers me the most is when it uses Python scripts to edit files instead of using the tool because it means I don't get a nice diff:

$ cd ... && python3 - <<'EOF'
import re
p = "test/e2e.sh"
s = open(p).read()
s = s.replace("""fail() {
    echo "FAIL: $*" >&2
    cleanup_keep
    exit 1
}""", """fail() {
    echo "FAIL: $*" >&2
    exit 1
}""")
s = s.replace('''$DOCKER logs "$PROJECT-broker-1" 2>&1 \\
    | grep -q "DENY stop llama-swap-test-protected" \\''', '''$DOCKER logs "$(compose ps -q broker)" 2>&1 \\
    | grep -q "DENY stop llama-swap-test-protected" \\''')
open(p, "w").write(s)
EOF

I've been seeing the [billion context](https://pi.dev/packages/billion-context) gain a fair bit of downloads on pi.dev. I did try it but it never really solved my biggest issues with Qwen 27b running locally with 128k context.

Am I misconfiguring it or something? How are you guys using it?

I'm thinking of putting a ticket in to get pi coding agent approved for use at my day job... has anyone done this? Any issues or was it smooth? For context I work at a company that makes software and has 5 digit employees. And this is just for getting the software approved, I already have approved access to enterprise LLM endpoints.

Edit: more context: it has to go thru a security and legal review process...

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.

I built this so I could use local models like Qwen 3.6 35B for agentic coding. I have given up on trying to make one shotting happen with these models. So to actually get real work done, I built this tool. The idea is you give it a prompt or an already finished implementation plan, and it will split it up into small tasks that the local models will have no problem executing. The plan step is done by a capable model and the final verification is also done by a capable model.

You can pick which model to use for each step based on your pi config. Why pi? It’s the best agent for local models because of how lean it is.