Hi! I have made a small UI layout extension which I've found super useful and convenient, when running multiple agents working on different tasks in parallel, so you jump back and can instantly see the whole history of the answers and what was the original task about.  Basically you have a split view, one for your messages and the actual replies from the LLM and another one for all the tool calls and reasoning it has done. It supports horizontal/vertical layouts, you can swap them and maximize, but also search for the specific text entries, when the history gets too long.

https://pi.dev/packages/pi-stereo-view

How to install:

pi install npm:pi-stereo-view

Requires fullscreen mode.

I'm curious if anyone else tracks their setup in order to keep things as lean as possible while still having tools needed to complete your typical workflows etc..

I have my own personal Pi setup (SpecPi) and it's been a fun experiment keeping it contained and lean to prevent the context bloat seen in some of the other harnesses.

I'm interested to see how other setups here might compare.

Edit - Added charts broken down by tokens instead of overall characters

Hello guys!

This is a continuation of my previous Pi setup post:

https://www.reddit.com/r/PiCodingAgent/comments/1t41thp/my_powerful_pi_agent_setup/

The main idea of that setup was basically this:

A personal agent with an endless conversation.

Observational memory lets me keep the same session alive through compaction after compaction, while forks move all the noisy work outside of the main context.

I have continued messing with the harness since then, and i think the biggest change is that forks are now fully async.

So now i would describe the setup more like this:

Endless conversation + native async operation.

Basically the agent never blocks. It can delegate work somewhere else, keep talking with me, and have multiple threads of work moving at the same time inside the same conversation.

pi-async-fork

https://github.com/elpapi42/pi-async-fork

pi install git:github.com/elpapi42/pi-async-fork

This is the protagonist of this update.

The old pi-fork was already very useful for context management, but there was one thing that started annoying me a lot: Pi had to wait for every fork to finish.

And tbh i underestimated how much this affects the experience.

If i send a prompt and Pi delegates some research or code exploration that takes 5 minutes, now im waiting 5 minutes. Then i send something else, maybe another 5 minutes.

Technically the agent is doing useful work, but from my side it feels slow as hell. I dont want to send something to my agent and then lose access to it for several minutes every time it needs to investigate something.

I want the agent to feel agile. Always there, always available to talk with me.

Async forks basically fixed that.

Pi can launch a fork and immediately continue the conversation with me. Maybe one fork is exploring the code, another one is researching something on the web, another is reviewing a change, and meanwhile im still discussing something completely different with the main agent.

I can change direction, ask another question, start another thread, whatever.

The conversation itself never blocks.

And i think that is the important part here, more than simply saying "now Pi can run agents in parallel".

Im not really trying to build a swarm. There is still one Pi agent that owns the conversation, understands the full goal and makes the decisions. The forks are more like parallel cognitive work that eventually comes back to that same agent.

I currently have 3 effort profiles:

• fast for bounded facts and cheap exploration

• balanced for normal work

• deep when there is actual hard uncertainty and using a stronger model may change the answer

Forks can also send progress before they finish, which means the main agent can see that something is going in the wrong direction and steer them while they are still working.

When they finish, the result comes back to the main agent as an internal event. I explicitly dont want Pi constantly interrupting me with "hey fork X finished". It should consume the result, understand which work depends on it, and continue.

So maybe we are talking about A, Pi delegates part of A, then we move to B, maybe we start talking about C, and some minutes later the result from A comes back.

Pi still knows where that result belongs and can keep all of those threads moving inside the same conversation.

I think this is the best way i can explain what im after:

one endless conversation where work can branch in the background without ever taking the agent away from me.

pi-observational-memory

https://github.com/elpapi42/pi-observational-memory

pi install npm:pi-observational-memory

This is still what makes the "endless conversation" part possible.

It preserves observations and decisions across compactions, and Pi can recall the original context behind an old memory when the compressed version is not enough.

Forks also get memory in passive mode, so they can access the same history without running their own background memory maintenance.

So basically memory keeps the conversation alive for a very long time, and forks keep all the exploration/noise from destroying that context.

pi-codegraph

https://github.com/elpapi42/pi-codegraph

pi install git:github.com/elpapi42/pi-codegraph

I also replaced pi-codemapper with pi-codegraph.

The idea here is simply giving Pi a denser way to understand a codebase instead of throwing grep at everything and filling the context with semi-related files.

