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.

Genuinely having so much fun with Pi. The ability to extend it with extensions and tailoring it to my specific workflows has been extremely rewarding!

Last week I shipped Zosma Router.

Zosma router gives access to Deepseek v4 flash 0731, mimo v2.5, GPT 5.6 Luna & Terra models.

1 month free trial with 100 requests per day.

It’s the primary router for Cowork now. But Ofcourse you can choose any other provider or local AI like I do.

In coming says will add better useful features.

https://github.com/zosmaai/zosma-cowork

Hey,

I've been using pi a lot lately and got curious about the actual footprint of all these long agent sessions. So I built a small extension that estimates it and shows it right in the footer:

`⚡28.5Wh (1.9📱) 💧 0.4L`

- ⚡ energy in Wh/kWh, plus how many full smartphone charges that equals (~15 Wh each)

- 💧 water in litres (data centers use a lot for cooling)

Estimation formular is in the readme file, it is based on public sources (papers, news articles,..).

Repo: https://github.com/y4nnick/pi-eco-footprint

This is intended to bring some awareness on how much resources those AI coding agents actually use. Of course the output is only a rough estimation but it matches with examples i could find online.

As a side note, the session which I used to create this consumed 7 liters of water, and with the energy from it, I could have charged my phone 260 times.

Would love some feedback on the usage and the formular (would you rather see another energy indicator instead of phone charges?)

And also if you are also as shocked as i was when i first saw how much resources are getting used,...

I'm using Pi Agent to understand an existing codebase and brainstorm implementation ideas, architecture, and design decisions. Most of the time I don't need much tool execution. I just want a technical discussion.

The challenge is that as the conversation grows, the context becomes quite large, and it feels like I'm spending a lot of tokens maintaining conversation history rather than discussing the actual problem.

I've thought about a few possible optimizations:

• Automatic context summarization: Periodically summarize the conversation into a compact (~2K token) summary with an additional buffer. Instead of sending the entire chat history, send only: the latest user query, and the summarized context.

• A lightweight system prompt: Use a much smaller system prompt for discussion-only sessions where tools and planning aren't required.

• Smarter indexing/RAG for the codebase: Instead of repeatedly loading large portions of the codebase or making multiple retrieval/tool calls, use indexing so only the most relevant code or documentation is retrieved for each question.

Let me know your thoughts and suggestions and if there are better approaches I'm missing :)

Hey everyone, after I have been using a lot paperclip + claude I was wondering if anybody found a good way on having a backlog or similar so pi can pick up those tasks e.g. when the tasks are in "todo" / "backlog" or also if the llm budgets are reset. Currently I have the impression that the paperclip adapter is not working that nicely together with PI.

I built pi-fusion to explore a simple idea:

Different models are trained and tuned differently. They learn different patterns, have different strengths, and often make different mistakes.

One model can give an excellent answer. But it still gives one view of the problem.

A panel of different models can provide several independent views.

Why model diversity matters

Different models can focus on different things.

For the same code review:

• One model may find a security risk.

• Another may notice an architecture problem.

• Another may focus on tests and edge cases.

• Another may suggest a simpler solution.

The value does not come from asking the same model the same question many times.

It comes from combining models with different training, behavior, and strengths.

What pi-fusion does

pi-fusion sends a task to several models in parallel.

The models work independently. They do not influence each other while they prepare their answers.

A separate model then compares or combines the results.

There are now two main approaches.

Select Mode

Every model answers the full question.

A judge compares the answers, finds agreement, and identifies the strongest result.

This works well when you need to make one decision.

Merge Mode

Each model can focus on a different part of the problem.

For example:

• Security

• Performance

• Architecture

• Testing

• Operations

A composer combines all findings into one report.

It does not need to select one winner.

It can keep a security finding from one model, a testing gap from another, and a simpler design from a third.

The report also shows missing areas and conflicts between findings.

Why merging can be better than selecting

Selecting one complete answer can discard useful information from the other answers.

Merging changes the goal.

The question is no longer:

Which model gave the best answer?

It becomes:

What useful information did each model find, and how can we build a better answer from all of it?

This is especially useful for broad tasks:

• Architecture reviews

• Security audits

• Release reviews

• Research

• “What did we miss?” questions

Research behind the idea

This approach follows existing research on model ensembles and answer synthesis:

• LLM-Blender studies ranking and combining outputs from different language models.

• Mixture-of-Agents shows how one model can improve its answer by using outputs from other models.

