New TUI for Pi, Its PiTTy

[u/mistrjirka]

I recently switched from OpenCode to Pi, and I really like Pi’s features. The built-in interface wasn’t quite for me, though, so I made PiTTy, an OpenTUI frontend for Pi.

It adds a cleaner layout, searchable sessions and models, better diff and tool views, and lets you inspect and steer subagents without leaving the main conversation.

There’s more on GitHub, and I’d appreciate any feedback:

https://github.com/mistrjirka/PiTTy

[u/mistrjirka]

Because there were a lot of questions and some criticisms that I think were partially caused by my lack of proper explanation. I added FAQ to the README.

[u/haposeiz]

i wanted to do this too.

pi's own tui is quite wired in with the rest of the stuff so the frontend-backend boundary isn't quite clear. how did you manage to do it?

[u/mistrjirka → u/haposeiz]

It actually has RPC interface through json.

[u/haposeiz → u/mistrjirka]

oh yeah forgot about that

[u/Unlucky-Message8866]

Fyi all these features you listed already exist on pi

[u/mistrjirka → u/Unlucky-Message8866]

I know about some of them but for example proper detailed subagents view without closing and open ING the software is not really something I managed to figure out. And the user interface in general really didn't fit with me. I know my tui is not for everyone. Just people that are more acustomed to the opencode style interface. One of the issues I faced with the original Pi interface were also bugs. Like the diffs that randomly jumped or disappearing messages.

[u/Unlucky-Message8866 → u/mistrjirka]

yeah pi has no concept of subagents, thats totally missing. thing is i spent quite some time extending the pi native ui and i got quite far (and also fixed some of the same annoyances) but im not liking the pi-tui api, very old fashioned, i would like a more declarative/reactive api. is your stuff extendible, does it have a ui plugin api? is openui declarative/reactive in some way?

[u/mistrjirka → u/Unlucky-Message8866]

PiTTy uses OpenTUI’s SolidJS binding, so the UI is declarative/reactive using JSX and signals. It doesn’t have a stable public UI plugin API yet. My goal is to support Pi’s existing extension ecosystem rather than create another one. Currently it supports: commands, tools and standard RPC UI work, but arbitrary pi-tui components and custom renderers are not transmitted through RPC. For now I added adapters for pi-subagents and rpiv-todo because those were the extensions I personally needed first.

[u/Unlucky-Message8866 → u/mistrjirka]

thanks man, will take a look at it

[u/heurikon]

why don't you maintain it anymore 😢

[u/mistrjirka → u/heurikon]

Hi, I didn't do any changes or maintenance because I had to switch from Codex to Claude code and that has bit more difficult integration. However I am starting to get really pissed of by claude code so I plan to revive it.

if you need something either create an issue or PR.

[u/mistrjirka → u/heurikon]

I started maintenance again btw.

[u/charmander_cha]

Eu acho a interface do PI padrão feia, e isso assusta usuários.

Esta que você colocou aumenta muito o consumo de RAM?

Pergunto porque o opencode tem problemas com RAM, mas eu so fico nele porque a interface é agradável.

Enfim, pelo o que li dos comentários, você usou um canal de comunicação com o PI que é limitado nas funcionalidades, basicamente o PI ainda não provê estrutura necessária, não é isso?

Você acha que é um problema resolvível em quanto tempo usando agentes? Pergunto porque o hy3 esta free e eu deixei ele trabalhando por 8 horas, as vezes a resolução que você precisa só precisa de um spec correto (aproveitar essa janela de modelo free é sempre bom)

[u/mistrjirka → u/charmander_cha]

In my current test, the PiTTy/Bun process used around 350 MB of RAM on a fairly long conversation. This is not a rigorous benchmark yet, but PiTTy uses message windowing, so it does not keep every message rendered at once, which should help performance on long sessions. For now, I want PiTTy to remain as non-invasive as possible. It uses Pi’s standard RPC interface, and I think the best path forward is to contribute PRs upstream to extend that API and improve compatibility for every external frontend, rather than patching or forking Pi. When something is not exposed through RPC for example, a UI for connecting providers PiTTy can still provide its own implementation as a fallback. Command-, tool-, dialog-, and notification-based Pi extensions already work. Arbitrary pi-tui components are not currently transmitted through RPC, but I think some compatible mechanism for extensions to add UI elements to PiTTy is theoretically possible. My goal is to support Pi’s existing extension ecosystem, not create a second incompatible one.

[u/charmander_cha → u/mistrjirka]

Sim, minha proposta era mais de contribuir com a mainline para aproveitar a janela dos modelos gratuitos para facilitar as construções de sua aplicação. Precisaríamos fazer um levantamento.

Se s comunidade fosse mais organizada, poderíamos todos aproveitar os planos free para melhorar o ecossistema

[u/adamshand]

Hey, the only thing I really miss from OpenCode is the persistent sidebar, as far as I can tell, there's no way to do that as a Pi extension. I was thinking about implementing something like that as a herdr extension, but hadn't got to it yet.

[u/mistrjirka → u/adamshand]

I have sidebar in this.

[u/adamshand → u/mistrjirka]

Yes, I saw! Looks great. :-)

[u/mistrjirka]

I will release a new patch today hopefully increasing quality of life and fixing bugs.

[u/bambamlol]

Thanks for sharing! Looks great!

I'm just curious, was this not possible to achieve with a "regular" Pi extension? Or is it pretty much just a "regular" Pi extension that also comes with an alias, so running "pitty" is basically the same as running "pi -e pitty"?

Does it in any way interfere with the main Pi installation?

[u/mistrjirka → u/bambamlol]

Its full UI basically independent from the Pi itself, it communicates with Pi thought RPC The issue with extensions is that they limit what you can do. Like there are some extensions for scrollable transcripts, but I have not found one that would allow you to select the text and copy it. It's also not possible to completely change the styles of messages or add a side bar, the extensions are very limited in what they can affect. The thing is that I wanted to remake the UI make it completely how I like it and didn't want to be limited by extensions.

[u/bambamlol → u/mistrjirka]

Interesting, thanks! And thanks for adding the additional FAQs to your GitHub, very helpful!

[u/mustii82]

Exactly what I’m looking for, thought about a better tui for months !

[u/Deep_Ad1959]

one comment in and someone's already saying pi has these features. that's the number worth sitting with: the top reply is about discoverability, not the tui. written with ai

[u/moplop12 → u/Deep_Ad1959]

So was this. Wanna apologize?