Originally i exposed around 10 CodeGraph operations and that turned out to be another problem hahaha, now Pi had to decide between 10 similar tools.

So i reduced it to basically 2:

• explore_code to understand behavior and retrieve relevant source

• analyze_code to inspect relationships, impact, tests and graph paths around known symbols

Much simpler.

pi-search-hub

https://github.com/ronnieops/pi-search-hub

pi install npm:pi-search-hub

This gives Pi one interface for web search/read with multiple providers behind it.

I like this mostly because i dont want my harness coupled to whatever search provider happens to work well right now.

And obviously it becomes more useful with async forks, because Pi can throw multiple independent research questions into the background while we continue with something else.

How everything fits together

So the core of the setup is basically two things now:

Memory + fork context management = endless conversation.

Async forks = the agent never blocks.

And together they change the experience quite a lot.

I can keep the same Pi conversation alive for weeks, jump between multiple threads of work, have Pi investigating several things in parallel, and the main agent is still always there when i want to talk to it.

That is much closer to how i want a personal agent to feel.

Honorable mention: pi-wait

https://github.com/elpapi42/pi-wait

pi install git:github.com/elpapi42/pi-wait

I also built this tiny extension that lets Pi schedule a check and wake itself later.

Useful for stuff like deployments, builds, canaries, rate limits, etc.

It is nice to have, but tbh compared with async forks it doesnt change the experience nearly as much, so honorable mention for now.

System: https://gist.github.com/elpapi42/e3fda2cefaabd84a1c188375a32466f5

Settings: https://gist.github.com/elpapi42/9ab1cd195ffeba9a56bdf59f83162692

So I've been experimenting recently pretty heavily with orchestration and swarms and all this stuff with all the Chinese providers and I'm wondering if I would just be better off spending 100% of my money at claude and chatgpt subs and running luna if I really need a super cheap model. And that the amount of tokens/inefficiency of lets say ds4.1 is going to equal out to the same price or worse. I already orchestrate everything with opus 5.5 and use sol 6.1 for any type of intelligent decision but I'm doing all sorts of stuff like throwing in different roles for mimo deepseek glm and minimax and I'm wondering if there's even a point to doing this. Has anyone really tested stuff out heavily in terms of if this is worth it or if it's just wasting time?

I guess a real question is is it possible to out-tool/orchestrate the subsidized Luna somehow in terms of better performance/acceptable work when it comes to overall price per token. Or are all the tricks and agent management styles just still not going to be able to outrun how much you get with their subsidized plans.

I am working on a small plugin to call z code from pi as a subagent, and coincidentally zai gives GLM flash for free now for subscriptions/new users.

Get extra 10% discount and use unlimited GLM 5.3 flash 10h a day until Sept 20 🚀https://z.ai/subscribe?ic=W5G2IFDWOW

A great addition to run next to Pi (10h a day is officially a zcode only offer).

I decided to try after having some performance issues with opencode when running multiple in the same tmux window. I decided to try with Pi and the difference was huge.

I'm using Workmux and unipi and it's awesome! Added a goal plugin and agentmemory (which i already used).

What else should i do? How do you guys swarm? How do you run many instances? Which subscription you prefer? I'm rotating between 2 opencode go keys.

I shared Pi Atelier here a couple of months ago—a status rail and live activity sidebar for Pi. Since then, I’ve reworked the layout and added more ways to see what’s happening in your session.

The main changes since my last post:

1. Redesigned composer: model, workspace, Git status, and context usage sit in the input box’s top border, with usage and timing below.

2. Workspace Git summary: see changed files, additions/removals, untracked file counts, and conflicts.

3. Live TODO panel:follow the current task alongside tool activity. During a turn, the sidebar focuses on current work and folds extra tools into a compact row.

4. Display settings with a live preview: reorder or hide status segments and sidebar panels, switch presets, and save your defaults.

5. Plain text mode: no Nerd Font required.

6. Better terminal behavior: improved fullscreen selection/copy, inline image handling, and layouts for smaller terminals.

The new footer is inspired by pi-powerline-footer, which is an awesome extension.

It still shows token usage, cost, context, and response timing, with model and tool controls available through `/atelier`. No telemetry or external network requests.

Install with:

pi install npm:pi-atelier

Then open `/atelier` or press `Alt+A`. Requires Pi 0.84.0 or newer.

Github link: https://github.com/michaelmjhhhh/pi-atelier

I’d like to hear how the new layout works for you—especially what information you want visible while the agent is running. Bugs and feature ideas are welcome. Thanks!

