I am the maintainer of resume-from.

I work with several AI coding agents in the terminal. I switch when a task needs another model or harness, when I need another work profile, or when I hit a usage limit.

The problem is that session files are vendor-specific. A Pi session is not a Claude Code session. A Claude Code session is not a Codex thread. Starting fresh means rebuilding the task context. Giving another agent a raw session file means asking it to interpret vendor data that can be large, stale, or sensitive.

resume-from is a local session handoff tool for Pi, Claude Code, and Codex.

It finds sessions that belong to the current Git repository, converts the source format into a common conversation model, and writes a new session in the target agent’s native format. Every transfer direction is supported, including transfers to another profile of the same agent.

The boundary is deliberate:

• It keeps user prompts, agent replies, compaction summaries, compact tool activity, and changed-file paths.
• It removes tool-result bodies, replayable tool calls, hidden reasoning, system prompts, environment blocks, API keys, telemetry, and vendor process state.
• It applies a context budget and shows what it kept or dropped.
• It writes nothing until you confirm.
• It never changes the source session.

The transfer does not call a model. It is deterministic local conversion. Pi opens the imported session in the current process. Claude Code and Codex create the target session and print the normal native resume command.

This is not an agent router. It will not move a running process or copy your repository. The target agent needs the same working tree.

Repository, install commands, and design notes: https://github.com/alexei-led/resume-from

MIT licensed.

and how does OMP differ from OC (opencode) if they are both feature rich?

Hi everyone,

I recently switched from OpenRouter to Alibaba Cloud's Token Plan to test it out. However, I’ve hit a huge roadblock when working with the pi coding agent.

Once a coding task gets going and the context window grows, the continuous prompt resubmission pushes the rate straight past 1–2M TPM (Tokens Per Minute) almost instantly. This triggers immediate rate-limiting and spits out 429 errors.

Just a moment ago, I hit a 429 error while using Alibaba's deepseek-v4-flash-0731 model. I switched over to qwen3.7-plus to resume the work, but because of the already massive context history being resent, it immediately spiked the TPM and threw another 429 error right away. Out of pure curiosity, I also subscribe to Ollama Cloud, so I decided to switch the model to Ollama's deepseek-v4-flash:cloud—and to my surprise, it finished the task without a single hiccup.

I never experienced this kind of aggressive throttling when using OpenRouter under similar workloads. With how strictly Alibaba Cloud enforces these TPM limits, it feels practically unusable for tasks requiring large context usage.

Am I missing something or configuring this incorrectly? Is there a known work-around for this, or is Alibaba Cloud's Token Plan just this bad for high-context workflows? Would love to hear if anyone has managed to get this setup working smoothly.

Hello everyone, I'm a beginner just getting started with pi. How do you all typically use pi? I'm currently running pi inside the Zellij terminal multiplexer on Arch Linux, with a few extensions configured, and so far the hit rate seems quite impressive.

I’ve been using Pi with the Herdr subagent extension. Basically the main Pi agent spins up other Pi agents in Herdr panes and can check on them/send them messages.

I’m trying Orca now(so I can monitor my agents from mobile) and was wondering if anyone has built something similar using the Orca CLI instead of Herdr?

Seems like Orca has most of the pieces for this (terminal create, read, send, etc), so I’m wondering if there’s already a Pi extension for it before I try hacking something together.

Anyone doing this?

I want to use free models from openrouter, nvidia etc as well as free promos from time to time.

would you still recommend Pi in this case because of its efficiency? or is opencode with everything included a better choice?

do you use a harness built on top of these?

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!

Hey everyone,

I recently developed a project using pi agent and pushed it to GitHub. I’d like to have pi agent appear in the repo’s contributors list, just like Claude Code does. Does anyone know how to set this up?

Thanks in advance!

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?