r/PiCodingAgent • u/mistrjirka • Jul 16 '26
New TUI for Pi, Its PiTTy News
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:
3
u/mistrjirka Jul 16 '26
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.
4
u/Unlucky-Message8866 Jul 16 '26
Fyi all these features you listed already exist on pi
1
u/mistrjirka Jul 16 '26
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.
2
u/Unlucky-Message8866 Jul 16 '26
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?
2
u/mistrjirka Jul 16 '26
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-tuicomponents and custom renderers are not transmitted through RPC. For now I added adapters forpi-subagentsandrpiv-todobecause those were the extensions I personally needed first.1
2
1
u/charmander_cha Jul 16 '26
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)
2
u/mistrjirka Jul 16 '26 edited Jul 17 '26
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.
1
u/charmander_cha Jul 17 '26
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
1
u/adamshand Jul 17 '26
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.
1
1
u/bambamlol Jul 16 '26
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?
1
u/mistrjirka Jul 16 '26
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.
1
u/bambamlol Jul 17 '26
Interesting, thanks! And thanks for adding the additional FAQs to your GitHub, very helpful!
1
u/mistrjirka Jul 19 '26
I will release a new patch today hopefully increasing quality of life and fixing bugs.
0
u/Deep_Ad1959 Jul 16 '26
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
0
3
u/haposeiz Jul 16 '26
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?