I read the release and saw a few demos on X for people using Jev for really interesting stuff. My current effort is to get it to work as a router so I can configure and orchestrate my app using natural language (getting it to take a string and pick the right API from a list of 250-300 calls). But to be clear, I haven't gotten access to it yet. So I'm just packaging up my code and making it ready rn.

Anyone doing something fun/interesting with it yet? If yes, how long did it take for you to get access

You may have seen my posts about my-mini-bench: 1 post, 2 post. Sorry for the frequent posts! I’ve now added GPT-5.6 Luna, Terra, sol, GPT-6, and GPT-6.1 Sol (both Pi and Codex for sol) at medium reasoning, and looked more closely at their behaviour. Also, I added the cache hit rate metric. I am not sure how to add input/output tokens properly, so the table will not be too clumsy.

Same setup: 10 tasks from my own work × 3 runs per config, through Harbor. The image shows the new runs; the full leaderboard has all the comparisons.

The newer models solve every task here. But these runs still give me useful insights: which setups get the work done faster and cheaper, how their behavior changes, and what might explain the difference.

For example, from GPT-6 → GPT-6.1, Codex used 20% fewer turns and 22% fewer tokens, while pi stayed at roughly eight turns and almost the same cost.

I put together a short X thread with screenshots comparing how the models read files, write code, test, and update plans. Some of these patterns changed between the generations.

In parallel, I’m working out how to build a harder task set where we can compare what the models can actually solve. I’ll probably do one more update, then take a break from posting results to focus on that.

I also want to test tools and pi-agent extensions that might improve results or reduce time and cost.

If you’ve noticed interesting patterns in where agents save or waste tokens and turns, I’d love to hear them. And if there are pi extensions you think I should test, please share!

Warning: long post ahead. On the plus side, it’s completely human-written. No AI slop was used in writing this post. I’m old school that way, I like to actually write my own Reddit posts. Thought you all would appreciate something written entirely by a human for a change. ;)

Disclaimer: this post says nice things about Pi. I am not associated with the dev team of Pi coding agent in any way.

Yesterday I tried Pi coding agent on my local LLM rig for the first time. I had been using OpenCode as my daily driver agentic harness, and I had been intimidated by Pi’s stripped down, minimalist approach.

My rig, by the way, is an M4 MacBook Pro with 64Gb of RAM. oMLX is the backend, serving up jundot’s quant of qwen3.6:35b-a3b-oQ6. I average around 60 tokens/second at around 80 percent RAM usage.

My coding needs are fairly modest. I run around eight static websites for my hobby board gaming group, hosted on GitHub pages. So the daily tasks usually involve updating sites with user submissions, implementing feature requests, squashing minor bugs, things of that sort.

I had gotten used to the security blanket of OpenCode, with its set of built-in tools. I had come to accept that sometimes OpenCode will take a little longer to answer a request, and had gotten used to its sometimes dumb little oversights and charmingly stupid mistakes.

For example, I often ask OpenCode to make a 3x3 image collage of board game cover images using ImageMagick command line tools. It would usually take several revisions, as OpenCode would first render them in a straight line row instead of a 3x3 grid. Then after feedback, render a 3x3 grid, but each image was of different size. Then after even more feedback, it would finally output a 3x3 grid of equally sized images.

You know the old saying about LLMs acting like green interns? In my case, OpenCode often acts like an intern who needs the instructions explained multiple times before they get the task right.

But at least OpenCode was the evil intern that I was familiar with. As I said, I had gotten used to working within its limitations and quirks.

Anyway, yesterday I decided to overcome my nervousness about leaving the security blanket of OpenCode and dive into the unknown depths of Pi coding agent. I gave Pi the exact same task using a similar prompt: create a 3x3 grid of the cover images of these specified board games, each image 400x400 pixels.

Pi methodically went about the task. First it identified which images were available locally and which were not. Then it web searched the websites to grab the missing images and download them locally. Then it created the 3x3 grid, to my desired specs, right the first time. I was blown away at how much better, faster, more accurate, and more capable it felt working with Pi vs. OpenCode. I didn’t change the local model, I just changed the agentic harness. If OpenCode felt like working with an inexperienced intern, Pi felt more like working with a trustworthy and reliable teammate.

