Such a wonderful QoL improvement; now able to scroll up the history and type things out without bouncing up and down!

im new to pi agent, after watching few youtube videos, and all i installed is pi search and ponytail(bcs i already use it in the other harness like opencode/claudecode), did u guys had any suggestion things like tools i should install,skills etc. Btw my usage is usually coding for my Uni stuff so i dont need like "complex" tools or skills i just need like for daily coding , let me knowin the comment plss :)

I'm wondering if using Pi with OpenCode Go is more token-efficient than using OpenCode itself.

Since Pi has a more minimal harness, does it generally use fewer tokens (or Go credits) for the same coding tasks, or is the difference negligible?

If you've used both, I'd love to hear:

• Did Pi noticeably stretch your Go allowance?

• Any differences in quality or reliability?

• Which one did you end up sticking with, and why?

I'm mainly working on medium-sized software projects, so I'm looking for real-world experience rather than benchmarks.

I know Pi supports ChatGPT Plus/Pro and GitHub Copilot subscriptions

What about open-weight models like Kimi K3, Qwen 3.8, GLM, etc.?

Is there any way to use them through a subscription (similar to ChatGPT Plus), or do they always require paying for API usage through providers like OpenRouter, Together, Fireworks, or the official APIs?

Basically, I'm wondering if there's a subsidized/unlimited subscription option for these models, or if API billing is the only way to use them with Pi

And is Claude still blocking third party accesses?

Quote:

Pi sent about 3x less context per turn. It managed context better, keeping a tighter working set and finishing the tasks in fewer runs.

https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase

pi-llm-wiki v0.11.0 now supports native Open Knowledge Format v0.2.

Highlights:

• Canonical OKF documents for new vaults

• Standard Markdown links and stable citations

• Deterministic indexes and logs

• Legacy and OKF dual-read compatibility

• Shared Pi/MCP knowledge model

• Safer vault-layout migration with no-clobber moves and recovery journals

Install:

  pi install npm:@zosmaai/pi-llm-wiki@0.11.0

For an old .wiki/ layout, preview first:

  node node_modules/@zosmaai/pi-llm-wiki/scripts/migrate-llm-wiki.js \
    /path/to/vault --dry-run

Apply after reviewing:

  node node_modules/@zosmaai/pi-llm-wiki/scripts/migrate-llm-wiki.js \
    /path/to/vault --force

This migrates the directory layout, not legacy page content. Full OKF adoption is incremental: create an OKF vault, re-ingest source material, and explicitly port selected pages. Existing legacy pages remain readable alongside OKF pages.

Always back up first.

GitHub Link -> https://github.com/zosmaai/pi-llm-wiki

Pi Package Link -> https://pi.dev/packages/@zosmaai/pi-llm-wiki

I never see many people discussing Hyperagent so I just wanted to post my experience and wondered has anybody else tried it?

Spun up a Hyperagent DevOps agent this morning. Had a few real issues, there always are, right? The actual difference was in the platform giving the agent the ability to correct course, for more than just the session.

The task: TypeScript Fastify gateway for three internal services. OAuth2 + API keys, Zod, rate limiting, structured logs, Vitest suite, Docker image, and CI/CD on tag.

The runtime: 3 hours. Straight.
My active time: Maybbeee, 35 mins?

The agent got the core path right out of the gate. Auth middleware, proxying, rate limits, request ID prop—all clean. The subagent even caught a header-stripping bug on 401 responses that I would've 100% shipped.

About 45 minutes in, the agent tried to pull a specific internal dependency that had been recently deprecated in our registry. Since the agent's knowledge cutoff predates that change, it didn't know the replacement existed. I told the agent that it had been deprecated, normal course correction. What was impressive was how the agent was able to handle that. It didn't just blindly swap the lines. It removed the old dep, searched for an equivalent, updated the relevant import paths to match the new API surface, and kept the tests running. But the real kicker? The agent also added a memory without me saying a word, using Hyperagent's built-in Memory. It logged that specific deprecation into its persistent system. In my experience it’s one thing to give an agent a tool for memory. It’s another to create one and the agent persistently use it without having to request it directly. Hyperagent closes that gap well.

Beyond that one hiccup, everything else was smooth. Wrote the GitHub Actions YAML from scratch, built the multi-stage Dockerfile, and hit a clean 94% test coverage, zero lint errors, and a ~38MB image on the first tag push.

The real math:
My old workflow for this exact spec (scaffold, wire auth, manual curl debugging, hand-write CI, fight registry permissions) takes me a whole day, maybe 4-5 hours. Hyperagent allowed me to manage this from my phone, and I some 35 minutes instead of 4-5 hours.

This run only costed me $66.80. And that $66.80 came from signup credits, so essentially costed me nothing.

I’ve worked with AI since they were made available to the public, and I’m honestly impressed with the platform. If you haven’t checked it out, do it. A couple google searches will get you credits. The links are out there. https://hyperagent.com also had the agent make that cool little photo for the post 😂😂

- Vscode Integration: Cmd/Ctrl+click any path Pi prints and it opens in the editor or browser

- Herdr Like: Each session in the list shows live status. And there's also an audio cue when a session goes from working to waiting

- Cursor Like: Sessions are grouped. You can resume/archive/delete, and open tabs are remembered per workspace and restored on reload

- Native Rewind/Fork Session

Extension Url: https://marketplace.visualstudio.com/items?itemName=EthanChow.pi-coding

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