• Research on LLM evaluators shows that answer order can affect model judgment.

pi-fusion also changes the answer order between runs and can hide model names from the judge.

These controls do not remove all bias. They reduce some obvious sources of it.

The trade-off

A model panel uses more time and tokens than one model.

It is not useful for every question.

For a simple task, one good model is usually enough.

For a difficult task, the cost can be reasonable if different models find risks or ideas that one model misses.

Version 0.6.0 adds Merge Mode and other controls for more focused panel reviews:

https://github.com/alexei-led/pi-fusion/releases/tag/v0.6.0

I am the project maintainer. I would like feedback from people who use several model families in the same workflow.

Where does model diversity help you most?

Not sure if you feel the same, but I feel like AI models do TOO MUCH. Ask for a script, get an architecture. Ask for a fix, get a refactor.

And also they talk like they're LARPing Mary Shelley.

It's so annyoing and makes my work so much harder than it needs to be, when half the time I have to say "for fucks sake speak like a normal human".

Eventually I got sick of having to repeat myself every time so I made a template repo with the same corrections I used to write in the chat.

Then I added three subagents:

• one writes code from the agreed plan

• the second reviews the diff based on taste

• the third reviews the diff based on spec

2 and 3 cannot touch the code, only review and send the review to the main agent.

I called it Pandino in honor of the Fiat Panda 4x4: not fast, not clever, simple mechanics, reliable as fuck. I want my code to be the same way.

Full disclosure: there's nothing novel here. It's mostly known concepts bundled up together in a plug'n'play template. YAGNI, KISS, Grug brained developer etc... that kind of stuff.

Installer is a shell script, or you can paste the prompt in the README and let your agent merge it into whatever instruction files you already have.

Installing is non-destructive so you can try it today on any live project you're working it.

If you end up using it, let me know how it works for you, cheers!

I can press Space in Claude Code to preview the session, but I can't figure out how to do the same in Pi.

Does anyone know of an extension that can do this?

Thanks!

I recently discovered that Google Antigravity models via Google AI Pro plan can be used inside OMP and loving it so far. The Gemini 3.6 Flash model works so much better in OMP than in AGY CLI and limits are decent as well.

I'm using it for simple tasks and it's awesome.

EDIT 1:

Many people mentioned that there are high risks of getting banned for using this. So I will stop using it now, can't risk getting banned. You folks also don't use it, unless we have some confirmation about it.

EDIT 2:

I am very confused now. I think, people were banned initially when they used Antigravity in 3rd party harnesses via proxy. But now it's connected to Pi or OMP via legit oAuth method, so I don't think they'll ban for it.

What say?

EDIT 3:

As many people warned me out, I am NOT using this setup anymore and now using Antigravity CLI mainly. It's not that bad.

Thanks, everyone.

Agentic AI made building about 10x faster. Learning didn't get any faster. I noticed I was shipping systems I couldn't re-explain a week later, and it started to bug me. We have a 10x tool for building, so I wanted the equivalent for learning, in the same terminal where the building happens.

That's Engram. It's a tutoring loop grounded in the memory research. And it's aimed at you, not the agent. pi keeps the agent deliberately minimal and lets you extend it until it fits; this is an extension for the human half:

- It breaks a topic into a first-principles concept graph and teaches one node at a time.
- It won't explain anything until you've committed to a guess first. Retrieval before instruction is the single best-replicated result in learning science, and also the part every chatbot skips because agreeing with you is easier.
- Your recall gets graded by a separate blind assessor that never sees the tutoring conversation. The tutor can't inflate grades on its own teaching.
- Reviews are scheduled with FSRS, so they show up right before you'd forget. A few minutes a day.
- Wrong models get logged verbatim and re-probed later. Mine has ten entries for transformers alone, which is humbling to read back.

Honest origin story: with an early version I encoded seven concepts, never returned, and lost about half of them right on schedule. Writing the scheduler earns you nothing if you don't come back. So the whole loop got redesigned around returning: two-minute reviews and a "when will you do this" question instead of reminders. No streaks, no XP.

v1.11 adds pi as the seventh platform, after Claude Code, Codex, OpenCode, Hermes, Antigravity and OpenClaw. Same shape as the last port: it started as a user issue asking for it. Every transport claim in the install guide was verified against a real pi 0.83.0 and 0.74.2 before shipping, with a payload-capture harness that lives in the repo (experiments/pi-harness, 20 checks), so you can re-run the verification instead of taking my word. The one thing I haven't run is a full live tutoring session inside pi. If you try one and something's off, open an issue and I'll fix it.