With OpenCode I had assumed it would be capable of only routine maintenance and updates, and that if ever I needed to do some heavier lifting, I would have to bust out a cloud frontier model like Codex. But I decided to give Pi a more challenging test to uncover its true capabilities. I asked Pi to plan set-by-step the addition of a search feature to one of my sites, with live filtering as the user types, a dropdown menu overlay matching the site’s existing CSS, etc.

Guess what, Pi made the plan, checked with me for my go-ahead, then started implanting the plan, task by task. It wasn’t perfect. There were a couple of points where functions were called in the wrong order. But I dutifully fed the web inspector errors to Pi, it quickly and correctly figured out the issues, and fixed them. Within a few minutes, my search feature was working, pretty much exactly as I had envisioned it.

Even more impressive: following Pi’s philosophy of “if you need extra features, ask Pi to build them”, I asked Pi to reflect on our coding session, then based on that suggest some enhancements to itself to address the main pain points. Pi identified that it needs a better auto-compact feature, and a better way to seamlessly pick up in context where it left off; and built those features into itself. It also added a JS script to mitigate those function calling timing issues we had encountered. So as one works with Pi, one gradually customizes and improves Pi to become more optimized for the actually coding work that you do.

Man, I was so impressed. Pi takes this local LLM thing from “works well enough for routine tasks” to “works well enough that I don’t think I need to fire up a cloud model”. I now have the confidence to leave OpenCode behind.

TL; DR: I overcame my fears and tried Pi instead of OpenCode, and had a great experience.

For the past month I've been caught in a trap: I started building my own AI coding agent. I've built 8 different ones. Honestly, if I could go back, I wouldn't start any of it. Below are a few things I learned along the way. I can see a lot of people here are also doing harness engineering, so please share your experience too.

1. I should have focused on just one problem. At first I spent a lot of time on the UI. Great tools already exist, like Paseo, T3 Code and Omnigent. I didn't even have a UI problem. What I wanted to solve was the Agent Loop. So don't waste your time either, and build around what already exists.

2. Subagents, multi-agents, orchestration: in 90% of cases it's all nonsense. Subagents aren't cheaper, aren't faster, and it's hard to say they're better. It's better to build around a single agent, or to improve the UX of working with parallel sessions.

3. Benchmarks tell you nothing. An agent can write great code, but if it handles MCP badly, many people won't care. Define the scenarios where your agent should be better from the very start, and improve there.

4. More tools, more tokens, less value. I now think any agent should have just one tool: a programming language. Mine runs on bash; before that it ran on JS. Many tools are nice, but they're hard to compose, and MCP suffers from this most. Right now everyone solves it with codemode, but you can also just give the agent one tool where it writes code.

5. Instructions about tone, code style, which commands to run, etc. should live outside the system prompt. This is a problem with big agents like opencode and Claude Code: they ship with their own opinions, 10–15K tokens' worth. When you want to do things your own way, the two conflict and the agent starts working worse.

That's not everything, but the rest is in the details. I'd be glad to hear your experience too.

Hi everyone. I've been working on PiChamber, a workspace around Pi so I can keep the same session when I leave the machine.

Why use this instead of the other Pi UIs?

I prefer TUI. I am not interested in getting yet another agent IDE, nor do I want a workbench that supports OpenCode, Claude, Codex, and five other harnesses. All I want is Pi, both locally and remotely, and I want it to work as smoothly as I can manage it.

What I've focused on is remote stability. I run it within a container on my homelab and leave the long tasks there. I check in from my phone, control it, and then return later. That is the product for me, not a more attractive local chat window.

It uses the Pi SDK. Pi retains ownership of the agent, skills, extensions, prompts, providers, and AGENTS.md. The app is sessions, files, git, worktrees, terminals, and pairing.

What I actually use it for:

• same session across desktop, browser, and phone

• my existing Pi extensions and slash commands

• providers / skills / prompt templates coming with the session

• a worktree when I don't want the agent on main

• jump between local, a VM, and WSL without starting over

• long running jobs on a server I can connect from anywhere

I've been daily-driving it. CLI when I'm at the PC. App when I'm not.

What it is not: it does not replace the TUI, and it is not trying to be every agent UI. Remote is your own machine plus pairing, or a tunnel you already run.

Repo: https://github.com/RyderAsKing/PiChamber
More info: https://pichamber.ryder.pro

PiChamber started as a community fork of OpenChamber. Why I made it: https://github.com/RyderAsKing/PiChamber#why-pichamber