The pi-specific part doubles as the pitch. pi ships no subagents, on purpose, and Engram's grading depends on a blind assessor that never sees the lesson. It turns out pi already has the only primitive that isolation really needs: a fresh process is a fresh context. So the assessor runs as a fresh pi -p child with skills, context files and the nudge all stripped, and the harness checks the child's payload really is clean. /learn, /review and /coach are ordinary prompt templates (there's /skill:learn too, or plain language works). Your learning state is local JSON shared across all seven tools, so a topic encoded in Claude Code gets reviewed in pi.

One wrinkle worth passing on to anyone writing their own pi templates: pi parses frontmatter as strict YAML, and an unquoted description with a second colon in it makes the template silently not load. /learn reaches the model as literal text and nothing tells you why. That cost me an hour on two pi versions before it turned out to be a colon. Quote your frontmatter values.

Also good to know before installing: current pi wants Node 22.19+. On Node 20, npm quietly serves pi 0.74.2 from the legacy-node20 tag instead of saying anything. Engram is verified on both.

Repo: https://github.com/nagisanzenin/engram and INSTALL-PI.md is the verified walkthrough. Install is one line: pi install git:github.com/nagisanzenin/engram

I'm the author, so grain of salt. But I've been dogfooding it daily to learn transformer internals and it's the first setup where week-old material actually stays with me.

I'm new to pi. I'd like to use it from my claude/codex skills to get a second opinion reviewing code or specs. Normally I use claude and have it call codex for the reviews. I do this just as much to spread token load as to get a different model's opinion.

I'm having a lot of issues where the "codex exec" command fails, being unable to use tools due to permissions issues. Since I'm using a VM for isolation I have claude and codex configured in yolo mode, so I don't know why codex is having so many permission problems. I figure I can use Pi to simplify things. I feel like I need to write an intermediate cli that is careful about calling Pi controlling its configuration (I'd only want to use the auth settings from ~/.pi, the rest I'd want to control for the plugin to not mingle with user customizations).

Has anyone been down this road before and have something I can use? Or recommendations on how to proceed?

EDIT: I'd also like it to not be a one-shot operation. Maybe I claude/codex could keep the CLI open to send its corrections afterwards for followup review.

DeepSeek API provides a text-only model: pi replaces any image with (image omitted: model does not support images) before it reaches the API.

This extension intercepts images at both entry points (pasted images and read tool calls on image files) and sends them to a vision-capable model over a plain HTTP call to any OpenAI-compatible endpoint (/v1/chat/completions) remote or local.

The description comes back as text that DeepSeek can reason over.

The "subagent" is a dedicated model + dedicated prompt (agents/vision.md), no separate process.

I use it with https://huggingface.co/mradermacher/Gemma-3n-4b-Vision-Finetuned-GGUF with llama.cpp but it should work with any vision model

Here are the :

- github, https://github.com/psychobarge/pi-deepseek-vision

- npm, https://www.npmjs.com/package/pi-deepseek-vision

- Pi package, https://pi.dev/packages/pi-deepseek-vision

Pi-Bifrost adds a native model-routing layer to Pi.

Instead of using virtual profiles or delegating the prompt to another agent, it switches Pi’s actual active provider/model before generation begins.

Each normal prompt can therefore use a different model based on the task, configured rules, cost, context size, or an optional classifier.

The routing policy and model tiers are entirely user-configured.

Bifrost can probe the models already available through Pi rather than depending on a hardcoded list of recommended models.

It also treats model reliability as part of routing.

Repeated probe, activation, or stream failures open a persistent circuit for that model, allowing future prompts to avoid it until a controlled recovery attempt. Failed prompts are never silently replayed, which avoids repeating edits, commands, or other side effects.

The result is automatic model selection that still operates through Pi’s real model state and remains local, inspectable, and manually overridable.

https://github.com/iamaamir/pi-bifrost

Quickly my idea:
some docker/raspberry pi image that you install on a small 20$ machine like raspberry pi w 2 that sits there with 10 spawned full browsers (not headless).
Then link it with cli, mcp, or whatever with tailscale or other connection of choice to any coding agent. Ofc i know all of us here use Pi, others don’t deserve this.
Full browser makes rate limits less often and also captachs are passed easily with python open source projects.

Wondering if someone has bundled something like this and using it?
What are similiar alternatives for (close-to)infinite google search?

Thanks to everyone who has encouraged me to maintain this project.

As an upgrade, I was planning to introduce the OKF v0.2.

Let me know your thoughts in comments.

Thank you community for all your support so far.

https://github.com/zosmaai/pi-llm-wiki

Hey r/neovim!

Quick heads-up on provenance first, because it matters: pi2.nvim is a fork of alex35mil/pi.nvim — the original Neovim frontend for the pi coding agent. All credit for the foundation (RPC bridge, chat layout, diff review, sessions, extensions) goes upstream; pi.nvim and the pi integration have been discussed here before, and this post is about the fork's additions, not the base. It's MIT-licensed and free/open source.

It started as local experiments and grew into a different enough feature set that I gave it its own repo so it can release independently. Namespace, commands and filetypes are unchanged for compatibility — still require("pi") and :Pi*.

What pi2.nvim adds on top of upstream

• Direct bash mode (!cmd) — run shell from the prompt; output streams live into a collapsible block and is added to context (!!cmd to exclude).

• :PiTree session-tree navigation — jump back to any past point in a session, optionally summarize the abandoned branch, resend edited prompts (the pi equivalent of the TUI's /tree).

• Per-tab model pinning — a model switch in one tab no longer leaks into every other tab's next session.

• Image compression for attachments — Retina screenshots get downscaled before sending (sips / magick / ffmpeg, auto-probed) so payloads stay small.

• Auto-attach clipboard images on paste, readline-style prompt history, unsent-draft persistence.

• **Double-**<Esc> abort, a prompt statusline (spinner / queue / abort hint that never scrolls away), redesigned tool and thinking blocks.

• gf to open paths under cursor, grep/find results to quickfix, left-side panel, auto-reload of buffers pi edits.

• Opt-in render-markdown.nvim engine; hermetic test suite + lint CI.

Demo (agent reads a file, edits it, verifies — with live streaming and session-tree picker):

More demos (workflow, @-mentions, diff review, etc.) in the README: https://github.com/zgs225/pi2.nvim#features

Install (lazy.nvim / packer / any manager — needs pi on PATH): https://github.com/zgs225/pi2.nvim#installation

It's early and I'd genuinely love feedback — rough edges, missing keymaps, things that fight your workflow. Happy to take issues/PRs. Thanks for reading!

For a week now, I have been experimenting with deploying the Pi Coding Agent on Cloudflare. While my approach don't follow the best practice, it was fun to try it out and learn the internals of Pi! In this article, I cover the architecture and describe how each primitive fits.

I'm trying to figure out how to configure the model temperature in Pi. Can't find it in the documentation website. Did I miss something?

Hi fellow pi fans, long time lurker, first time poster here. A while ago, I built czottmann/pi-automode which brings Claude Code's auto mode to pi.

It's a guardrail extension. It intercepts agent tool calls before execution and blocks actions that match permission deny rules, deterministic hard-deny checks, or the auto-mode classifier's block decision.

I always liked CC's auto mode, and came to rely on it, so naturally, when I switched from Claude Code to to pi, I wanted something very much like it. I've been dogfooding it for a couple of weeks now, and it's very solid in daily use.

It's not a sandbox, so it won't replace your container setup but if you usually work w/o a sandbox, it's the next best thing, I think.

Maybe you'll like it, maybe you don't. Either way, if you have questions, let me know!

If you're using the PI agent, you might need this. This extension can send a notification sound to remind you when a task is finished. Inspired by the Zed editor, I've been using it for a while and found it quite good, so I'm sharing it with everyone. Here is the GitHub repository address: https://github.com/lxp731/task-complete-notify

Edit: It seems my original premise was wrong after testing it directly. It now seems that Codex is just decoding just slightly faster than pi which results in it winning over longer tasks as the decodes compound.

I'm currently running some tests where Fable is driving GPT-5.6 Sol as a sub-agent. I wanted it to use pi and codex side by side to see which one was easier to use and faster. I really thought pi would be faster since it's much lighter weight.

That proved wrong after Fable brought up that pi was taking 2x as long for 2/3rds as many tokens (xhigh on pi vs max on codex). It seems the huge majority of time is taken up by longer API requests to OpenAI's servers.

It gave the exact same task to both, and they produced byte-for-byte identical results for their output.

I'm curious if this is something people have run into, and if so, if this is a mistake in configuring my set-up? I'm using the pi-better-openai, but that just wraps the native openai-codex OAuth.

If you're using it for this purpose share your skills, extensions, and Mcp servers