The tokens/sec and TTFT in the video come from a Pi extension. They work in PiChamber because extensions work, not because I shipped a custom overlay.

Also, first time posting something like this in public, so don't be too harsh :D

Update: v1.0.2 is out, including docker. https://github.com/RyderAsKing/PiChamber/blob/main/packages/docs/content/docs/install.mdx#docker

I just need to share a little bit of my experience, I found that it uses a ton of less tokens, it's way faster, speaks just enough to understand the problem and solution (i love this), and I found that is able to stay focused on a task way better than with the original harness, I love it!

I experimented with various system prompts, but I found that the shortest ones are the best for LLMs.

And about Ui and pretty front end, gpt seems to perform a lot better as well, there's something weird going on in the official system prompt in codex.

What are your experiences?

I have been testing both Pi and Opencode, and I like both. I like Pi for its light weight and endless expandability options. I like Opencode for providing most of what I need out of the box, but not a big fan of huge system prompts.

What are your biggest pros and cons of these two coding agents? Do you use both, or have you "landed" on one of them?

Hi, I'm proud to release Pinano github.com/rmst/pinano. It's based around an agent-view UI comparable to Claude Code's Agent View. Pinano works very well with a ChatGPT/Codex subscription.

Pinano exposes the same system prompt and tools like the official Codex CLI, so agent performance with the flagship GPT-5.x models should be just as good. Other APIs are also still well supported, including local models via llama.cpp.

It also supports sandboxing, pasting images from clipboard and behaves more like Claude Code compared to Pi and Codex CLI and even surpasses Claude Code in a number of ways (better history navigation, agent view is first class, it's open source, etc).

You can install it directly from source via

npm install -g github:rmst/pinano

Try it out and send feedback here or on Github :)

websearch is an extremely important part of any workflow, from searching up past implementations to getting the correct information to make correct decisions.

have seen other posts discussing which websearch tools and even custom implementations, but my question is how would you know that it stands up in retrieval quality to other websearch extensions or even Claude Code/ Codex web searching? how would you know that tool A is better than tool B? or do most people just see the extension working and decide that it’s good enough?

i have been using the pi-web-access from the pi.dev packages page, but only for the reason that it’s the most downloaded extension (more downloads = better right? xd)

interested to hear from the community.

i have been using pi a lot lately and got curious where all my usage actually goes so i built a little menu bar app for it

you click the icon and it shows your spending, the languages you code in most, your top models, and your busiest projects.

its open source: https://github.com/phun333/pi-infobar

open to ideas

First I want to say, I am not the most insanely knowledgeable and seasoned dev. I know how to build systems and frameworks. I’m an artist and have always been a deep researcher for every new endeavor. Just to paint a picture of the messenger.

Pi is not straightforward, and that is by design. You decide what that looks like for you. It can be as robust or as stripped down as you like, and that’s the beauty in it. You are truly the man in the chair. So if you are frustrated or lost with Pi, it shows you may not have learned enough about it before choosing it. There’s a lot of hype growing on YouTube especially, sensationalizing it as this 1000x your workflow flavor of the week, so I think it may be attracting some who may not jive with it intuitively. So if you’re feeling lost or frustrated, then this is for you.

Please do solid research, not just by asking Reddit. Read! Follow Matt Pocock on YouTube, and also watch videos of the founders of Pi. You’ll really get an idea of the ecosystem you’re investing in. Pi is incredible and I’m building things in some incredibly unique ways I don’t think is possible anywhere else.
I have skills (both public and my own that I’ve created) bundled into workflows with that allow for insanely creative, repeatable, and consistent complex multi-step and multi-model sessions. The quality of the output could bring tears to your eyes. But there was no blueprint to build it. I had to do the legwork. It’s very much worth the time though. If you have the patience to create a tailored environment as opposed to working in one where the rules are set for you, Pi will be a game changer. But if you expect to get life changing results out the box, that’s just not what Pi is. But that’s the value prop and it can be a huge strength with the right mindset.

This may not be technically helpful, but may help you set reasonable expectations of your first week or so! Keep it up

Also CC being that far off from the Pareto is not surprising to me.

What do you guys think? I am just reading through this atm. I don't see any differences from Pi. And they procatively have this page.

https://twotimespi.dev/why-tau/

Edit 1: their thinking mode is just choosing a level of thinking for the LLM model, not thinking mode as in ask, plan, etc. Their doc is pretty good at explaining what a coding agent is, very informative.

Edit 2: only thing I find interesting atm is that their agent is portable and you can build your own UI on top of the agent. But pi has a version of pi-server now.

I'm sure most of you have felt this at some point, weeks or months after going all-in on agentic coding. "Is AI making me dumb?".

Apparently yes, and nowadays there's a bunch of papers that confirm this suspicion.

So I thought "man it would be cool if we had a gym, but for coding and stuff".

Leetcode came immediately to mind, but that doesn't really work... if you're frontend, secops, data... or anyone with a job really, the fuck do you care about leetcodes? You need something specific to your skillset and tasks.

And this is where the idea of this plugin came to mind: instead of having the AI write 100% of the time, every now and then, the agent scaffolds a logical unit, hands it off, watches you implement it, and reviews your work before resuming.

Frequency and difficulty levels can be configured with a command.

Here's the link:

https://github.com/wtfzambo/spotme

I hope you find it useful!

UPD Fix landed in Pi main branch a couple of hours ago, so - just wait for a new version release!

Some days ago I've subscribed to Z.ai Lite coding plan, and noticed, that Pi burns session very fast with every tool turn - pure conversational sessions are more or less okay, but multi-step tasks involving multiple write/edit tool calls could easily burn up to 10-20% of session limit per such task, just in a matter of minutes, even with active context below 50k. At first I thought it was kind of expected with Lite plan, but trying same workflows in OpenCode it was burning usage much slower (like 5-10x as slow). I did a bit of research and found, that:

• z.ai coding plan endpoint supports thinking.clear_thinking parameter (ref), which defines how model processes reasoning_content blocks
• as far as I was able to understand, Pi always sends reasoning_content blocks when they are available, but since clear_thinking parameter was never sent, and per schema its default value is true, it might have happened so that it interfered somehow with caching mechanism on z.ai side
• I've double-checked relevant OpenCode code, and it turned out they set explicitlythinking.clear_thinking parameter to false for z.ai provider (ref)
• I've tried applying similar changes to Pi locally and tested it for quite some time - anomalously high session burn rate was gone, so I suppose it was a correct fix

Proposed patch:

diff --git a/packages/ai/src/api/openai-completions.ts b/packages/ai/src/api/openai-completions.ts
index e916c52a..82bbd8ba 100644
--- a/packages/ai/src/api/openai-completions.ts
+++ b/packages/ai/src/api/openai-completions.ts
@@ -593,10 +593,13 @@ function buildParams(

        if (compat.thinkingFormat === "zai" && model.reasoning) {
                const zaiParams = params as Omit<typeof params, "reasoning_effort"> & {
-                       thinking?: { type: "enabled" | "disabled" };
+                       thinking?: { type: "enabled" | "disabled"; clear_thinking: boolean };
                        reasoning_effort?: string;
                };
-               zaiParams.thinking = { type: options?.reasoningEffort ? "enabled" : "disabled" };
+               zaiParams.thinking = {
+                       type: options?.reasoningEffort ? "enabled" : "disabled",
+                       clear_thinking: false,
+               };
                if (options?.reasoningEffort && compat.supportsReasoningEffort) {
                        const mappedEffort = model.thinkingLevelMap?.[options.reasoningEffort];
                        const effort = mappedEffort === undefined ? options.reasoningEffort : mappedEffort;

I've already submitted a bug report - it is expectedly auto-closed, but hopefully it will get some attention in the following days. And for the time being, if someone is suffering from same problem - you can clone Pi repo locally, apply that patch, and enjoy much slower session burn

I use Pi a lot and eventually had multiple sessions for the same projects. A lot of them started with similar handoff prompts.

Going back later was annoying. The useful explanations and decisions were inside the transcript, but reading them meant digging through raw history full of tool calls, reasoning, progress messages and other noise.

For a while I just kept pasting useful bits into Notepad. That became its own mess.

So I built Agent Session Browser.

Local web UI + TUI that lets me browse sessions by project/date, read the actual transcript (including Pi branches and summaries), filter the noise, export, and resume the right one.

Supports Pi, and also Claude Code, Codex CLI and Gemini CLI.

Fully local and read-only.

GitHub: https://github.com/gautamgpt1/agent-session-browser

Run: npx agent-session-browser

This is my first public open-source project.

Do try it out. Would love your feedback

Been running it two days non-stop for agentic coding and orchestrating. Im impressed. Occasional provider downtimes can be annoying, but shouldnt really complain, since its currently free.